Stream: t-compiler/wg-nll

Topic: #47184-user-given-type-annotations


nikomatsakis (Aug 06 2018 at 13:02, on Zulip):

So this is one of the major remaining bugs to fix

nikomatsakis (Aug 06 2018 at 13:02, on Zulip):

I was talking about it with @pnkfelix and we thought we could brainstorm how to fix

nikomatsakis (Aug 06 2018 at 13:02, on Zulip):

(cc @davidtwco who did the existing work on this)

nikomatsakis (Aug 06 2018 at 13:02, on Zulip):

I think the first thing is to try to catalog where the points of concern are

nikomatsakis (Aug 06 2018 at 13:03, on Zulip):

the only case I that I believe works today is this one:

nikomatsakis (Aug 06 2018 at 13:03, on Zulip):
let x: T = ...;

where x is a single variable, not a pattern like _ or (x, y)

pnkfelix (Aug 06 2018 at 13:04, on Zulip):

should we perhaps transcribe @davidtwco 's comment with a categorization of cases remaing, transcribe that to the Issue Descriptioin

pnkfelix (Aug 06 2018 at 13:04, on Zulip):

with check boxes, even? :)

nikomatsakis (Aug 06 2018 at 13:04, on Zulip):

the other cases then are :

pnkfelix (Aug 06 2018 at 13:04, on Zulip):

ohj it had check boxes

nikomatsakis (Aug 06 2018 at 13:04, on Zulip):

oh yes I think I remember going through that exercise with @davidtwco before :)

pnkfelix (Aug 06 2018 at 13:04, on Zulip):

i'm going to do it

nikomatsakis (Aug 06 2018 at 13:05, on Zulip):

but it looks like that list is roughly the same as mine

nikomatsakis (Aug 06 2018 at 13:05, on Zulip):

I'm not entirely sure what

Lifetimes defined but not used, this currently only occurs in the yield-subtype.rs test but that will also need resolved.

was referring to, have to check that test, but I think it's maybe the (unrelated, really) issue #51351 that @mikhail-m1 fixed recently

nikomatsakis (Aug 06 2018 at 13:06, on Zulip):

(yes, I think I am correct)

nikomatsakis (Aug 06 2018 at 13:06, on Zulip):

yield-subtype.rs:

fn bar<'a>() {
    let a: &'static str = "hi";
    let b: &'a str = a;

    || {
        yield a;
        yield b;
    };
}
nikomatsakis (Aug 06 2018 at 13:07, on Zulip):

so there are a couple of aspects to this

nikomatsakis (Aug 06 2018 at 13:07, on Zulip):

I think that the case of specifying types in substitutions is somewhat different from the other cases

nikomatsakis (Aug 06 2018 at 13:07, on Zulip):

e.g., like foo::<&'a u32> or something

nikomatsakis (Aug 06 2018 at 13:07, on Zulip):

currently, in MIR, those types are just Ty that are embedded in the MIR directly

nikomatsakis (Aug 06 2018 at 13:08, on Zulip):

so I think that something like let x = foo::<&'a u32>(&22) would be a constant reference

nikomatsakis (Aug 06 2018 at 13:10, on Zulip):

e.g.

TMP0 = foo::<&'a u32>
TMP1 = TMP0(&22)
nikomatsakis (Aug 06 2018 at 13:10, on Zulip):

one thought I had for this is that the MIR could stop embedding Ty<'tcx> directly

nikomatsakis (Aug 06 2018 at 13:10, on Zulip):

and instead include a TypeIndex

nikomatsakis (Aug 06 2018 at 13:10, on Zulip):

and the Mir struct would have a list of types

nikomatsakis (Aug 06 2018 at 13:11, on Zulip):

(probably and substs)

nikomatsakis (Aug 06 2018 at 13:11, on Zulip):

and then we could have constraints

nikomatsakis (Aug 06 2018 at 13:11, on Zulip):

i'm not sure how easy that would be though, might be horribly annoying

pnkfelix (Aug 06 2018 at 13:11, on Zulip):

the goal would be...

nikomatsakis (Aug 06 2018 at 13:11, on Zulip):

basically the challenge is.. how do we distinguish "this is a region that user wrote"

nikomatsakis (Aug 06 2018 at 13:11, on Zulip):

from "this is a region we inferred"

nikomatsakis (Aug 06 2018 at 13:12, on Zulip):

alternatively we could, in those constraints we add, have some other way to "uniquely identify" the substs we are constraining

nikomatsakis (Aug 06 2018 at 13:12, on Zulip):

but it seems tricky to do

nikomatsakis (Aug 06 2018 at 13:13, on Zulip):

so the MIR after my change might "look like"

B0 {
  TMP0 = foo::<S0>
  TMP1 = TMP0(&22)
}

