Cargo's `[lints]` table is a cargo-only feature: cargo translates the
entries into `-A`/`-W`/`-D`/`-F` rustc flags before invoking the
compiler. Since buildRustCrate calls rustc directly, these lints were
silently ignored, forcing users to duplicate them as raw flags in
`extraRustcOpts`.
Accept a `lints` attr with the same shape as the Cargo.toml section
(tool → lint name → level string or `{ level, priority }` attrset),
translate it to rustc flags in Nix, and append to the rustc command
line. Entries are sorted by ascending priority so lower-priority lint
groups are emitted first and can be overridden by more specific lints,
matching cargo's behaviour.
The `capLints` default changes from `"allow"` to `null`, resolved to
`"allow"` when `lints` is empty (the usual case for third-party
dependencies) and `"forbid"` when `lints` is set — otherwise a
`deny`/`forbid` lint would be silently capped and the table would be a
no-op. Explicit `capLints` still overrides. This is the same model
cargo uses: your own crate's `[lints]` always apply; only
dependencies get `--cap-lints allow`.
Generators like crate2nix can populate `lints` directly from the
manifest at generation time.
lib.sh previously hardcoded `--cap-lints allow` in both build_lib and
build_bin. Since rustc only honours the first `--cap-lints` it sees,
appending a different level via `extraRustcOpts` had no effect, making
it impossible to run clippy (or any lint-based tooling) through
buildRustCrate without wrapper scripts that strip the argument.
This adds a `capLints` parameter (default `"allow"`, preserving current
behaviour) that can be set per-crate or via `.override`:
(myCrate { }).override { capLints = "warn"; }
This was available in makeNeovimConfig already but:
- generated wrapper arguments, which we want to avoid because it
confuses users
- `makeNeovimConfig` relies on neovim-unwrapped in impure manner, which
for instance caused issues in one of cases where I override
neovim-unwrapped's luajit with a luajit with custom lua packages.
Cargo uses the basename of a JSON target specification in various places
to refer to targets, cc-rs parses the basename to grab target
information. There may be other examples where the basename is relevant.
Instead of fighting these existing conventions, let's just recommend
users provide a rustcTargetSpec, either as a standard name or as a
custom JSON file with the right basename
This adds a useful hook to be used for projects that use stestr,
it is primiative at the moment but covers most scenarios for using
it.
This PR also changes a Python module to start using it, once it
lands, follow up PRs can update all of them to use it tree-wide.
Signed-off-by: Vinetos <contact+git@vinetos.fr>
