| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
This PR will fix some typos detected by [typos].
I only picked the ones I was sure were spelling errors to fix, mostly in
the comments.
[typos]: https://github.com/crate-ci/typos
|
|
|
|
|
|
|
|
|
|
issues97981
|
|
|
|
|
|
Use revisions to track NLL test output (part 1)
The idea here is 2 fold: 1) When we eventually do make NLL default on, that PR should be systematic in "delete revisions and corresponding error annotations" 2) This allows us to look at test NLL outputs in chunks. (Though, I've opted here not to "mark" these tests. There are some tests with NLL revisions *now* that will be missed. I expect we do a second pass once we have all the tests with NLL revisions; these tests should be easy enough to eyeball.)
The actual review here should be "easy", but a bit tedious. I expect we should manually go through each test output and confirm it's okay.
The majority of these are either: 1) Only span change (the one I see most common is highlighting an entire function call, rather than just the function name in that call) 2) "E0308 mismatched types" -> "lifetime does not live long enough" 3) "E0495 cannot infer an appropriate lifetime for lifetime parameter" -> "lifetime does not live long enough" 4) "E0312 lifetime of reference outlives lifetime of borrowed content" -> "lifetime does not live long enough" 5) "E0759 `XXX` has an anonymous lifetime `'_` but it needs to satisfy a `'static` lifetime requirement" -> "lifetime does not live long enough" 6) "E0623 lifetime mismatch" -> "lifetime does not live long enough"
Other than the now lack of an error code, most of these look fine (with most giving more helpful suggestions now).
`rfc1623` output isn't great.
cc ``@marmeladema`` if you want to look through these
Let's r? ``@oli-obk`` since you've commented on the Zulip thread ;)
|
|
|
|
|
|
type parameter
The user wrote the bound, so it's obvious they want a type.
|
|
During borrowchecking, we treat any free (early-bound) regions on
the 'defining type' as `RegionClassification::External`. According
to the doc comments, we should only have 'external' regions when
checking a closure/generator.
However, a plain function can also have some if its regions
be considered 'early bound' - this occurs when the region is
constrained by an argument, appears in a `where` clause, or
in an opaque type. This was causing us to incorrectly mark these
regions as 'external', which caused some diagnostic code
to act as if we were referring to a 'parent' region from inside
a closure.
This PR marks all instantiated region variables as 'local'
when we're borrow-checking something other than a
closure/generator/inline-const.
|
|
Instead of special-casing mutable pointers/references, we
now support general generic types (currently, we handle
`ty::Ref`, `ty::RawPtr`, and `ty::Adt`)
When a `ty::Adt` is involved, we show an additional note
explaining which of the type's generic parameters is
invariant (e.g. the `T` in `Cell<T>`). Currently, we don't
explain *why* a particular generic parameter ends up becoming
invariant. In the general case, this could require printing
a long 'backtrace' of types, so doing this would be
more suitable for a follow-up PR.
We still only handle the case where our variance switches
to `ty::Invariant`.
|
|
Consider types appearing in const expressions to be invariant
This is an approach to fix #80977.
Currently, a type parameter which is only used in a constant expression is considered bivariant and will trigger error E0392 *"parameter T is never used"*.
Here is a short example:
```rust
pub trait Foo {
const N: usize;
}
struct Bar<T: Foo>([u8; T::N])
where [(); T::N]:;
```
([playgound](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2015&gist=b51a272853f75925e72efc1597478aa5))
While it is possible to silence this error by adding a `PhantomData<T>` field, I think the better solution would be to make `T` invariant.
This would be analogous to the invariance constraints added for associated types.
However, I'm quite new to the compiler and unsure whether this is the right approach.
r? ``@varkor`` (since you authored #60058)
|
|
|
|
|
|
same
|
|
Fixes #73159
This is similar to #69350 - if the user didn't initially
write out a 'static lifetime, adding 'static in response to
a lifetime error is usually the wrong thing to do.
|
|
|
|
|
|
If a symbol name can only be imported from one place for a type, and
as long as it was not glob-imported anywhere in the current crate, we
can trim its printed path and print only the name.
This has wide implications on error messages with types, for example,
shortening `std::vec::Vec` to just `Vec`, as long as there is no other
`Vec` importable anywhere.
This adds a new '-Z trim-diagnostic-paths=false' option to control this
feature.
On the good path, with no diagnosis printed, we should try to avoid
issuing this query, so we need to prevent trimmed_def_paths query on
several cases.
This change also relies on a previous commit that differentiates
between `Debug` and `Display` on various rustc types, where the latter
is trimmed and presented to the user and the former is not.
|
|
|
|
Specific labels when referring to "expected" and "found" types
|
|
Add outlives suggestions for some lifetime errors
This PR implements suggestion diagnostics for some lifetime mismatch errors. When the borrow checker finds that some lifetime 'a doesn't outlive some other lifetime 'b that it should outlive, then in addition to the current lifetime error, we also emit a suggestion for how to fix the problem by adding a bound:
- If a and b are normal named regions, suggest to add the bound `'a: 'b`
- If b is static, suggest to replace a with static
- If b also needs to outlive a, they must be the same, so suggest unifying them
We start with a simpler implementation that avoids diagnostic regression or implementation complexity:
- We only makes suggestions for lifetimes the user can already name (eg not closure regions or elided regions)
- For now, we only emit a help note, not an actually suggestion because it is significantly easier.
Finally, there is one hack: it seems that implicit regions in async fn are given the name '_ incorrectly. To avoid suggesting '_: 'x, we simply filter out such lifetimes by name.
For more info, see this internals thread:
https://internals.rust-lang.org/t/mechanical-suggestions-for-some-borrow-checker-errors/9049/3
TL;DR Make suggestions to add a `where 'a: 'b` constraint for some lifetime errors. Details are in the paper linked from the internals thread above.
r? @estebank
TODO
- [x] Clean up code
- [x] Only make idiomatic suggestions
- [x] don't suggest naming `&'a self`
- [x] rather than `'a: 'static`, suggest replacing `'a` with `'static`
- [x] rather than `'a: 'b, 'b: 'a`, suggest replacing `'a` with `'b` or vice versa
- [x] Performance (maybe need a perf run when this is closer to the finish line?)
- perf run was clean...
- EDIT: perf run seems to only check non-error performance... How do we check that error performance didn't regress?
- [x] Needs ui tests
- [x] Integrate the `help` message into the main lifetime `error`
|
|
|
|
|
|
|
|
|
|
|
|
See #64931.
|
|
|
|
Make it clearer that a type or lifetime argument not being used can be
fixed by referencing it in a struct's fields, not just using `PhathomData`.
|
|
|
|
|
|
|
|
|
|
Correct unused parameter diagnostic
The message was incorrect for unused lifetime parameters. There's no need to be specific.
|
|
|
|
|
|
|
|
|
|
|
|
I also added `// skip-codegen` to each one, to address potential concerns
that this change would otherwise slow down our test suite spending time
generating code for files that are really just meant to be checks of
compiler diagnostics.
(However, I will say: My preference is to not use `// skip-codegen` if
one can avoid it. We can use all the testing of how we drive LLVM that
we can get...)
(Updated post rebase.)
|
|
|
|
This commit updates the test output for the updated NLL compare mode
that uses `-Z borrowck=migrate` rather than `-Z borrowck=mir`. The
previous commit changes `compiletest` and this commit only updates
`.nll.stderr` files.
|
|
Also change the order of the fake read for let and the AscribeUserType,
so that we use the better span and message from the fake read in errors.
|