Substs {
  S0 = [&'a u32]
}

and then a side constraint like User [ S0 = &'a u32 ] because that was given from the user

nikomatsakis (Aug 06 2018 at 13:14, on Zulip):

let me show a slightly more extended example...

nikomatsakis (Aug 06 2018 at 13:14, on Zulip):

foo::<&u32, _>(...)

nikomatsakis (Aug 06 2018 at 13:14, on Zulip):

might wind up as foo::<S0> with

substs {
  S0 = [&'a u32, &'b u32] // final inferred values
}

user {
  S0 = [&'a u32, _] // a canonical type
}
nikomatsakis (Aug 06 2018 at 13:15, on Zulip):

eventually the "inferred" values will actually be erased values

nikomatsakis (Aug 06 2018 at 13:15, on Zulip):

anyway, that's the rough idea I had for modifying the MIr. The next question is how to generate those user { .. } things, but let's leave that aside for the second :)

nikomatsakis (Aug 06 2018 at 13:19, on Zulip):

@pnkfelix thoughts?

pnkfelix (Aug 06 2018 at 13:20, on Zulip):

i guess it seems more complicated than what I had idealized

davidtwco (Aug 06 2018 at 13:20, on Zulip):

I'm still happy to help out on this issue with any parts of it where I might be of use.

pnkfelix (Aug 06 2018 at 13:20, on Zulip):

but I also am sure you know more about the problems that are going t oarise

pnkfelix (Aug 06 2018 at 13:21, on Zulip):

(I think part of my problem is that I've forgotten your explanation for why emitting more UserAssertTy stmts is not going to suffice for all cases...)

pnkfelix (Aug 06 2018 at 13:23, on Zulip):

e.g. for turbofish cases: if they wrote "2048".parse::<u32>(), I would have thought we could emit UserAssertTy

pnkfelix (Aug 06 2018 at 13:23, on Zulip):

anyway I have to go AFK

nikomatsakis (Aug 06 2018 at 13:26, on Zulip):

ok ttyl

nikomatsakis (Aug 06 2018 at 13:27, on Zulip):

we might be able to do UserAssertTy in that case, though it seems complicated, but I don't know about stuff like x = foo::<...>(...) calls

nikomatsakis (Aug 06 2018 at 13:27, on Zulip):

since then the type parameter may not show up in any variable's type necessarily

nikomatsakis (Aug 06 2018 at 13:27, on Zulip):

@davidtwco I definitely think this is going to need some refactoring / exploration help :)

pnkfelix (Aug 06 2018 at 13:44, on Zulip):

(oh yes, now I remember thinking that maybe UserAssertTy should take a Place ratehr than a Local or something along those lines

nikomatsakis (Aug 06 2018 at 13:53, on Zulip):

so there is one other problem which is that things like let PATTERN: TYPE don't obviously have a type to annotate -- there I think we probably do want to extend UserAssertTy, except that it would take -- not, I think -- a Place but rather some kind of "pattern-like-thing"?

nikomatsakis (Aug 06 2018 at 13:53, on Zulip):

it's probably worth exploring those cases a bit too

nikomatsakis (Aug 06 2018 at 13:53, on Zulip):

there is e.g.

nikomatsakis (Aug 08 2018 at 21:50, on Zulip):

I'm making some progress here

nikomatsakis (Aug 08 2018 at 21:50, on Zulip):

I've got a branch that is now recording -- as part of type-check -- the user-given annotations in various fns and method scenarios

nikomatsakis (Aug 08 2018 at 21:53, on Zulip):

e.g., these cases seem to work

#[rustc_dump_user_substs]
fn main() {
    // Here: nothing is given. In fact, it'd be sort of nice to not
    // have any annotation here.
    let x = foo; //~ ERROR [?0]
    x(22);

    // Here: `u32` is given.
    let x = foo::<u32>; //~ ERROR [u32]
    x(22);

    // Here: we only want the `T` to be given, the rest should be variables.
    let x = <_ as Bazoom<u32>>::method::<_>; //~ ERROR [?0, u32, ?1]
    x(&22, 44, 66);

    // Here: all are given
    let x = <u8 as Bazoom<u16>>::method::<u32>; //~ ERROR [u8, u16, u32]
    x(&22, 44, 66);

    // Here: we want in particular that *only* the method `U`
    // annotation is given, the rest are variables.
    let y = 22_u32;
    y.method::<u32>(44, 66); //~ ERROR [?0, ?1, u32]

    // Here: nothing is given. In fact, it'd be sort of nice to not
    // have any annotation here.
    let y = 22_u32;
    y.method(44, 66); //~ ERROR [?0, ?1, ?2]
}
nikomatsakis (Aug 08 2018 at 21:53, on Zulip):

well, by work I mean "we record the write thing"

nikomatsakis (Aug 08 2018 at 21:53, on Zulip):

I have some thoughts about how to encode it in the MIR level, I think there is something relatively simple we can do

davidtwco (Aug 08 2018 at 22:02, on Zulip):

:tada:

nikomatsakis (Aug 08 2018 at 22:04, on Zulip):

@davidtwco this won't help at all with the pattern case

nikomatsakis (Aug 08 2018 at 22:04, on Zulip):

I think we just have to handle that separately

nikomatsakis (Aug 08 2018 at 22:04, on Zulip):

that's actually the most common, of course

davidtwco (Aug 08 2018 at 22:05, on Zulip):

Will you be able to funnel all these cases through the same code that unpacks the complex cases? Or will they need their own handling?

nikomatsakis (Aug 08 2018 at 22:05, on Zulip):

which do you mean by "these cases", sorry?

davidtwco (Aug 08 2018 at 22:06, on Zulip):

All the different places you are pulling annotations from.

nikomatsakis (Aug 08 2018 at 22:29, on Zulip):

I think it will come down to two cases, basically:

nikomatsakis (Aug 08 2018 at 22:29, on Zulip):

pattern annotations on let

nikomatsakis (Aug 08 2018 at 22:29, on Zulip):

and other annotations

nikomatsakis (Aug 08 2018 at 22:29, on Zulip):

the latter is what I am focusing on now

nikomatsakis (Aug 08 2018 at 22:29, on Zulip):

I don't think those two cases will be particularly unified though

nikomatsakis (Aug 08 2018 at 23:22, on Zulip):

actually... I maybe take that back a bit. We may be able to re-use the UserAssertTy MIR statements

nikomatsakis (Aug 09 2018 at 16:05, on Zulip):

opened PR https://github.com/rust-lang/rust/pull/53225 — not a complete fix yet but covers a lot of the cases

nikomatsakis (Aug 31 2018 at 23:33, on Zulip):

this test passes now:

#![feature(nll)]

fn main() {
    let _: Vec<&'static String> = vec![&String::new()];
    //~^ ERROR borrowed value does not live long enough [E0597]

    let (_, a): (Vec<&'static String>, _) = (vec![&String::new()], 44);
    //~^ ERROR borrowed value does not live long enough [E0597]

    let (_a, b): (Vec<&'static String>, _) = (vec![&String::new()], 44);
    //~^ ERROR borrowed value does not live long enough [E0597]
}
nikomatsakis (Aug 31 2018 at 23:33, on Zulip):

(on my branch)

nikomatsakis (Sep 07 2018 at 19:29, on Zulip):

@pnkfelix and whomever else: I'd like to have another change to talk over what we want to do here

nikomatsakis (Sep 07 2018 at 19:29, on Zulip):

the more I think about it, the more unsure I am :)

nikomatsakis (Sep 07 2018 at 19:29, on Zulip):

maybe Monday?

pnkfelix (Sep 07 2018 at 21:07, on Zulip):

Sure Monday is good. I assume you meant to write “another chance ...”

nikomatsakis (Sep 07 2018 at 21:48, on Zulip):

yes :)

nikomatsakis (Sep 18 2018 at 20:44, on Zulip):

ok so on the topic of user-given type annotations...

I just wrote up some mentoring instructions for https://github.com/rust-lang/rust/issues/54331, describing how to handle the type ascription case.

I realize now how much stuff has yet to be added to rustc-guide :P

nikomatsakis (Sep 18 2018 at 20:44, on Zulip):

but @Santiago Pastorino and @Keith Yeung I had tagged both of you as possible folks for this

nikomatsakis (Sep 18 2018 at 20:44, on Zulip):

there is more than one case

nikomatsakis (Sep 18 2018 at 20:45, on Zulip):

it will require modifying the main type checker, as well as the "HAIR" and MIR construction...

Keith Yeung (Sep 18 2018 at 20:45, on Zulip):

does HIR/AST get lowered to HAIR first, before finally being lowered to MIR?

nikomatsakis (Sep 18 2018 at 20:45, on Zulip):

oh, dang it

nikomatsakis (Sep 18 2018 at 20:45, on Zulip):

yes, it does

nikomatsakis (Sep 18 2018 at 20:45, on Zulip):

just realized that I sort of left out a step

nikomatsakis (Sep 18 2018 at 20:45, on Zulip):

which is that we have to figure out how this will be reflected in MIR, and that is .. hmm. Potentially mildly tricky?

nikomatsakis (Sep 18 2018 at 20:45, on Zulip):

nah it's .. probably ok

nikomatsakis (Sep 18 2018 at 20:46, on Zulip):

well, we may have to make a new temporary or something, so that we can assert its type in MIR land

nikomatsakis (Sep 18 2018 at 20:46, on Zulip):

anyway the first few steps dont' require that

Santiago Pastorino (Sep 18 2018 at 20:53, on Zulip):

but @Santiago Pastorino and @Keith Yeung I had tagged both of you as possible folks for this

I can take this

Santiago Pastorino (Sep 18 2018 at 20:54, on Zulip):

I mean, unless @Keith Yeung really want to do it :)

Keith Yeung (Sep 18 2018 at 20:56, on Zulip):

i haven't really looked into it yet

nikomatsakis (Sep 18 2018 at 20:57, on Zulip):

there are other parts too

nikomatsakis (Sep 18 2018 at 20:57, on Zulip):

but I won't be able to write those up yet...

nikomatsakis (Sep 18 2018 at 20:57, on Zulip):

I am thinking mostly of what I described here

nikomatsakis (Sep 18 2018 at 20:57, on Zulip):

which may be enough to go on, but maybe not

Santiago Pastorino (Sep 18 2018 at 20:58, on Zulip):

i haven't really looked into it yet

me neither but I have no tasks so, I guess when I start taking a look at it I just start tackling it :P

Santiago Pastorino (Sep 18 2018 at 21:01, on Zulip):

there are other parts too

:+1:, I'm fine to do whatever is needed :)

Keith Yeung (Sep 18 2018 at 21:11, on Zulip):

i think i have an idea of what we wanna do for this issue right now

Keith Yeung (Sep 18 2018 at 21:14, on Zulip):

we have indeed missed a step

Keith Yeung (Sep 18 2018 at 21:14, on Zulip):

HAIR to MIR lowering

nikomatsakis (Sep 18 2018 at 21:16, on Zulip):

Yeah so the challenge here is that

Keith Yeung (Sep 18 2018 at 21:17, on Zulip):

but i think it's a matter of creating a new Rvalue variant?

Keith Yeung (Sep 18 2018 at 21:18, on Zulip):

or perhaps that is the challenge

Keith Yeung (Sep 18 2018 at 21:18, on Zulip):

figuring out exactly what kind of node we wanna generate

Keith Yeung (Sep 18 2018 at 21:18, on Zulip):

or really, what kind of statement

nikomatsakis (Sep 18 2018 at 21:18, on Zulip):

there is presently a AscribeUserType statement

nikomatsakis (Sep 18 2018 at 21:18, on Zulip):

https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/enum.StatementKind.html#variant.AscribeUserType

nikomatsakis (Sep 18 2018 at 21:19, on Zulip):

so we basically want to lower to that

Keith Yeung (Sep 18 2018 at 21:19, on Zulip):

ah, i see it

nikomatsakis (Sep 18 2018 at 21:20, on Zulip):

actually, I think I take back what I said about Adt

nikomatsakis (Sep 18 2018 at 21:20, on Zulip):

well, I don't know

nikomatsakis (Sep 18 2018 at 21:21, on Zulip):

yeah, I think we could refactor that, I stand by what I wrote ;)

nikomatsakis (Sep 18 2018 at 21:21, on Zulip):

but first things first

Keith Yeung (Sep 18 2018 at 21:23, on Zulip):

@Santiago Pastorino sorry, it looks like i got myself too invested in this right now :D mind if i tackle this instead?

nikomatsakis (Sep 18 2018 at 21:25, on Zulip):

heh :) I'll put @Santiago Pastorino to work somehow

