Support `{prefix}` and `{lowerprefix}` markers in `config.json` `dl` key
Hello,
The crates.io-index Git repository uses a nice directory structure to keep individual directory sizes under control.
When mirroring crates.io, it's useful to store crate files in a similar directory structure for the same reasons.
Cargo provides "markers" for use in the `dl` key of the `config.json` file in crates.io-index to allow flexibility in mapping a crate's name and version into a URL for the crate. The marker `{crate}` is replaced by the crate's name, and the marker `{version}` is replaced with the crate's version. The default URL template is `https://crates.io/api/v1/crates/{crate}/{version}/download`.
Currently, if a mirror of crates.io stores crates in a directory structure similar to that of crates.io-index, it's up to the server to construct the directory name from the crate name. This eliminates trivial web servers and `file:` URLs from hosting such a tree of crates.
This pull requests adds two new markers for the `dl` key in `config.json`, allowing Cargo to supply the directory name as part of the URL. The marker `{lowerprefix}` is the same directory name used within crates.io-index; it is calculated from the crate name converted to lowercase. The marker `{prefix}` is similar, but it uses the crate name as-is (without case conversion), which is useful for supporting older versions of Cargo that lack these markers; for example, nginx rewrite rules can easily construct `{prefix}` but can't perform case-conversion to construct `{lowerprefix}`. These new markers will provide implementation flexibility and simplicity for crate mirror servers.
Add environment variables to identify the binary and crate name
Closes#8251
This adds `CARGO_BIN_NAME` and `CARGO_CRATE_NAME` to rustc/rustdoc process env.
`CARGO_BIN_NAME` is added for binary compilation units, `CARGO_CRATE_NAME` is added for binary and library units.
The `build::crate_env_vars` test was updated to test for this. The test is currently only checking behavior for the binary compile unit.
Documentation was updated to reflect the added environment variables.
1.45 beta backports
Beta backports for:
* #8290 — Fix fingerprinting for lld on Windows with dylib.
* #8329 — Don't hash executable filenames on apple platforms. (fix macos backtraces)
Don't hash executable filenames on apple platforms.
Due to some recent changes to the backtrace crate, backtraces on apple platforms haven't been working (they are missing line/filename information). The reason is that previously libbacktrace would hunt through the directory for any matching file in the `.dSYM` directory. The new implementation expects a file matching the executable name exactly (which no longer includes the hash because Cargo renames it).
The solution here is to not include a hash in the executable filename. This matches the behavior on Windows which does it for a similar reason (paths are embedded in pdb files).
The downside is that switching between different settings (like different features) causes Cargo to rebuild the binary each time. I don't think this is a particularly common use case, at least I've not heard any complaints about this behavior on Windows.
Fixes https://github.com/rust-lang/rust/issues/72550
Fix fingerprinting for lld on Windows with dylib.
This fixes an issue where if `lld` is used on Windows, dynamic libraries will never be treated as "fresh". This is a regression from #8210 where Cargo is expecting export files to be created, but lld does not create these.
The solution is to ignore "Auxiliary" files in fingerprinting, which AFAIK aren't really needed (only the primary output files really matter).
Fixes#8284
Don't hash executable filenames on apple platforms.
Due to some recent changes to the backtrace crate, backtraces on apple platforms haven't been working (they are missing line/filename information). The reason is that previously libbacktrace would hunt through the directory for any matching file in the `.dSYM` directory. The new implementation expects a file matching the executable name exactly (which no longer includes the hash because Cargo renames it).
The solution here is to not include a hash in the executable filename. This matches the behavior on Windows which does it for a similar reason (paths are embedded in pdb files).
The downside is that switching between different settings (like different features) causes Cargo to rebuild the binary each time. I don't think this is a particularly common use case, at least I've not heard any complaints about this behavior on Windows.
Fixes https://github.com/rust-lang/rust/issues/72550
Previously, this failure will return an unhelpful warning.
This commit adds an error message saying that the argument for
`manifest_path` must be an absolute path.
Fix an accidental raw access of field
The manifest has a few different ways of specifying whether a crate is a
procedural macro, and there's a `TomlTarget::proc_macro()` method to
unify these various lines. Unfortunately though we had a bug where one
location forgot to call the method and read the raw field! This led to
surprising behavior where the different ways to specify a proc macro
would have subtly different changes in behavior. The fix here in this PR
is to ensure that we access the property always via the method.
Closes#8315
The manifest has a few different ways of specifying whether a crate is a
procedural macro, and there's a `TomlTarget::proc_macro()` method to
unify these various lines. Unfortunately though we had a bug where one
location forgot to call the method and read the raw field! This led to
surprising behavior where the different ways to specify a proc macro
would have subtly different changes in behavior. The fix here in this PR
is to ensure that we access the property always via the method.
Closes#8315
Warn if using hash in git URL, Fixes#8241
This fixes an issue where if the user wants to set the git rev but doesn't know how and as results tries to set the ref in the url hash as also shown when downloading the dependency.
Now cargo returns a warning notifying the user about the correct way to set the ref.
Fixes#8241
reset lockfile information between resolutions
#8249 pointed out that some kind of lockfile data was leaking between calls to the resolver. @ehuss made a reproducing test case. This PR resets the `LockedMap` data structure when calling `register_previous_locks`.
lets see if CI likes it.
fix#8249
