Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[NLL] Poor spans for mismatched types #95686

Closed
jackh726 opened this issue Apr 5, 2022 · 2 comments
Closed

[NLL] Poor spans for mismatched types #95686

jackh726 opened this issue Apr 5, 2022 · 2 comments
Assignees
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-NLL Area: Non-lexical lifetimes (NLL) NLL-diagnostics Working towards the "diagnostic parity" goal T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@jackh726
Copy link
Member

jackh726 commented Apr 5, 2022

The src/test/ui/rfc1623.rs test currently gives objectively worse output spans under NLL. Specifically, without NLL, we point to the specific field that isn't general enough. With NLL, we point at the outer struct creation.

Relevant excerpt with error labels:

struct SomeStruct<'x, 'y, 'z: 'x> {
    foo: &'x Foo<'z>,
    bar: &'x Bar<'z>,
    f: &'y dyn for<'a, 'b> Fn(&'a Foo<'b>) -> &'a Foo<'b>,
}
fn id<T>(t: T) -> T {
    t
}
static SOME_STRUCT: &SomeStruct = &SomeStruct {
    //[nll]~^ ERROR mismatched types
    //[nll]~| ERROR mismatched types
    //[nll]~| ERROR implementation of `FnOnce` is not general enough
    //[nll]~| ERROR implementation of `FnOnce` is not general enough
    foo: &Foo { bools: &[false, true] },
    bar: &Bar { bools: &[true, true] },
    f: &id,
    //[base]~^ ERROR implementation of `FnOnce` is not general enough
};
@jackh726 jackh726 added A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. A-NLL Area: Non-lexical lifetimes (NLL) NLL-diagnostics Working towards the "diagnostic parity" goal labels Apr 5, 2022
@Aaron1011 Aaron1011 self-assigned this Apr 19, 2022
@Aaron1011
Copy link
Member

This is caused by the way that we handle region constraints for promoteds. We change the location of all constraints to point to the location of the promoted:

let locations = location.to_locations();
for constraint in constraints.outlives().iter() {
let mut constraint = constraint.clone();
constraint.locations = locations;

However, the location is used for both borrow-checking and diagnostics. As a result, any errors that get 'blamed' on a promoted will have the span of the entire promoted. We should track the span separately from the location, so that we can adjust the (semantic) location and diagnostic span separately.

@jackh726
Copy link
Member Author

Span here is better thanks to #96236. Now just a nearly duplicate error, which we can track in #96211.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-NLL Area: Non-lexical lifetimes (NLL) NLL-diagnostics Working towards the "diagnostic parity" goal T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

2 participants