Turn quadratic time on number of impl blocks into linear time
Previously, if you had a lot of inherent impl blocks on a type like:
```Rust
struct Foo;
impl Foo { fn foo_1() {} }
// ...
impl Foo { fn foo_100_000() {} }
```
The compiler would be very slow at processing it, because
an internal algorithm would run in O(n^2), where n is the number
of impl blocks. Now, we add a new algorithm that allocates but
is faster asymptotically.
Comparing rustc nightly with a local build of rustc as of this PR (results in seconds):
| N | real time before | real time after |
| - | - | - |
| 4_000 | 0.57 | 0.46 |
| 8_000 | 1.31 | 0.84 |
| 16_000 | 3.56 | 1.69 |
| 32_000 | 10.60 | 3.73 |
I've tuned up the numbers to make the effect larger than the startup noise of rustc, but the asymptotic difference should hold for smaller n as well.
Note: current state of the PR omits error messages if there are other errors present already. For now, I'm mainly interested in a perf run to study whether this issue is present at all. Please queue one for this PR. Thanks!
Re-word doc comment for rustc_middle::hir::place::Projection.
Also adds:
- Missing end stop punctuation, and
- Documentation links to `rustc_middle::mir::Place`.
`PatKind::Ref(PatKind::Ident(BindingMode::ByValue(Mutability::Mut), ..), ..)`
is an AST representing `&(mut ident)`. It was errorneously printed as
`&mut ident` which reparsed into a syntactically different AST.
This affected help diagnostics in the parser.
Make BoundRegion have a kind of BoungRegionKind
Split from #76814
Also includes making `replace_escaping_bound_vars` only return `T`
Going to r? `@lcnr`
Feel free to reassign
or_patterns: implement :pat edition-specific behavior
cc #54883 `@joshtriplett`
This PR implements the edition-specific behavior of `:pat` wrt or-patterns, as determined by the crater runs and T-lang consensus in https://github.com/rust-lang/rust/issues/54883#issuecomment-745509090.
I believe this can unblock stabilization of or_patterns.
r? `@petrochenkov`
const_evaluatable_checked: fix occurs check
fixes#79615
this is kind of a hack because we use `TypeRelation` for both the `Generalizer` and the `ConstInferUnifier` but i am not sure if there is a useful way to disentangle this without unnecessarily duplicating some code.
The error in the added test is kind of unavoidable until we erase the unused substs of `ConstKind::Unevaluated`. We talked a bit about this in the cg lazy norm meeting (https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/lazy_normalization_consts)
Improve and fix diagnostics of exhaustiveness checking
Primarily, this fixes https://github.com/rust-lang/rust/issues/56379. This also fixes incorrect interactions between or-patterns and slice patterns that I discovered while working on #56379. Those two examples show the incorrect diagnostics:
```rust
match &[][..] {
[true] => {}
[true // detected as unreachable but that's not true
| false, ..] => {}
_ => {}
}
match (true, None) {
(true, Some(_)) => {}
(false, Some(true)) => {}
(true | false, None | Some(true // should be detected as unreachable
| false)) => {}
}
```
I did not measure any perf impact. However, I suspect that [`616ba9f`](616ba9f9f7) should have a negative impact on large or-patterns. I'll see what the perf run says; I have optimization ideas up my sleeve if needed.
EDIT: I initially had a noticeable perf impact that I thought unavoidable. I then proceeded to avoid it x)
r? `@varkor`
`@rustbot` label +A-exhaustiveness-checking
Stabilize or_insert_with_key
Stabilizes the `or_insert_with_key` feature from https://github.com/rust-lang/rust/issues/71024. This allows inserting key-derived values when a `HashMap`/`BTreeMap` entry is vacant.
The difference between this and `.or_insert_with(|| ... )` is that this provides a reference to the key to the closure after it is moved with `.entry(key_being_moved)`, avoiding the need to copy or clone the key.
passes: prohibit invalid attrs on generic params
Fixes#78957.
This PR modifies the `check_attr` pass so that attribute placement on generic parameters is checked for validity.
r? `@lcnr`
Register nodes that we've reused from the previous session explicitly
with `OnDiskCache`. Previously, we relied on this happening as a side
effect of accessing the nodes in the `PreviousDepGraph`. For the sake of
performance and avoiding unintended side effects, register explictily.
This is elegant but a bit of a perf gamble. That said, or-patterns
rarely have many branches and it's easy to optimize or revert if we ever
need to. In the meantime simpler code is worth it.
