remove keys w/ skolemized regions from proj cache when popping skolemized regions
This addresses #37154 (a regression). The projection cache was incorrectly caching the results for skolemized regions -- when we pop skolemized regions, we are supposed to drop cache keys for them (just as we remove those skolemized regions from the region inference graph). This is because those skolemized region numbers will be reused later with different meaning (and we have determined that the old ones don't leak out in any meaningful way).
I did a *somewhat* aggressive fix here of only removing keys that mention the skolemized regions. One could imagine just removing all keys added since we started the skolemization (as indeed I did in my initial commit). This more aggressive fix required fixing a latent bug in `TypeFlags`, as an aside.
I believe the more aggressive fix is correct; clearly there can be entries that are unrelated to the skoelemized region, and it's a shame to remove them. My one concern was that it *is* possible I believe to have some region variables that are created and related to skolemized regions, and maybe some of them could end up in the cache. However, that seems harmless enough to me-- those relations will be removed, and couldn't have impacted how trait resolution proceeded anyway (iow, the cache entry is not wrong, though it is kind of useless).
r? @pnkfelix
cc @arielb1
TRPL: guessing game: minor clarification
The original text is correct and exact, but might confuse a non-English speaker (at least I was confused), so I made it a bit more plain (see https://github.com/rust-lang/rust/issues/37307).
I know minor wording changes like these are affected by personal style, so I'd understand if you don't find this useful.
r? @steveklabnik
Add error explaination for E0182, E0230 and E0399
This PR adds some error descriptions requested in issue https://github.com/rust-lang/rust/issues/32777.
r? @GuillaumeGomez
Specifically this adds descriptions for
E0182 - unexpected binding of associated item in expression path
E0230 - missing type parameter from on_unimplemented description
E0399 - overriding a trait type without re-implementing default methods
syntax: Tweak path parsing logic
Associated paths starting with `<<` are parsed in patterns.
Paths like `self::foo::bar` are interpreted as paths and not as `self` arguments in methods (cc @matklad).
Now, I believe, *all* paths are consistently parsed greedily in case of ambiguity.
Detection of `&'a mut self::` requires pretty large (but still fixed) lookahead, so I had to increase the size of parser's lookahead buffer.
Curiously, if `lookahead_distance >= lookahead_buffer_size` was used previously, the parser hung forever, I fixed this as well, now it ICEs.
r? @jseyfried
macros: Future proof `#[no_link]`
This PR future proofs `#[no_link]` for macro modularization (cc #35896).
First, we resolve all `#[no_link] extern crate`s. `#[no_link]` crates without `#[macro_use]` or `#[macro_reexport]` are not resolved today, this is a [breaking-change]. For example,
```rust
```
Any breakage can be fixed by simply removing the `#[no_link] extern crate`.
Second, `#[no_link] extern crate`s will define an empty module in type namespace to eventually allow importing the crate's macros with `use`. This is a [breaking-change], for example:
```rust
mod syntax {} //< This becomes a duplicate error.
```
r? @nrc
Enable line number debuginfo in releases
This commit enables by default passing the `-C debuginfo=1` argument to the
compiler for the stable, beta, and nightly release channels. A new configure
option was also added, `--enable-debuginfo-lines`, to enable this behavior in
developer builds as well.
Closes#36452
Detect local-rebuild by just the MAJOR.MINOR version
A new point-release shouldn't change any language semantics, so a local
stage0 that matches MAJOR.MINOR version should still be considered a
local-rebuild as far as `--cfg stageN` features go.
e.g. `1.14.0` should be considered a local-rebuild for any `1.14.X`.
(Bootstrap keys used to be an issue too, until #37265.)
Don't enqueue onto a disabled dep_graph.
This commit guards all calls to `DepGraphThreadData::enqueue` with a
check to make sure it is enabled. This avoids some useless allocation
and vector manipulations when it is disabled (i.e. when incremental
compilation is off) which improves speed by 1--2% on most of the
rustc-benchmarks.
This commit has an observable functional change: when the dep_graph is
disabled its `shadow_graph` will no longer receive messages. This should
be ok because these message are only used when debug assertions are
enabled.
r? @nikomatsakis
prefer `if let` to match with `None => { }` arm in some places
In #34268 (8531d581), we replaced matches of None to the unit value `()`
with `if let`s in places where it was deemed that this made the code
unambiguously clearer and more idiomatic. In #34638 (d37edef9), we did
the same for matches of None to the empty block `{}`.
A casual observer, upon seeing these commits fly by, might suppose that
the matter was then settled, that no further pull requests on this
utterly trivial point of style could or would be made. Unless ...
It turns out that sometimes people write the empty block with a space in
between the braces. Who knew?
