Skip to content

NLL doesn't check user type annotations are well-formed #54620

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

Closed
matthewjasper opened this issue Sep 27, 2018 · 2 comments
Closed

NLL doesn't check user type annotations are well-formed #54620

matthewjasper opened this issue Sep 27, 2018 · 2 comments
Assignees
Labels
A-NLL Area: Non-lexical lifetimes (NLL) E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. NLL-sound Working towards the "invalid code does not compile" goal

Comments

@matthewjasper
Copy link
Contributor

For example, this code is accepted with NLL enabled:

fn call2<'a, 'b>(a: &'a usize, b: &'b usize) {
let z: Option<&'b &'a usize> = None;//~ ERROR E0623
}
fn call3<'a, 'b>(a: &'a usize, b: &'b usize) {
let y: Paramd<'a> = Paramd { x: a };
let z: Option<&'b Paramd<'a>> = None;//~ ERROR E0623
}
fn call4<'a, 'b>(a: &'a usize, b: &'b usize) {
let z: Option<&'a &'b usize> = None;//~ ERROR E0623
}

cc #47184

@matthewjasper matthewjasper added A-NLL Area: Non-lexical lifetimes (NLL) NLL-sound Working towards the "invalid code does not compile" goal labels Sep 27, 2018
@nikomatsakis nikomatsakis added this to the Edition 2018 RC 2 milestone Oct 2, 2018
@nikomatsakis
Copy link
Contributor

(Related: #54105)

I imagine that the way to fix this is that we have to prove a WellFormed predicate with-respect-to the user-given type annotations:

self.prove_predicates(
sig.inputs().iter().map(|ty| ty::Predicate::WellFormed(ty)),
term_location.to_locations(),
ConstraintCategory::Boring,
);

Probably the place to do this is on the relate_type_and_user_type function:

fn relate_type_and_user_type(
&mut self,
a: Ty<'tcx>,
v: ty::Variance,
b: CanonicalTy<'tcx>,
locations: Locations,
category: ConstraintCategory,
) -> Fallible<()> {

One complication, though, is that the user-given type is a "canonical type":

which means that it might have _ and things encoded in it. However, the relate_type_and_user_type fn already creates type variables representing each of those _ and things. Right now it just stores them into a vector:

/// As we execute, the type on the LHS *may* come from a canonical
/// source. In that case, we will sometimes find a constraint like
/// `?0 = B`, where `B` is a type from the RHS. The first time we
/// find that, we simply record `B` (and the list of scopes that
/// tells us how to *interpret* `B`). The next time we encounter
/// `?0`, then, we can read this value out and use it.
///
/// One problem: these variables may be in some other universe,
/// how can we enforce that? I guess I could add some kind of
/// "minimum universe constraint" that we can feed to the NLL checker.
/// --> also, we know this doesn't happen
canonical_var_values: IndexVec<CanonicalVar, Option<Kind<'tcx>>>,

I guess what we would need to do is -- after equating, relating, whatever -- to instantiate the canonical type with these final values (presumably using the substitute function), and then create the WellFormed predicate.

@nikomatsakis nikomatsakis added the E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. label Oct 2, 2018
@blitzerr blitzerr self-assigned this Oct 2, 2018
@blitzerr
Copy link
Contributor

blitzerr commented Oct 5, 2018

The issue is that this code compiles and executes file with NLL enabled as you can see here. But with NLL turned off, it errors out as here.
This RFC (unrelated) but helps defined what wellFormed types are.

bors added a commit that referenced this issue Oct 12, 2018
[NLL] Check user types are well-formed

Also contains a change of span for AscribeUserType.
I'm not quite sure if this was what @nikomatsakis was thinking.

Closes #54620

r? @nikomatsakis
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-NLL Area: Non-lexical lifetimes (NLL) E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. NLL-sound Working towards the "invalid code does not compile" goal
Projects
None yet
Development

No branches or pull requests

3 participants