This introduces a work-around for a bug in rustup.rs when excuting
cargo from a custom toolchain. Instead of trusting rustup to
invoke cargo from one of the release channels we just invoke
nightly cargo directly.
This is in anticipation for rust-lang/rust#56987 where the
`rustc_driver` crate being linked in will be required to link correctly
against the compiler. In the meantime it should be harmless otherwise!
Revert "Merge pull request #3257 from o01eg/remove-sysroot"
This reverts commit 041c49c1ed, reversing
changes made to 1df5766cbb.
The PR broke running a cargo-install'd clippy.
The installed clippy would not be able to find a crate for std.
Fixes#3523Reopens#2874
The rustc arg might not be exactly "rustc". It may be any path to a rustc
executable (especially if the RUSTC environment variable is set when
executing cargo). Rather check that it is a path with 'rustc' file stem.
Warning was:
warning: the feature `macro_vis_matcher` has been stable since 1.29.0 and no longer requires an attribute to enable
--> src/lib.rs:4:12
|
4 | #![feature(macro_vis_matcher)]
| ^^^^^^^^^^^^^^^^^
|
= note: #[warn(stable_features)] on by default
This commit makes `cargo clippy` output the build artifacts to a
separate directory if the `CLIPPY_DOGFOOD` env var is set. This should
prevent dogfood builds from interfering with regular builds.
This should help with issue #2595.
Now that we're using cargo check, we can stop needing to find out the
manifest path ourselves. Instead, we can delegate to cargo check, which
is perfectly capable of working out for itself what needs to be built.
This fixes#1707 and #2518.
Note that this PR will change the output. We will no longer output `bin:
foo` before each crate. This a bit unfortunate. However, given that
we're now going to be building in parallel (which is *much* faster), I
think this is acceptable - we'll be no worse than cargo itself.
Matthias Krüger