Santiago Pastorino (Sep 18 2018 at 21:33, on Zulip):

:+1:

Keith Yeung (Sep 18 2018 at 23:13, on Zulip):

hmm... so i'm not sure what happens when we lower the HAIR expression to MIR

Keith Yeung (Sep 18 2018 at 23:13, on Zulip):

there are a couple of places that require changing

Keith Yeung (Sep 18 2018 at 23:14, on Zulip):

as_place.rs, as_rvalue.rs, category.rs and into.rs

Keith Yeung (Sep 18 2018 at 23:19, on Zulip):

category.rs should be easy -- we just return None, since it doesn't match any of the category listed

Keith Yeung (Sep 18 2018 at 23:49, on Zulip):

@nikomatsakis woah ok, now i'm feeling the trouble when attempting to lower it to MIR

Keith Yeung (Sep 18 2018 at 23:50, on Zulip):

AscribeUserType requires an expression as one of its fields

Keith Yeung (Sep 18 2018 at 23:50, on Zulip):

and in the ExprType variant you proposed, it doesn't contain any information about the expression that the ascription is applied to

Keith Yeung (Sep 18 2018 at 23:50, on Zulip):

perhaps we need to extend it to contain that

Keith Yeung (Sep 18 2018 at 23:55, on Zulip):

... in which case, we really need to rename ExprType to maybe TypeAscription

Keith Yeung (Sep 19 2018 at 00:04, on Zulip):

darn it, i mispoke

Keith Yeung (Sep 19 2018 at 00:04, on Zulip):

AscribeUserType requires a Place

Keith Yeung (Sep 19 2018 at 01:04, on Zulip):

ok, so here's what i'm thinking:

Keith Yeung (Sep 19 2018 at 01:06, on Zulip):

if i'm not mistaken, the only use of the Place field in AscribeUserType is to get the type of the Place here

Keith Yeung (Sep 19 2018 at 01:10, on Zulip):

given that, i wonder if we can just thread through a Ty instead of a Place, in which case this would help us in lowering the type ascriptions, since we can provide the Ty of the ascribed expression

nikomatsakis (Sep 19 2018 at 17:47, on Zulip):

@Keith Yeung so the HAIR node has to wrap an expression

nikomatsakis (Sep 19 2018 at 17:47, on Zulip):

and if/when it is lowered to a MIR operand, it has to store the result of evaluating that expression into a temporary, assert the type on that temporary, and then return that temporary as a MIR operand

nikomatsakis (Sep 19 2018 at 17:48, on Zulip):

(if it is lowered to a place, it can do something mildly different)

nikomatsakis (Sep 19 2018 at 17:48, on Zulip):

