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 041c49c1ed11b016d6ab9379643bb1da2adf5bfe, reversing
changes made to 1df5766cbb559aab0ad5c2296d8b768182b5186c.
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.
