Bump to semver 0.10 for `VersionReq::is_exact`
This stops using `to_string` as a proxy for this now-provided precise API.
This reverts commit b71927224fd9306b2b5bd2b4f8c22268eadfeb6a and bumps the
dependency version in Cargo.toml.
This stops using `to_string` as a proxy for this now-provided precise API.
This reverts commit b71927224fd9306b2b5bd2b4f8c22268eadfeb6a and bupms the
dependency version in Cargo.toml.
Fix panic with `cargo tree --target=all -Zfeatures=all`
When `cargo tree --target=all` was used with the new feature resolver, this would cause a panic because the feature resolver doesn't know about the "all" behavior, and would filter out packages that don't match.
I don't feel like this is a particularly elegant solution, but I'm uncertain of how to make it better.
Closes#8109
Fix nightly tests with llvm-tools.
https://github.com/rust-lang/rust/pull/72000 removed `libLLVM-10-rust-1.45.0-nightly.so` from the default install. Several of the plugins tests fail without this, so make sure it gets installed.
Provide better error messages for a bad `patch`.
This attempts to provide more user-friendly error messages for some situations with a bad `patch`. This is a follow-up to #8243.
I think this more or less covers all the issues from #4678. I imagine there are other corner cases, but those will need to wait for another day. The main one I can think of is when the patch location is missing required features. Today you get a "blah was not used in the crate graph." warning, with some suggestions added in #6470, but it doesn't actually check if there is a feature mismatch.
Closes#4678
Try installing exact versions before updating
When an exact version is being installed, if we already have that
version from the index, we don't need to update the index before
installing it. Don't do this if it's not an exact version, because the
update may find us a newer version.
This is particularly useful for scripts which unconditionally run
`cargo install some-crate --version=1.2.3`. Before install-update, I
wrote a crate to do this
(https://crates.io/crates/cargo-ensure-installed) which I'm trying to
replace with just `cargo install`, but the extra latency of updating the
index for a no-op is noticeable.
Add option to strip binaries
This PR adds a Cargo option for stripping symbols from generated binaries.
This is based on the `-Z strip` flag for `rustc`, which has been [recently implemented](https://github.com/rust-lang/rust/issues/71757).
Notes for reviewers: I'm not entirely sure how we test this, I've created a crate locally and it seems to be working.
Supersedes my previous work in #8191.
Fixes#3483.
Handle LTO with an rlib/cdylib crate type
In the case that LTO is happening but we're also generating a
cdylib/rlib simultatneously that means that the final artifact will use
the rlib but the cdylib still needs to be produced. To get this to work
the cdylib's dependency tree needs to be compiled with embedded bitcode.
The cdylib itself will be linked with the linker because we can't LTO an
rlib+cdylib compilation, but the final executable will need to load
bitcode from all its deps.
This is meant to address rust-lang/rust#72268
In the case that LTO is happening but we're also generating a
cdylib/rlib simultatneously that means that the final artifact will use
the rlib but the cdylib still needs to be produced. To get this to work
the cdylib's dependency tree needs to be compiled with embedded bitcode.
The cdylib itself will be linked with the linker because we can't LTO an
rlib+cdylib compilation, but the final executable will need to load
bitcode from all its deps.
This is meant to address rust-lang/rust#72268
Gracefully handle errors during a build.
If there are certain errors like EPIPE during a build, Cargo runs the risk of hanging if the compiler emits too many messages. This happens because Cargo now uses a bounded queue for compiler messages. However, if the main loop exits while the threads are running, there is nothing to drain the queue, and thus the threads will block indefinitely.
The solution here is to be extra careful of how errors are handled in the main loop. All errors are now treated roughly the same (report the error, allow the queue to continue to drain).
I've also tweaked things so the *first* error is reported, not the last.
Closes#8245
Fix `cargo update` with unused patch.
If you end up with an unused patch in `Cargo.lock`, then you try to update the patch to a version that does not match the original unused patch, and run `cargo update`, Cargo refuses to update it with the error "patch for `bar` in `https://github.com/rust-lang/crates.io-index` did not resolve to any crates". At this point, Cargo seems to be permanently stuck with no way to update it (unless you manually edit `Cargo.lock`).
The solution here is to add the unused patches to the "to_avoid" list, so that `cargo update` is allowed to update them.
I am uncertain if this is the best way to fix it, but seems to match my intuition of how `cargo update` is implemented.
Rephrased error message for disallowed sections in virtual workspace
I changed the error message from `virtual manifests do not specify [target]` to `This virtual manifest specifies a [target] section, which is not allowed` because the old one confused me.
I encountered it while hacking on Rustc in CLion. I made a change to the `Cargo.toml` I had copied from StackOverflow and after the next restart code analysis and go-to-definition stopped working. After some fiddling, I tracked that down to my change in `Cargo.toml`. It took me a while because, like I said, the error message from CLion didn't make sense to me.
```
19:13 Cargo project update failed:
Execution failed (exit code 101).
/home/julian/.cargo/bin/cargo metadata --verbose --format-version 1 --all-features
stdout : error: failed to parse manifest at `/home/julian/Dokumente/Rust/Compiler/rust/Cargo.toml`
Caused by:
virtual manifests do not specify [target]
stderr :
```
I hope this change avoids future confusion :)
Ignore broken console output in some situations.
If stdout or stderr is closed while Cargo is running, Cargo would panic in some situations (usually with EPIPE). For example, `cargo install --list | grep -q cargo-fuzz`, where `grep` will close stdout once it gets a match. This changes it so that Cargo will ignore output errors in most situations. Failure to output a regular build message still results in an error, which follows the behavior of some tools like `make`.
All output, including stdout, now goes through `Shell`.
Closes#5234
Expand error message to explain that a string was found
With `opt-level = "3"` this previously said:
must be an integer, `z`, or `s`, but found: 3 for ...
The error message doesn't make that super clear.
This should now be a bit more clear.
Fixes#8234
---
We could even include a bit more saying that `"3"` should become 3 (either unconditionally or after trying to parse `"3"` into an integer?
cc @steveklabnik
With `opt-level = "3"` this previously said:
must be an integer, `z`, or `s`, but found: 3 for ...
The error message doesn't make that super clear.
This should now be a bit more clear.
Fixes#8234
Add context to some fs errors.
This adds some extra context to most fs operations that indicates some more detail (particularly the path). It can be frustrating when cargo says something generic like "Access is denied." without printing a path or information about what it is doing.
Addresses #8211, where it adds extra context to the message.
Move SipHasher to an isolated module.
This allows removing the blanket `#![allow(deprecated)]` sprinkled whenever it is used.
We could alternatively use the [siphasher](https://crates.io/crates/siphasher) crate, but I don't think it is necessary at this time.
