The crates.io API server's 1 req/sec rate limit currently surfaces as
intermittent HTTP 403 errors when vendoring lockfiles. Switch to the CDN
endpoint as recommended by upstream (rust-lang/crates.io#13482), mirroring
the fix already applied to fetchCargoVendor in #512735.
fetchurl is content-addressed by sha256, so the URL change does not affect
any downstream store paths.
Fixes#524979
Proc-macro crates are host dylibs that rustc dlopen()s. Instrumentation
flags passed via extraRustcOpts (e.g. -Zsanitizer=address,
-Cinstrument-coverage) leave unresolved runtime symbols in those dylibs
and break the build. Cargo avoids this by not applying RUSTFLAGS to host
artifacts; buildRustCrate already has extraRustcOptsForBuildRs for build
scripts, so add the analogous knob for proc-macros.
Defaults to null, which falls back to extraRustcOpts so existing callers
are unchanged. Set to [] to opt proc-macros out when applying
sanitizer/coverage flags tree-wide via crateOverrides.
Commit c4f5dfad0d was intended as a stylistic cleanup, but the trailing \ it
removed from pkgs/build-support/rust/lib/default.nix was not stylistic: it is a
shell line continuation that joins the cross-only env var block to the cargo
command added by consumers. Without it, `CC_*`, `CXX_*`, and
`CARGO_TARGET_*_LINKER` are silently not passed to cargo when
rustTargetPlatform != rustHostPlatform.
This in turn can break cross compilation of Rust packages.
Fix it by adding back the trailing \
Fixes: #497857
Signed-off-by: Gilberto Bertin <me@jibi.io>
Add completePropagatedBuildInputs that collects propagatedBuildInputs
from a crate and all its transitive Rust dependencies, analogous to how
completeDeps chains .rlib paths. The collected inputs are appended to
buildInputs so native library deps (e.g. boost) declared on a library
crate automatically propagate to binary crates that depend on it,
without requiring repetition in every downstream crate override.
The Makefile generated for parallel binary builds used the binary names
directly as make targets. This caused make to silently skip a build
whenever a file or directory with the same name existed in the crate
source root — e.g. a crate with a `cli` binary and a `cli/` directory
would "succeed" without producing the binary.
Using the binary name as a target also risked collision with the `all`
meta-target and with make metacharacters (`$`, `:`, `#`) in user-supplied
crateName or bin.path values.
Switch to synthetic numeric targets (b0, b1, …) declared .PHONY, and
escape `$` in the recipe arguments.
Collect binary targets into a bash associative array (name→path), then
generate a Makefile on the fly and pipe it to `make -j`. Make handles
parallel execution and the jobserver protocol natively, so rustc
invocations share the same token pool via MAKEFLAGS.
Also fix build_bin error propagation: add `|| return 1` to the rustc
invocation so failures are not silently swallowed when the crate name
has no hyphens and the mv rename is skipped.
Cargo sets `CARGO_BIN_EXE_<name>` when compiling integration tests so
they can locate the crate's own binaries via `env!()` and exec them
as subprocesses. buildRustCrate previously compiled bin targets as
test harnesses only (via `--test`) when buildTests=true, so the real
binary never existed and the env var was never set.
When buildTests is set, now first build the real (non-test) binaries
to `target/cargo-bin-exe/`, install them to `$out/bin/`, and expose
`CARGO_BIN_EXE_<name>` to subsequent rustc invocations via an `env`
prefix. Using `env` rather than bash `export` is necessary because
hyphenated binary names (`CARGO_BIN_EXE_my-crate`) produce env var
names that bash rejects as invalid identifiers; `env` sets them via
execve's envp array directly and has no such restriction.
The env array is populated by iterating `target/cargo-bin-exe/` at
build time, so it covers all binary-target shapes: explicit `crateBin`
entries, auto-detected `src/main.rs`, and auto-detected `src/bin/*.rs`.
`build_bin` in lib.sh gains an optional third argument for the output
directory so the real binary and the `--test` harness can coexist
without colliding in `target/bin/`. The lib-test build is reordered to
after the real-bin build so its compilation also sees the env vars.
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.
build_bin_test_file derives the test binary name by replacing `/` with
`_`, stripping the `tests_` prefix and `.rs` suffix. For the
subdirectory integration-test layout `tests/<dir>/main.rs`, this
produces `<dir>_main`, but cargo names that binary `<dir>` per its
auto-discovery rules. Tools that expect the cargo convention
(cargo-nextest binaries-metadata, IDE test runners) cannot find the
binaries.
Strip the trailing `_main` when the source file is `*/main.rs`. The
guard is needed so a flat-style `tests/<name>_main.rs` keeps its
suffix.
Add `expectedTestBinaries` to the test harness so binary naming can be
asserted, and cover both the subdir case (suffix stripped) and the
flat case with a literal `_main` in the filename (suffix kept). Also
fix a typo in `removeAttrs` that leaked `expectedTestOutputs` into the
crate args.
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"; }
When the rust-src component is installed (common with rust-overlay
toolchains via rust-toolchain.toml), rustc unvirtualises libstd source
paths. Panic locations from monomorphised generic std code
(BTreeMap, VecDeque, sync primitives, etc.) then embed the toolchain
store path in .rodata, pulling the entire multi-GB toolchain into the
runtime closure.
This is not an RPATH issue — stdenv's patchelf --shrink-rpath already
cleans that. The reference is a core::panic::Location string.
Remap the rustc store path to /rustc so panic messages stay readable
but no longer create a store-path dependency. This is a no-op for
toolchains without rust-src (the prefix simply never matches).
To avoid confusion and spurious newlines in the output.
Found by searching for a backslash followed by a newline, some
indentation, and then the end of multi-line string marker, using the
following extended regex:
```regex
\\\n +'';
```
In [0.9.109], nextest added a `--show-progress=running` mode that
shows an interactive view of currently running tests. This is nice in
interactive use. However, it's very annoying when viewing logs after the
fact, such as through `nix log ...`.
`--show-progress=none` reverts to the simple interface, reporting a
single line for each test run with no control codes.
[0.9.109]: https://github.com/nextest-rs/nextest/releases/tag/cargo-nextest-0.9.109
