| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
As described in #57374, NLL currently produces unhelpful higher-ranked
trait bound (HRTB) errors when '-Zno-leak-check' is enabled.
This PR tackles one half of this issue - making the error message point
at the proper span. The error message itself is still the very generic
"higher-ranked subtype error", but this can be improved in a follow-up
PR.
The root cause of the bad spans lies in how NLL attempts to compute the
'blamed' region, for which it will retrieve a span for.
Consider the following code, which (correctly) does not compile:
```rust
let my_val: u8 = 25;
let a: &u8 = &my_val;
let b = a;
let c = b;
let d: &'static u8 = c;
```
This will cause NLL to generate the following subtype constraints:
d :< c
c :< b
b <: a
Since normal Rust lifetimes are covariant, this results in the following
region constraints (I'm using 'd to denote the lifetime of 'd',
'c to denote the lifetime of 'c, etc.):
'c: 'd
'b: 'c
'a: 'b
From this, we can derive that 'a: 'd holds, which implies that 'a: 'static
must hold. However, this is not the case, since 'a refers to 'my_val',
which does not outlive the current function.
When NLL attempts to infer regions for this code, it will see that the
region 'a has grown 'too large' - it will be inferred to outlive
'static, despite the fact that is not declared as outliving 'static
We can find the region responsible, 'd, by starting at the *end* of
the 'constraint chain' we generated above. This works because for normal
(non-higher-ranked) lifetimes, we generally build up a 'chain' of
lifetime constraints *away* from the original variable/lifetime.
That is, our original lifetime 'a is required to outlive progressively
more regions. If it ends up living for too long, we can look at the
'end' of this chain to determine the 'most recent' usage that caused
the lifetime to grow too large.
However, this logic does not work correctly when higher-ranked trait
bounds (HRTBs) come into play. This is because HRTBs have
*contravariance* with respect to their bound regions. For example,
this code snippet compiles:
```rust
let a: for<'a> fn(&'a ()) = |_| {};
let b: fn(&'static ()) = a;
```
Here, we require that 'a' is a subtype of 'b'. Because of
contravariance, we end up with the region constraint 'static: 'a,
*not* 'a: 'static
This means that our 'constraint chains' grow in the opposite direction
of 'normal lifetime' constraint chains. As we introduce subtypes, our
lifetime ends up being outlived by other lifetimes, rather than
outliving other lifetimes. Therefore, starting at the end of the
'constraint chain' will cause us to 'blame' a lifetime close to the original
definition of a variable, instead of close to where the bad lifetime
constraint is introduced.
This PR improves how we select the region to blame for 'too large'
universal lifetimes, when bound lifetimes are involved. If the region
we're checking is a 'placeholder' region (e.g. the region 'a' in
for<'a>, or the implicit region in fn(&())), we start traversing the
constraint chain from the beginning, rather than the end.
There are two (maybe more) different ways we generate region constraints for NLL:
requirements generated from trait queries, and requirements generated
from MIR subtype constraints. While the former always use explicit
placeholder regions, the latter is more tricky. In order to implement
contravariance for HRTBs, TypeRelating replaces placeholder regions with
existential regions. This requires us to keep track of whether or not an
existential region was originally a placeholder region. When we look for
a region to blame, we check if our starting region is either a
placeholder region or is an existential region created from a
placeholder region. If so, we start iterating from the beginning of the
constraint chain, rather than the end.
|
|
|
|
|
|
Now the first row of each basic block is always light instead of
changing seemingly at random.
|
|
|
|
|
|
|
|
|
|
This also tests that `&&[]` no longer causes an ICE in this PR (although
the test fails the borrow checker). This could be more complete.
|
|
Simplify interners
Some code readability improvements.
|
|
Add lower bound doctests for `saturating_{add,sub}` signed ints
Closes #64940
|
|
Fixes #64919. Suggest fix based on operator precendence.
Fixes https://github.com/rust-lang/rust/issues/64919
|
|
Remove unneeded `fn main` blocks from docs
## [No whitespace diff](https://github.com/rust-lang/rust/pull/64912/files?w=1)
|
|
syntax: cleanup param, method, and misc parsing
Do some misc cleanup of the parser:
- Method and parameter parsing is refactored.
- A parser for `const | mut` is introduced that https://github.com/rust-lang/rust/pull/64588 can reuse.
- Some other misc parsing.
Next up in a different PR:
- ~Implementing https://github.com/rust-lang/rust/issues/64252.~ -- maybe some other time...
- Heavily restructuring up `item.rs` which is a mess (hopefully, no promises ^^).
r? @petrochenkov
|
|
BTreeSet intersection, is_subset & difference optimizations
...based on the range of values contained; in particular, a massive improvement when these ranges are disjoint (or merely touching), like in the neg-vs-pos benchmarks already in liballoc. Inspired by #64383 but none of the ideas there worked out.
I introduced another variant in IntersectionInner and in DifferenceInner, because I couldn't find a way to initialize these iterators as empty if there's no empty set around.
Also, reduced the size of "large" sets in test cases - if Miri can't handle it, it was needlessly slowing down everyone.
|
|
apfloat: improve doc comments
r? @eddyb @nagisa
|
|
|
|
This is needed to dump graphviz results for the `IndirectlyMutableLocals` analysis.
|
|
|
|
Co-Authored-By: Oliver Scherer <github35764891676564198441@oli-obk.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
doctests
|
|
|
|
|
|
|
|
|
|
|
|
Deduplicate closure type errors
Closure typing obligations flow in both direcitons to properly infer
types. Because of this, we will get 2 type errors whenever there's
an unfulfilled obligation. To avoid this, we deduplicate them in the
`InferCtxt`.
|
|
r=estebank
Improve code clarity
No commit except 55b54285c811b6ab12bb0ba001126fd5b7d3bd09 address performance, just making the existing code more clear.
r? @estebank
|
|
Silence unreachable code lint from await desugaring
Fixes #61798.
This PR silences the unreachable code lint when it originates from within an await desugaring.
|
|
Add tests for some issues
Closes #50571
Closes #58022
Closes #58344
|
|
A small amount of tidying-up factored out from PR #64648
As requested by @Mark-Simulacrum, I put this in a separate commit to make it easier to review. (As far as I can tell, no violations of the policy here, and they are simply in a separate PR because they're not directly related to the import of that PR.)
r? @Mark-Simulacrum
|
|
Remove legacy grammar
Revival of #50835 & #55545
On the #wg-grammar discord there was agreement that enough progress has been made to be able to remove the legacy grammar.
r? @Centril @qmx
cc @rust-lang/wg-grammar
|
|
r=nikomatsakis
async/await: improve not-send errors
cc #64130.
```
note: future does not implement `std::marker::Send` because this value is used across an await
--> $DIR/issue-64130-non-send-future-diags.rs:15:5
|
LL | let g = x.lock().unwrap();
| - has type `std::sync::MutexGuard<'_, u32>`
LL | baz().await;
| ^^^^^^^^^^^ await occurs here, with `g` maybe used later
LL | }
| - `g` is later dropped here
```
r? @nikomatsakis
|
|
syntax: recover trailing `|` in or-patterns
Fixes https://github.com/rust-lang/rust/issues/64879.
For example (this also shows that we are sensitive to the typo `||`):
```
error: a trailing `|` is not allowed in an or-pattern
--> $DIR/remove-leading-vert.rs:33:11
|
LL | A || => {}
| - ^^ help: remove the `||`
| |
| while parsing this or-pattern starting here
|
= note: alternatives in or-patterns are separated with `|`, not `||`
```
r? @estebank
|
|
Stabilize macros in some more positions
- Fn-like macros and attribute macros in `extern` blocks
- Fn-like procedural macros in type positions
- ~Attribute macros on inline modules~ (moved to https://github.com/rust-lang/rust/pull/64273)
Stabilization report: https://github.com/rust-lang/rust/pull/63931#issuecomment-526362396.
Closes https://github.com/rust-lang/rust/issues/49476
cc https://github.com/rust-lang/rust/issues/54727
|
|
syntax: Support modern attribute syntax in the `meta` matcher
Where "modern" means https://github.com/rust-lang/rust/pull/57367:
```
PATH
PATH `(` TOKEN_STREAM `)`
PATH `[` TOKEN_STREAM `]`
PATH `{` TOKEN_STREAM `}`
```
Unfortunately, `meta` wasn't future-proofed using the `FOLLOW` token set like other matchers (https://github.com/rust-lang/rust/issues/34011), so code like `$meta:meta {` or `$meta:meta [` may break, and we need a crater run to find out how often this happens in practice.
Closes https://github.com/rust-lang/rust/issues/49629 (by fully supporting `meta` rather than removing it.)
|
|
It's not necessary.
|
|
It's only used in two places, and the code is shorter and more readable
with it gone.
|
