Use FxHash{Map,Set} instead of the default Hash{Map,Set} everywhere in rustc.
Most of the compiler uses the `Fx` hasher but some places ended up with the default one.
Fix manifests for broken tools: take 2
This is a follow up of #53715, to avoid stripping unavailable components from the extensions list. This time I also figured out how to test the changes, so the produced manifest is correct.
Along with the fix I added a README with instructions on how to test the tool, and a new `BUILD_MANIFEST_DISABLE_SIGNING` env var to avoid dealing with gpg while testing the tool. I chose an env var instead of a flag because it's more difficult to have it slip in by accident on CI, and there is also another protection that panics if that env var is set on CI, just to be sure we don't release unsigned artifacts.
r? @alexcrichton
cc https://github.com/rust-lang-nursery/rustup.rs/issues/1486
A recent change (#53245) started to build LLVM with ThinLTO enabled and to
ensure that compile times are kept down it builds LLVM dynamically by default to
ensure that all the various LLVM tools aren't redoing all that optimization
work. This means, however, that all LLVM tools depend on LLVM's dynamic library
by default.
While the LLVM tools and LLDB components were updated to include the shared
library we accidentally forgot about LLD, included with the main rustc
component. LLD also links dynamically to LLVM and ships a non-working binary
right now because of this!
This commit updates our distribution to ship the LLVM dynamic library with the
compiler libraries. While not technically needed for rustc itself to operate
(right now) it may be needed for LLD, and otherwise it serves as a good basis
for the other LLVM tools components to work with as well.
This should...
Closes#53813
Generalize `async_idents` to all new keywords
This commit generalizes the existing `async_idents` lint to easily encompass
other identifiers that will be keywords in future editions. The new lint is
called `keyword_idents` and the old `async_idents` lint is registered as renamed
to this new lint.
As a proof of concept the `try` keyword was added to this list as it looks to be
listed as a keyword in the 2018 edition only. The `await` keyword was not added
as it's not listed as a keyword yet.
Closes#53077
Don't emit "unused extern crate" warnings for `extern crate foo as _;`
When importing a crate and renaming it to an underscore-prefixed name,
suppress "unused extern crate" warnings (but not idiom lints).
Reoptimize VecDeque::append
~Unfortunately, I don't know if these changes fix the unsoundness mentioned in #53529, so it is stil a WIP.
This is also completely untested.
The VecDeque code contains other unsound code: one example : [reading unitialized memory](https://play.rust-lang.org/?gist=6ff47551769af61fd8adc45c44010887&version=nightly&mode=release&edition=2015) (detected by MIRI), so I think this code will need a bigger refactor to make it clearer and safer.~
Note: this is based on #53571.
r? @SimonSapin
Cc: #53529#52553 @YorickPeterse @jonas-schievink @Pazzaz @shepmaster.
This commit generalizes the existing `async_idents` lint to easily encompass
other identifiers that will be keywords in future editions. The new lint is
called `keyword_idents` and the old `async_idents` lint is registered as renamed
to this new lint.
As a proof of concept the `try` keyword was added to this list as it looks to be
listed as a keyword in the 2018 edition only. The `await` keyword was not added
as it's not listed as a keyword yet.
Closes#53077
[experimental]: Build LLVM with ThinLTO enabled (2nd attempt)
This is https://github.com/rust-lang/rust/pull/51207 revived. This time, I'd like to run actual performance tests to see if it improves compile times.
Add some more wording to module documentation regarding how
`Arc::clone()` works, as some users have assumed cloning Arc's
to work via dereferencing to inner value as follows:
use std::sync::Arc;
let myarc = Arc::new(1);
let myarcref = myarc.clone();
assert!(1 == myarcref);
Instead of the actual mechanic of referencing the existing
Arc value:
use std::sync::Arg;
let myarc = Arc::new(1);
let myarcref = myarc.clone();
assert!(myarcref == &myarc); // not sure if assert could assert this
in the real world
create a valid DefIdTable for proc macro crates
At least the incremental compilation code, and a few other places in the
compiler, require the CrateMetadata for a loaded target crate to contain a
valid DefIdTable for the DefIds in the target.
Previously, the CrateMetadata for a proc macro contained the crate's
"host" DefIdTable, which is of course incompatible with the "target"
DefIdTable, causing ICEs. This creates a DefIdTable that properly refers
to the "proc macro" DefIds.
Fixes#49482.
r? @michaelwoerister
Should we beta-nominate this?
