quasar: fix the zeropod resolution and lint the crates in CI - #125
Merged
Conversation
`quasar-lang` at the pinned rev asks for `zeropod = "0.3.3"` and `wincode = "0.4"`. zeropod 0.3.4 moved to wincode 0.5, so a caret range resolves to a zeropod whose `PodU16`, `PodU32` and `PodU64` implement wincode 0.5's `SchemaWrite`, while the macros in quasar-lang name wincode 0.4's. Every u16/u32/u64 instruction argument then fails to compile with "the trait bound `PodU64: SchemaWrite<...>` is not satisfied", and rustc adds "there are multiple different versions of crate `wincode` in the dependency graph". No lockfile is committed for these crates and CI regenerates one before building, so the resolution is live: a project builds or does not depending on what zeropod has published, not on anything in this repository. lending, perpetual-futures and prop-amm already carried this pin. The other 53 did not, and 42 of them did not compile. Same pin, same comment, applied everywhere. (cherry picked from commit 6444919)
None of these crates has ever been formatted or linted: they each declare
their own `[workspace]`, and the repository-wide jobs only see members of the
root workspace. 51 of 56 had formatting diffs and 42 had clippy findings.
Formatting is `cargo fmt` with the repository's own rustfmt.toml, which they
pick up already by sitting under it.
The lint fixes:
- Account structs reported fields as never read, because `mod instructions;`
kept the structs crate-private even though their fields were `pub`. The
modules are `pub` now, which is what the majority of the Anchor examples
already do and what a client needs to name the accounts.
- Needless borrows of `.address()`, which returns a reference already.
- `for i in 0..n { views[k + i] = src[i].clone() }` over account views, which
is `clone_from_slice` on the corresponding subslice.
- `&[signer.clone()]` where `core::slice::from_ref(&signer)` does not clone.
- `(b'0'..=b'9').contains(&byte)` is `byte.is_ascii_digit()`.
- Redundant field names, a useless `u16` conversion, a manual `div_ceil`, a
manual `!RangeInclusive::contains`, and a doc comment separated from its
item by a blank line.
- `MAX_URI_LEN` in cutils was named only by two comments and enforced by
nothing; the `String<256, 2>` bound is what actually caps the URI, so the
constant is gone and the comments say so.
- `handle_init_mint` took ten arguments. The three extension authorities and
the three metadata fields are now `MintAuthorities` and `MintMetadata`.
All Quasar projects build with `quasar build` and pass `cargo test`: 197
tests across 56 crates.
(cherry picked from commit dcee536)
The `Rust Lint` workflow runs `cargo fmt --check` and `cargo clippy` from the repository root, which only ever sees members of the root workspace. Every Quasar crate declares its own `[workspace]`, because `quasar build` runs `cargo metadata --locked` against a per-project lockfile, so they cannot be members and that workflow has never seen them. The Quasar workflow builds and tests them but does not lint them. This adds a `lint` job running the same two commands the repository-wide job runs, including the `diverging_sub_expression` allowance. It walks Cargo manifests that name `quasar-lang` rather than reusing `build-and-test`'s project list, which is directories named exactly `quasar`. That list misses `tokens/quasar-metadata`, a vendored library three of the examples depend on. Linting is a host build needing neither the Quasar CLI nor platform-tools, and does not vary by Solana version, so it runs once rather than once per matrix entry. It reports every failing crate rather than stopping at the first.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Independent of the Anchor v2 work. Touches only Quasar crates and
.github/workflows/quasar.yml.42 of the 56 Quasar crates do not compile
quasar-langat the pinned rev asks forzeropod = "0.3.3"andwincode = "0.4". zeropod 0.3.4 moved to wincode 0.5, so a caret range resolves to a zeropod whosePodU16,PodU32andPodU64implement wincode 0.5'sSchemaWrite, while the macros in quasar-lang name wincode 0.4's. Everyu16/u32/u64instruction argument then fails withthe trait bound PodU64: SchemaWrite<...> is not satisfied, and rustc addsthere are multiple different versions of crate wincode in the dependency graph.No lockfile is committed for these crates and CI regenerates one before building, so the resolution is live: a project builds or does not depending on what zeropod has published, not on anything in this repository.
lending,perpetual-futuresandprop-ammalready carried thezeropod = "=0.3.3"pin with a comment explaining exactly this. The other 53 did not. Same pin, same comment, applied everywhere.Nothing has ever linted them
Each Quasar crate declares its own
[workspace], becausequasar buildrunscargo metadata --lockedagainst a per-project lockfile. They therefore cannot be members of the root workspace, and the repository-wideRust Lintworkflow only ever sees members. The Quasar workflow builds and tests them but never lints them.51 of 56 had formatting diffs and 42 had clippy findings. Most fixes were mechanical. Three were not:
mod instructions;kept the structs crate-private even though their fields werepub. The modules arepubnow, which is what most of the Anchor examples already do and what a client needs to name the accounts.MAX_URI_LENin cutils was named by two comments and enforced by nothing. TheString<256, 2>bound is what actually caps the URI, so the constant is gone and the comments say so.handle_init_minttook ten arguments. The three extension authorities and the three metadata fields are nowMintAuthoritiesandMintMetadata.A new
lintjob runs the same two commands the repository-wide job runs. It walks Cargo manifests namingquasar-langrather than reusing the build job's project list, which is directories named exactlyquasarand so missestokens/quasar-metadata, a vendored library three examples depend on. Linting needs neither the Quasar CLI nor platform-tools and does not vary by Solana version, so it runs once rather than once per matrix entry, and reports every failing crate rather than stopping at the first.Verification
Ran against this branch, not the branch it was extracted from: all 56 crates pass
cargo fmt --checkandcargo clippy -- -D warnings. Main gained funding-rate tests infinance/perpetual-futures/quasarafter the original work, and those were unformatted; this branch formats them too.The build and test path was verified with the Quasar CLI installed at the pinned rev, running the workflow's own sequence of
quasar buildthencargo testper project: 197 tests pass.Generated by Claude Code