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?
This splits "valid" into "valid for reads" and "valid for writes", and
also adds the concept of operation size to validity. Now functions which
operate on sequences state that e.g. pointer args must be "valid for reads of
size x".