I can probably find an example of another HAIR form that works similarly

Keith Yeung (Sep 20 2018 at 07:55, on Zulip):

huh, that poses some trouble, in particular the way we attempt to categorize the expression during MIR construction

Keith Yeung (Sep 20 2018 at 07:57, on Zulip):

it is most likely better to be categorized as an Rvalue that can be generated by Into

Keith Yeung (Sep 20 2018 at 07:57, on Zulip):

but the fact that types can also be ascribed on places is a little problematic

nikomatsakis (Sep 20 2018 at 13:31, on Zulip):

@Keith Yeung I think there are other "dual mode" expressions

nikomatsakis (Sep 20 2018 at 13:31, on Zulip):

hmm

nikomatsakis (Sep 20 2018 at 13:31, on Zulip):

it seems like we don't

nikomatsakis (Sep 20 2018 at 13:32, on Zulip):

well, we can make multiple expressions then

nikomatsakis (Sep 20 2018 at 13:32, on Zulip):

since we do categorize a.b.c: Foo as a "place expression" in the HIR

nikomatsakis (Sep 20 2018 at 13:32, on Zulip):

and it's kind of important to preserve that

nikomatsakis (Sep 20 2018 at 13:33, on Zulip):

(That said, I think there is no fundamental reason we can't have the HAIR expression play two roles — but it might be simpler not to.)

Keith Yeung (Sep 20 2018 at 13:37, on Zulip):

I was thinking that you could do an analysis of what role the expression plays before you categorize it

Keith Yeung (Sep 20 2018 at 13:38, on Zulip):

There might be a function somewhere where you can input an expression, and it tells you whether it is acting as a place or an rvalue

nikomatsakis (Sep 20 2018 at 13:48, on Zulip):

there are such functions

nikomatsakis (Sep 20 2018 at 13:48, on Zulip):

when you say "expression" I don't quite know which stage of the IR you are referring to

nikomatsakis (Sep 20 2018 at 13:48, on Zulip):

e.g., for HAIR, there is Category::of

nikomatsakis (Sep 20 2018 at 13:49, on Zulip):

during typeck, we have is_place_expr that operates on the HIR

nikomatsakis (Sep 20 2018 at 13:49, on Zulip):

but there is no reason for that to be defined on the FnCtxt in particular, it could be moved very easily

nikomatsakis (Sep 20 2018 at 13:50, on Zulip):

crucially, though, you can see that a.b.c: Foo is categorized as a place-expr here

nikomatsakis (Sep 20 2018 at 13:50, on Zulip):

so I think what we would want to do is — when lowering HIR::ExprKind::Type to HAIR — check if it is a place-expression (using that fn, lifted out from typeck)

nikomatsakis (Sep 20 2018 at 13:51, on Zulip):

and, if so, create a HAIR expression like TypePlace versus TypeValue, or something like that

nikomatsakis (Sep 20 2018 at 13:51, on Zulip):

the only difference between the two being that the first one always decorates a "place" expression inside

nikomatsakis (Sep 20 2018 at 13:51, on Zulip):

so it doesn't need to create a temporary to ascribe the type

nikomatsakis (Sep 20 2018 at 13:51, on Zulip):

sound reasonable?

nikomatsakis (Sep 20 2018 at 13:51, on Zulip):

probably we need a better name for those HAIR nodes

nikomatsakis (Sep 20 2018 at 13:52, on Zulip):

maybe AscribeTypeToPlace or something

Keith Yeung (Sep 20 2018 at 14:09, on Zulip):

yes, that's exactly the kind of function that i'm thinking of using during MIR lowering, i.e. in the body of Category::of

Keith Yeung (Sep 20 2018 at 14:11, on Zulip):

but i suppose it also makes sense to use it during HAIR lowering

nikomatsakis (Sep 20 2018 at 14:11, on Zulip):

yes, that's exactly the kind of function that i'm thinking of using during MIR lowering, i.e. in the body of Category::of

MIR lowering already has this function

nikomatsakis (Sep 20 2018 at 14:11, on Zulip):

it's called Category::of :P

nikomatsakis (Sep 20 2018 at 14:12, on Zulip):

the point is, we don't currently at least have any nodes that require this "recursive setup" to figure out the answer

nikomatsakis (Sep 20 2018 at 14:12, on Zulip):

another option would be to try having Type do that

nikomatsakis (Sep 20 2018 at 14:12, on Zulip):

that is, to ask the base expression what category it has

Keith Yeung (Sep 20 2018 at 14:12, on Zulip):

indeed, that i didn't think of

nikomatsakis (Sep 20 2018 at 14:12, on Zulip):

but I think this may ultimately be a bit more complex

nikomatsakis (Sep 20 2018 at 14:12, on Zulip):

than figuring it out ahead of time in HAIR time

nikomatsakis (Sep 20 2018 at 14:13, on Zulip):

and in any case the MIR you want to generate is mildly different

Keith Yeung (Sep 20 2018 at 14:13, on Zulip):

yeah, it seems like it makes more sense to just create a new HAIR node

nikomatsakis (Sep 20 2018 at 14:13, on Zulip):

I guess i'm not sure, I'd probably try it the way I described first though

Keith Yeung (Sep 20 2018 at 20:47, on Zulip):

i have a slight problem -- where should i put is_place_expr?

Keith Yeung (Sep 20 2018 at 20:48, on Zulip):

i could make it a free-standing function in librustc_typeck/check/mod.rs, but i'm not sure if that's the best place to do so

nikomatsakis (Sep 20 2018 at 20:49, on Zulip):

it does not appear to use self

nikomatsakis (Sep 20 2018 at 20:49, on Zulip):

I would make it a method of hir::Expr

nikomatsakis (Sep 20 2018 at 20:49, on Zulip):

if at all possible

nikomatsakis (Sep 20 2018 at 20:49, on Zulip):

and hence put it in src/librustc/hir/mod.rs

Keith Yeung (Sep 21 2018 at 18:53, on Zulip):

status update: i'm onto the final step in actually asserting the ascribed type with the expression's type

nikomatsakis (Sep 21 2018 at 19:00, on Zulip):

@Keith Yeung nice!

Keith Yeung (Sep 21 2018 at 19:00, on Zulip):

actually, i'm not sure if i even need to do that

Keith Yeung (Sep 21 2018 at 19:01, on Zulip):

it seems to me that there's already code to assert the place's type with the ascribed type in MIR borrowck

Keith Yeung (Sep 21 2018 at 19:01, on Zulip):

so... yay?

pnkfelix (Sep 21 2018 at 19:04, on Zulip):

@Keith Yeung what did you end up doing about the problem described by @nikomatsakis here ?

Keith Yeung (Sep 21 2018 at 19:04, on Zulip):

oh, i wasn't aware of that

pnkfelix (Sep 21 2018 at 19:05, on Zulip):

i.e. I had assumed part of the problem was going to be generalizing the code so that you would assert that a Place matched not merely just a Ty, but rather a series of projections into the Ty

pnkfelix (Sep 21 2018 at 19:06, on Zulip):

(the main reason why that idea appeals to me is that I already tried to take the approach of descending the Type structuring eagerly, in order to make it match up with the Places in the pattern structure. But I couldn't get that to 100% work, while the idea posted there by Niko seems much more plausible...)

nikomatsakis (Sep 21 2018 at 19:28, on Zulip):

i.e. I had assumed part of the problem was going to be generalizing the code so that you would assert that a Place matched not merely just a Ty, but rather a series of projections into the Ty

@pnkfelix actually the steps that @Keith Yeung is working on now are orthogonal from that

nikomatsakis (Sep 21 2018 at 19:29, on Zulip):

that is, they are working on the type ascription and cast expressions

pnkfelix (Sep 21 2018 at 19:29, on Zulip):

oh sorry

nikomatsakis (Sep 21 2018 at 19:29, on Zulip):

but we should probably have somebody on that

nikomatsakis (Sep 21 2018 at 19:29, on Zulip):

if @Keith Yeung is game, it might make sense for them to continue

nikomatsakis (Sep 21 2018 at 19:29, on Zulip):

since their head is in the right space

Keith Yeung (Sep 21 2018 at 19:36, on Zulip):

i need to try and understand what the problem is...

pnkfelix (Sep 21 2018 at 19:37, on Zulip):

@Keith Yeung niko is right that its an orthogonal thing

pnkfelix (Sep 21 2018 at 19:37, on Zulip):

@Keith Yeung namely I thought you were working on the part about making bindings like let (a, b): Type; work

Keith Yeung (Sep 21 2018 at 19:37, on Zulip):

ah

Keith Yeung (Sep 21 2018 at 19:38, on Zulip):

i guess i'm surprised that relate_type_and_user_type doesn't "propagate downward to more complex type patterns"

Keith Yeung (Sep 21 2018 at 19:39, on Zulip):

so, say given that we have Foo<'static> as a expression type, i would've expected relate_type_and_user_type to be able to relate that with Foo<'a>

Keith Yeung (Sep 21 2018 at 19:40, on Zulip):

and tell us that there's a type mismatch

pnkfelix (Sep 21 2018 at 19:44, on Zulip):

well hold on

pnkfelix (Sep 21 2018 at 19:44, on Zulip):

the comment I linked is talking specifically about a pattern where the binding x is, well, "deep"

pnkfelix (Sep 21 2018 at 19:44, on Zulip):

let &Foo { x }: &Foo<'static> = ...;

pnkfelix (Sep 21 2018 at 19:45, on Zulip):

and so we end up descending the structure and trying to ascribe a type to x alone

pnkfelix (Sep 21 2018 at 19:45, on Zulip):

the problem you are outlining, when you say " say given that we have Foo<'static> as a expression type ..."

pnkfelix (Sep 21 2018 at 19:46, on Zulip):

I believe we can accomplish exactly what you describe, via relate_type_and_user_type; you just need to pass in the appropriate ty::Variance

pnkfelix (Sep 21 2018 at 19:46, on Zulip):

Unless I am just wrong about this?

nikomatsakis (Sep 21 2018 at 19:46, on Zulip):

you are not wrong :)

nikomatsakis (Sep 21 2018 at 19:47, on Zulip):

the thing we cannot (yet) do is to extract the implications of that annotation for x (that is, some field of Foo)

pnkfelix (Sep 21 2018 at 19:48, on Zulip):

By the way, I would be interested in trying to attack this problem. But I think #21114 is a better item for me to attack, since I think we can get other people to attack the former.

Keith Yeung (Sep 21 2018 at 20:00, on Zulip):

btw I've got a PR here https://github.com/rust-lang/rust/pull/54447

Keith Yeung (Sep 21 2018 at 20:00, on Zulip):

i might also want to do the refactoring that niko mentioned on the issue

lqd (Sep 21 2018 at 20:02, on Zulip):

heads up ui/run-pass/mir/mir_ascription_coercion.rs failed in CI

Keith Yeung (Sep 21 2018 at 20:21, on Zulip):

yeah, knew something was wrong

Keith Yeung (Sep 21 2018 at 20:22, on Zulip):

the logic for lowering type ascriptions to MIR is problematic

nikomatsakis (Sep 21 2018 at 20:43, on Zulip):

left a few comments @Keith Yeung

Keith Yeung (Sep 21 2018 at 22:00, on Zulip):

made changes according to comments

Keith Yeung (Sep 23 2018 at 07:11, on Zulip):

so my PR is currently failing on a const eval stack overflow, and I'm not exactly sure how to diagnose this

nikomatsakis (Sep 24 2018 at 15:55, on Zulip):

I'll take a look

nikomatsakis (Sep 24 2018 at 21:20, on Zulip):

(doing a local build now)

Keith Yeung (Sep 24 2018 at 21:29, on Zulip):

i also recently found out that i can use VS to debug on windows

Keith Yeung (Sep 24 2018 at 21:29, on Zulip):

so i don't necessarily have to get a linux or mac in order to use gdb/lldb to look at the stack

nikomatsakis (Sep 24 2018 at 21:37, on Zulip):

the problem is not specific to constants

nikomatsakis (Sep 24 2018 at 21:43, on Zulip):

hmm. what happens is:

nikomatsakis (Sep 24 2018 at 21:43, on Zulip):

I don't quite know why this problem seems to be specific to ValueTypeAscription though

nikomatsakis (Sep 24 2018 at 21:44, on Zulip):

well, it occurs with either case

nikomatsakis (Sep 24 2018 at 21:45, on Zulip):

it seems like the problem is

nikomatsakis (Sep 24 2018 at 21:45, on Zulip):

if you look, into also includes code for Place category things

nikomatsakis (Sep 24 2018 at 21:47, on Zulip):

I added a possible fix, will test and push

nikomatsakis (Sep 24 2018 at 21:54, on Zulip):

@Keith Yeung I pushed a commit — the problem is that into seems to special-case "places" to avoid precisely this loop

nikomatsakis (Sep 24 2018 at 21:54, on Zulip):

I added an add'l assertion as well to catch this case...

Keith Yeung (Sep 24 2018 at 21:55, on Zulip):

huh, so it's actually a pre-existing bug

Keith Yeung (Sep 24 2018 at 21:56, on Zulip):

because all Category::Place expressions aren't supposed to be handled in the catch-all branch

nikomatsakis (Sep 24 2018 at 21:57, on Zulip):

there was a missing assertion, at minimum

Keith Yeung (Sep 24 2018 at 21:57, on Zulip):

also, i'm quite confused by the fact that it seems to only happen with const declarations -- tests with other rvalue ascriptions seemed to turn out okay

nikomatsakis (Sep 24 2018 at 21:57, on Zulip):

no,they all fail

nikomatsakis (Sep 24 2018 at 21:57, on Zulip):

at least for me they did

Keith Yeung (Sep 24 2018 at 21:58, on Zulip):

i see, i suppose i only knew about the const eval case

Keith Yeung (Sep 24 2018 at 21:58, on Zulip):

if travis is happy with this, i guess we're good to go

Keith Yeung (Sep 24 2018 at 21:58, on Zulip):

i can also roll in the changes for typecasts though

Keith Yeung (Sep 24 2018 at 21:59, on Zulip):

perhaps i should do that since merge times with bors is about 3-4 hours

nikomatsakis (Sep 24 2018 at 22:05, on Zulip):

I'd say yes, add them in, should be a small-ish change

nikomatsakis (Sep 24 2018 at 22:05, on Zulip):

it'd be nice to have some tests though

nikomatsakis (Sep 24 2018 at 22:05, on Zulip):

unless I missed 'em

nikomatsakis (Sep 24 2018 at 22:06, on Zulip):

this directory src/test/ui/nll/user-annotations/

nikomatsakis (Sep 27 2018 at 18:41, on Zulip):

@Keith Yeung you are planning to add the as code into https://github.com/rust-lang/rust/pull/54447/, right?

Keith Yeung (Sep 27 2018 at 18:41, on Zulip):

yes, sorry i haven't gotten into it yet

nikomatsakis (Sep 27 2018 at 18:42, on Zulip):

no worries just wanted to know, else I would r+

Keith Yeung (Sep 29 2018 at 01:45, on Zulip):

hmm... so casts are a bit different in the sense that we already have ExprKind::Cast in the HAIR

Keith Yeung (Sep 29 2018 at 01:46, on Zulip):

according to issue #54332, it says that i should instead lower it differently and reuse the ExprKind::ValueTypeAscription variant that i've created previously

Matthew Jasper (Sep 29 2018 at 09:23, on Zulip):

I think Niko meant that (x as T) should be lowered as ValueTypeAscription { source: Cast { /* same as currently */ }, user_ty: T }, the Cast is still needed.

Matthew Jasper (Sep 29 2018 at 09:39, on Zulip):

While your there can you also move the branch in expr.rs above the // Now comes the rote stuff:comment? Even currently it's in no way rote.

Keith Yeung (Sep 29 2018 at 16:50, on Zulip):

I think Niko meant that (x as T) should be lowered as ValueTypeAscription { source: Cast { /* same as currently */ }, user_ty: T }, the Cast is still needed.

what you wrote there would mean that i have to box the ExprKind

Keith Yeung (Sep 29 2018 at 16:56, on Zulip):

oh, nevermind... I can use the ExprKind::to_ref method so that i don't need to box it

Matthew Jasper (Sep 29 2018 at 17:06, on Zulip):

Doesn't to_ref box it?

Keith Yeung (Sep 29 2018 at 17:33, on Zulip):

not sure, i just know that it typechecks

Keith Yeung (Sep 29 2018 at 18:06, on Zulip):

NUPE, it doesn't type check

Keith Yeung (Sep 29 2018 at 18:07, on Zulip):

primarily because ExprKind doesn't implement ToRef

nikomatsakis (Oct 01 2018 at 17:52, on Zulip):

@Keith Yeung yes you have to box the ExprKind... seems ok?

nikomatsakis (Oct 01 2018 at 17:52, on Zulip):

I did indeed mean what @Matthew Jasper suggested

Keith Yeung (Oct 01 2018 at 17:52, on Zulip):

i just haven't seen this pattern before for other variants

Keith Yeung (Oct 01 2018 at 17:52, on Zulip):

so wanted to double-check if that was the solution

nikomatsakis (Oct 01 2018 at 17:53, on Zulip):

well, I'm not sure about boxing

nikomatsakis (Oct 01 2018 at 17:53, on Zulip):

here is an example where we do something similar

nikomatsakis (Oct 01 2018 at 17:53, on Zulip):

except there we are wrapping something else with a Cast node

nikomatsakis (Oct 01 2018 at 17:55, on Zulip):

in general, one HIR node can definitely to multiple HAIR nodes (e.g., for adjustments)

Keith Yeung (Oct 01 2018 at 18:04, on Zulip):

so is it true that i should follow this format?

nikomatsakis (Oct 01 2018 at 18:04, on Zulip):

I think so, yes

nikomatsakis (Oct 01 2018 at 18:04, on Zulip):

however

nikomatsakis (Oct 01 2018 at 18:04, on Zulip):

well..

Keith Yeung (Oct 01 2018 at 18:05, on Zulip):

i.e. create a cast_expr, and then put it inside of ValueTypeAscription

nikomatsakis (Oct 01 2018 at 18:05, on Zulip):

so there are two options

nikomatsakis (Oct 01 2018 at 18:05, on Zulip):

we could just modify casts to always carry a user-type I guess..

nikomatsakis (Oct 01 2018 at 18:05, on Zulip):

but it seems better to nest it

nikomatsakis (Oct 01 2018 at 18:05, on Zulip):

however: we don't always have to do so

nikomatsakis (Oct 01 2018 at 18:05, on Zulip):

e.g. foo as u32 would need a ValueTypeAscription

nikomatsakis (Oct 01 2018 at 18:05, on Zulip):

there is some efficiency cost so it may be worth distinguishing

nikomatsakis (Oct 01 2018 at 18:06, on Zulip):

i.e. create a cast_expr, and then put it inside of ValueTypeAscription

right

nikomatsakis (Oct 01 2018 at 18:06, on Zulip):

I guess to start we can do it indiscriminantely

Keith Yeung (Oct 01 2018 at 18:06, on Zulip):

when perf becomes a problem we can revisit

nikomatsakis (Oct 01 2018 at 18:06, on Zulip):

exactly

Keith Yeung (Oct 01 2018 at 18:06, on Zulip):

should probably write a note on that point

Keith Yeung (Oct 02 2018 at 18:46, on Zulip):

ok, so my naïve implementation didn't work

nikomatsakis (Oct 02 2018 at 18:47, on Zulip):

for casts?

Keith Yeung (Oct 02 2018 at 18:47, on Zulip):

yes

Keith Yeung (Oct 02 2018 at 18:48, on Zulip):

in fact it passed my test case when it's supposed to fail

Keith Yeung (Oct 02 2018 at 18:48, on Zulip):

i wonder what the type of the cast expression is

Keith Yeung (Oct 02 2018 at 18:48, on Zulip):

perhaps i'm not using it correctly

nikomatsakis (Oct 02 2018 at 18:51, on Zulip):

maybe check the MIR you are generating?

nikomatsakis (Oct 02 2018 at 18:51, on Zulip):

if you push the code, I'll take a look

Keith Yeung (Oct 02 2018 at 19:40, on Zulip):

I have, in fact it's high five that told me about the error

Keith Yeung (Oct 02 2018 at 19:41, on Zulip):

That was in fact what I had in mind for next steps too

nikomatsakis (Oct 02 2018 at 19:42, on Zulip):

it might be something to do with constants

nikomatsakis (Oct 02 2018 at 20:11, on Zulip):

hmm

nikomatsakis (Oct 02 2018 at 20:11, on Zulip):

your PR looks reasonable

nikomatsakis (Oct 02 2018 at 20:11, on Zulip):

I can imagine the problems around constants, but I'm not sure why the test is not passing yet...

nikomatsakis (Oct 03 2018 at 20:16, on Zulip):

@Keith Yeung make any progress here? We could land the type ascriptions and come back to the cast expressions

Keith Yeung (Oct 03 2018 at 20:16, on Zulip):

no, i haven't looked into this yesterday unfortunately

Keith Yeung (Oct 03 2018 at 20:16, on Zulip):

but yes, perhaps that's what we can do for now

Keith Yeung (Oct 03 2018 at 20:18, on Zulip):

@nikomatsakis i've just removed my last commit for the type casts

Keith Yeung (Oct 03 2018 at 20:18, on Zulip):

think it's ready to be r+'d

nikomatsakis (Oct 03 2018 at 20:28, on Zulip):

ok

pnkfelix (Oct 05 2018 at 11:30, on Zulip):

hey @nikomatsakis do you think you'll be looking into the ICE on your PR #54757 any time soon?

pnkfelix (Oct 05 2018 at 11:31, on Zulip):

the reason that I ask is that it looks similar to ICE's that I am dealing with elsewhere, and so I am curious if you already have a fix in mind. (and/or if you think it overlaps with bugs related to normalization...)

nikomatsakis (Oct 05 2018 at 15:25, on Zulip):

@pnkfelix I am investigating this ICE right now, yes.

nikomatsakis (Oct 05 2018 at 15:30, on Zulip):

(if you have other examples, I'd like to see them)

pnkfelix (Oct 05 2018 at 16:16, on Zulip):

Well some are on a development branch, so who knows...?

Keith Yeung (Oct 08 2018 at 22:22, on Zulip):

here's the relevant sections of the MIR that gets generated with my attempt at the "respect casts" issue:

first, the temporary created by ValueTypeAscription when lowering to MIR and the cast temporary is defined as such:

let _2: &u32 as Canonical { variables: [CanonicalVarInfo { kind: Region }], value: &u32 };
let mut _3: &'static u32;

then, the relevant lines pertaining to ValueTypeAscription is here:

        _2 = &(*_3);
        StorageDead(_4);
        AscribeUserType(_2, o, Canonical { variables: [CanonicalVarInfo { kind: Region }], value: &u32 });
Keith Yeung (Oct 08 2018 at 22:23, on Zulip):

the question that immediately popped up in my head is "how do you even represent a &'static u32 in canonical types?"

Keith Yeung (Oct 08 2018 at 22:23, on Zulip):

or is it impossible and we are stuck with this data structure?

Keith Yeung (Oct 08 2018 at 22:24, on Zulip):

because whatever it is doing right now seems to not be able to capture the intent of &'static u32 for _2, which is what we need

nikomatsakis (Oct 09 2018 at 13:14, on Zulip):

@Keith Yeung I wonder if the cast problem was related to the bug I found in https://github.com/rust-lang/rust/pull/54757

nikomatsakis (Oct 09 2018 at 13:14, on Zulip):

we should try your commits again

nikomatsakis (Oct 09 2018 at 13:14, on Zulip):

the question that immediately popped up in my head is "how do you even represent a &'static u32 in canonical types?"

I don't know what the problem would be here, that should .. be fine?

nikomatsakis (Oct 09 2018 at 13:15, on Zulip):

I guess you're saying that we are getting the wrong "user type"; might be true, but it's not a limitation of Canonical

Keith Yeung (Oct 09 2018 at 21:25, on Zulip):

yep, travis is not happy

Keith Yeung (Oct 09 2018 at 21:26, on Zulip):

and yes, i was attempting to express that the canonical types are not exactly "canonical", so to speak

Keith Yeung (Oct 09 2018 at 21:26, on Zulip):

as in, they're not exactly the type that the user has ascribed to the expression

Keith Yeung (Oct 09 2018 at 21:26, on Zulip):

or in this case, not the exact target type the user wishes to cast to

nikomatsakis (Oct 09 2018 at 21:28, on Zulip):

thing is, they are, so we must be canonicalizing the wrong thing

nikomatsakis (Oct 09 2018 at 21:28, on Zulip):

would have to dig in a bit more to see why I guess

nikomatsakis (Oct 09 2018 at 21:29, on Zulip):

they ought to e.g. preserve 'static, unless the input type did not have 'static to start with

Keith Yeung (Oct 10 2018 at 00:02, on Zulip):

that's what i thought initially as well, and i can point to you where i think the culprit is

Keith Yeung (Oct 10 2018 at 00:03, on Zulip):

here: https://github.com/rust-lang/rust/pull/54938/files#diff-1d1b0d29a2e8da97c6bfb6e364d920c7R4143

Keith Yeung (Oct 10 2018 at 00:03, on Zulip):

i've tried moving this up so that i use the canonicalized type directly

Keith Yeung (Oct 10 2018 at 00:03, on Zulip):

instead of it being passed through all the cast checks and whatnot

Keith Yeung (Oct 10 2018 at 00:04, on Zulip):

and it still didn't work

nikomatsakis (Oct 17 2018 at 19:21, on Zulip):

@Keith Yeung argh forgot about this I will do some digging now

nikomatsakis (Oct 17 2018 at 20:03, on Zulip):

ok, the problem is caused by shadowing

nikomatsakis (Oct 17 2018 at 20:03, on Zulip):

the ty you want to be referring to is bound in the match higher up, but the one you are referring to is bound here:

let source = if let Some((did, offset, ty)) = var {
nikomatsakis (Oct 17 2018 at 20:04, on Zulip):

I don't know what's up with the const evaluation, otoh, I guess it's something caused by introducing a let and an ascribeusertype into the MIR

nikomatsakis (Oct 17 2018 at 20:04, on Zulip):

probably..harmless enough, but kind of lame

nikomatsakis (Oct 17 2018 at 20:06, on Zulip):

hmm

nikomatsakis (Oct 17 2018 at 20:07, on Zulip):

maybe not the whole story

nikomatsakis (Oct 17 2018 at 20:07, on Zulip):

test still doesn't pass for some reason

Keith Yeung (Oct 22 2018 at 03:31, on Zulip):

what ended up being the problem for this?

Keith Yeung (Oct 22 2018 at 03:31, on Zulip):

because i surely didn't spot what it was

nikomatsakis (Oct 22 2018 at 15:26, on Zulip):

well, @Keith Yeung, there was the shadowing I pointed out earlier (on this topic)

nikomatsakis (Oct 22 2018 at 15:26, on Zulip):

but in terms of the consts, there is some const code that was a bit over-active in terms of issuing errors because we now emitted the ValidateUserTypeAscription opcode...

nikomatsakis (Oct 22 2018 at 15:27, on Zulip):

...I side-stepped that for the time being

nikomatsakis (Oct 22 2018 at 15:27, on Zulip):

by not emitting those MIR statements for ascriptions like x as usize

nikomatsakis (Oct 22 2018 at 15:27, on Zulip):

since we don't need them anyway

nikomatsakis (Oct 22 2018 at 15:27, on Zulip):

the const code should prob be fixed though

nikomatsakis (Oct 30 2018 at 17:26, on Zulip):

so I was looking at breaking up #47184 into issues for the remaining problems

nikomatsakis (Oct 30 2018 at 17:26, on Zulip):

we've really made good progress it seems

nikomatsakis (Oct 30 2018 at 17:27, on Zulip):

I see a few remaining cases:

nikomatsakis (Oct 30 2018 at 17:27, on Zulip):

I'm not sure about the associated constants in patterns case

nikomatsakis (Oct 30 2018 at 17:28, on Zulip):

e.g., this does not error today:

trait Foo<'a> {
    const C: &'a u32;
}

impl<'a, T> Foo<'a> for T {
    const C: &'a u32 = &22;
}

fn foo() {
    let a = 22;
    match &a {
        <() as Foo<'static>>::C => { }
        &_ => { }
    }
}

fn main() {
}
nikomatsakis (Oct 30 2018 at 17:28, on Zulip):

and it's not clear that it should

nikomatsakis (Oct 30 2018 at 17:30, on Zulip):

ah, but this does error today (using a Cell to force invariance)

use std::cell::Cell;

trait Foo<'a> {
    const C: Option<Cell<&'a u32>>;
}

impl<'a, T> Foo<'a> for T {
    const C: Option<Cell<&'a u32>> = None;
}

fn foo() {
    let a = 22;
    let b = Some(Cell::new(&a));
    match b {
        <() as Foo<'static>>::C => { }
        _ => { }
    }
}

fn main() {
}
nikomatsakis (Oct 30 2018 at 17:40, on Zulip):

@pnkfelix I see you put https://github.com/rust-lang/rust/issues/55401 as NLL-deferred, you don't think it needs to be fixed for the release?

nikomatsakis (Oct 30 2018 at 17:41, on Zulip):

I'm trying to think what would be an example of a program that (fails to) error as a result of #55401

pnkfelix (Oct 30 2018 at 18:09, on Zulip):

I think that’s part of why I deferred it ...

pnkfelix (Oct 30 2018 at 18:10, on Zulip):

But at this point we can promote it to release milestone

nikomatsakis (Oct 30 2018 at 18:10, on Zulip):

I wasn't able yet to come up with a problem program

pnkfelix (Oct 30 2018 at 19:31, on Zulip):

hmm. this is worrisome. This code (playpen) errors, but if I uncomment #![feature(nll)], the compiler accepts it.

pnkfelix (Oct 30 2018 at 19:31, on Zulip):

better file a ticket

nikomatsakis (Oct 30 2018 at 19:33, on Zulip):

@pnkfelix that code looks ok to me though

nikomatsakis (Oct 30 2018 at 19:33, on Zulip):

I'm not sure why we reject it outside of NLL

nikomatsakis (Oct 30 2018 at 19:33, on Zulip):

in particular I expect &22 to be promoted

pnkfelix (Oct 30 2018 at 19:33, on Zulip):

its the basis of one of the patterns.rs tests

pnkfelix (Oct 30 2018 at 19:33, on Zulip):

the ascription of y to have type &'a _

nikomatsakis (Oct 30 2018 at 19:33, on Zulip):

oh wait

nikomatsakis (Oct 30 2018 at 19:33, on Zulip):

I see I see

nikomatsakis (Oct 30 2018 at 19:34, on Zulip):

right, we should be pushing the &'a down to y

pnkfelix (Oct 30 2018 at 19:34, on Zulip):

yeah so something is goofy

nikomatsakis (Oct 30 2018 at 19:34, on Zulip):

as a "lower bound" or "upper bound" or whichever

pnkfelix (Oct 30 2018 at 19:34, on Zulip):

I'll have to look at it later

pnkfelix (Oct 30 2018 at 19:34, on Zulip):

I'm assuming playpen is up to date

pnkfelix (Oct 30 2018 at 19:34, on Zulip):

mabye that's assumption is wrong

pnkfelix (Oct 30 2018 at 19:35, on Zulip):

oh no playpen is totally out of date, its from 10-25 or something

pnkfelix (Oct 30 2018 at 19:35, on Zulip):

so that was my mistake, using the playpen as the basis for a test

nikomatsakis (Oct 30 2018 at 19:35, on Zulip):

ah :)

pnkfelix (Oct 30 2018 at 20:04, on Zulip):

I did find an example, I think.

pnkfelix (Oct 30 2018 at 20:04, on Zulip):
fn static_to_a_to_static_through_ref_in_tuple<'a>(x: &'a u32) -> &'static u32 {
    let (ref y, _z): (&'a u32, u32) = (&22, 44);
    *y //~ ERROR
}
pnkfelix (Oct 30 2018 at 20:04, on Zulip):

I think that's supposed to error, but does not today under -Z borrowck=mir

nikomatsakis (Oct 30 2018 at 20:05, on Zulip):

I see

Jake Goulding (Oct 30 2018 at 20:43, on Zulip):

oh no playpen is totally out of date,

The playground is out of date because nightly cannot compile hyper.

Jake Goulding (Oct 30 2018 at 20:44, on Zulip):

https://github.com/rust-lang/rust/issues/55376

pnkfelix (Oct 30 2018 at 21:58, on Zulip):

okay well it sounds like that is now resolved, so hopefully things will start working again soon-ish...?

Jake Goulding (Oct 30 2018 at 22:09, on Zulip):

should - need to watch after today's nightly

Last update: Nov 21 2019 at 23:40UTC