Stream: t-compiler/wg-nll

Topic: in-band-lifetimes


nikomatsakis (Jul 25 2018 at 20:27, on Zulip):

@simulacrum didn't you add in_band_lifetimes feature to the compiler ?

simulacrum (Jul 25 2018 at 20:28, on Zulip):

You mean in rustc_mir? I went through and tried it but never submitted a PR

simulacrum (Jul 25 2018 at 20:28, on Zulip):

I still have the branch though, probably relatively easy to rebase

simulacrum (Jul 25 2018 at 20:29, on Zulip):

@nikomatsakis https://github.com/rust-lang/rust/compare/master...Mark-Simulacrum:rustc-mir-inband is the diff

nikomatsakis (Jul 25 2018 at 20:30, on Zulip):

oh, you didn't land it?

nikomatsakis (Jul 25 2018 at 20:31, on Zulip):

that explains why the #![feature] is not present :)

simulacrum (Jul 25 2018 at 20:34, on Zulip):

@nikomatsakis Want me to rebase it?

nikomatsakis (Jul 25 2018 at 20:35, on Zulip):

idk, maybe? I'd like to start using the feature -- I'm not crazy though about having lifetimes named 'a at impl scope

nikomatsakis (Jul 25 2018 at 20:35, on Zulip):

I'd want to maybe establish a different convention

nikomatsakis (Jul 25 2018 at 20:35, on Zulip):

basically what I wanted was something where single-letter names were only used at fn level

nikomatsakis (Jul 25 2018 at 20:35, on Zulip):

and multi-letter names were meant to be meaningful and could be used anywhere

nikomatsakis (Jul 25 2018 at 20:36, on Zulip):

ideally, a lint-enforced convention, but maybe good to do it manually to start

nikomatsakis (Jul 25 2018 at 20:36, on Zulip):

it's not particularly urgent

nikomatsakis (Jul 25 2018 at 20:36, on Zulip):

I was just curious because I thought I remembered you saying you had applied that change to librustc_mir

nikomatsakis (Jul 25 2018 at 20:36, on Zulip):

actually what I'd like to do is start using the implied_outlives_bounds for structs...

nikomatsakis (Jul 25 2018 at 20:37, on Zulip):

I get sick of writing <'cx, 'gcx: 'tcx, 'tcx: 'cx>

simulacrum (Jul 25 2018 at 20:37, on Zulip):

I don't imagine it'll be a difficult rebase

simulacrum (Jul 25 2018 at 20:38, on Zulip):

I can put it up later today/tomorrow probably

simulacrum (Jul 25 2018 at 20:38, on Zulip):

But yeah, conventions need to be established

nikomatsakis (Jul 25 2018 at 20:38, on Zulip):

agreed. I'm not sure I have the right ones, either, but I think they would work well

nikomatsakis (Jul 25 2018 at 20:39, on Zulip):

I would like to start using it though to try and get better sense for how it "feels"

simulacrum (Jul 25 2018 at 20:40, on Zulip):

Sure, yeah

nikomatsakis (Jul 26 2018 at 03:49, on Zulip):

on this topic, I tried to add infer_outlives_requirements to librustc_mir, but due to the (fixed) bug for cross-crate cases, it's still not usable

nikomatsakis (Jul 26 2018 at 03:49, on Zulip):

need one more beta

nikomatsakis (Jul 26 2018 at 05:34, on Zulip):

proposal: instead of 'cx, use 'this to represent the "contravariant region"...

nikomatsakis (Jul 26 2018 at 05:41, on Zulip):

or maybe 'me or 'my

Jake Goulding (Jul 26 2018 at 13:51, on Zulip):

Bringing back 'self. eh

simulacrum (Jul 26 2018 at 14:30, on Zulip):

'self doesn't work because self is a keyword -- 'this has been the trend I've seen so far

simulacrum (Jul 26 2018 at 14:30, on Zulip):

I do like 'me or something shorter though

Jake Goulding (Jul 26 2018 at 15:00, on Zulip):

@simulacrum I was referencing some Olde Rust, before when I started (0.12, IIRC) where 'self was a predefined lifetime.

simulacrum (Jul 26 2018 at 15:00, on Zulip):

Heh

Jake Goulding (Jul 26 2018 at 15:01, on Zulip):

But, as useful feedback instead of my joke...

to represent the "contravariant region"...

Maybe it should be 'cr

simulacrum (Jul 26 2018 at 15:39, on Zulip):

@nikomatsakis Well, it's up: https://github.com/rust-lang/rust/pull/52736

simulacrum (Jul 26 2018 at 15:39, on Zulip):

But reviewing that is going to be a nightmare

nikomatsakis (Jul 26 2018 at 15:44, on Zulip):

to some extent, if it compiles, it's fine

nikomatsakis (Jul 26 2018 at 15:48, on Zulip):

@simulacrum some of the changes are surprising to me; I'll leave comments

simulacrum (Jul 26 2018 at 15:48, on Zulip):

I'm definitely interested in feedback

simulacrum (Jul 26 2018 at 15:48, on Zulip):

Some of it might be that as I went through my patterns somewhat changed I think as I got more of a feel for things

nikomatsakis (Jul 26 2018 at 15:49, on Zulip):

the thing I'm most curious about is the 'self_

Jake Goulding (Jul 26 2018 at 15:50, on Zulip):

yeah ewww 'self_

Jake Goulding (Jul 26 2018 at 15:51, on Zulip):

i like that cramertj also reviewed

simulacrum (Jul 26 2018 at 15:52, on Zulip):

@nikomatsakis What do you think about using '_ instead of 'a/'me? I guess we can't always since we sometime want to tie things to that lifetime...

nikomatsakis (Jul 26 2018 at 15:53, on Zulip):

it's not so much the name itself

nikomatsakis (Jul 26 2018 at 15:53, on Zulip):

@simulacrum well I think we should use '_ whenever possible

nikomatsakis (Jul 26 2018 at 15:53, on Zulip):

that's the first and foremost rule

nikomatsakis (Jul 26 2018 at 15:53, on Zulip):

and in fact we have a lint for this

nikomatsakis (Jul 26 2018 at 15:53, on Zulip):

that... I think even works?

simulacrum (Jul 26 2018 at 15:53, on Zulip):

Even if that means a later patch will need to make broader changes?

nikomatsakis (Jul 26 2018 at 15:53, on Zulip):

that would be my preference

simulacrum (Jul 26 2018 at 15:53, on Zulip):

i.e. today you can pretty much just start using 'a in contexts

nikomatsakis (Jul 26 2018 at 15:53, on Zulip):

I think names should connect things

nikomatsakis (Jul 26 2018 at 15:54, on Zulip):

if I see a name, I would typically assume it's tied to something else

nikomatsakis (Jul 26 2018 at 15:54, on Zulip):

if the name is only used once, that is misleading

simulacrum (Jul 26 2018 at 15:54, on Zulip):

What about 'tcx?

simulacrum (Jul 26 2018 at 15:54, on Zulip):

E.g. mir::Place<'tcx> or some such

nikomatsakis (Jul 26 2018 at 15:54, on Zulip):

I typically use '_ if I can instead

nikomatsakis (Jul 26 2018 at 15:54, on Zulip):

but that is something of an exception

nikomatsakis (Jul 26 2018 at 15:54, on Zulip):

but I do usually write e.g. &InferCtxt<'_, '_, 'tcx>

nikomatsakis (Jul 26 2018 at 15:54, on Zulip):

and not 'gcx

nikomatsakis (Jul 26 2018 at 15:55, on Zulip):

I'd be fine with e.g. Ty<'_> if it's not needed

nikomatsakis (Jul 26 2018 at 15:55, on Zulip):

but I'm also ok with Ty<'tcx>, since that is so omni-present

nikomatsakis (Jul 26 2018 at 15:56, on Zulip):

@simulacrum but mainly I was curious whether the 'self_ was actually needed

nikomatsakis (Jul 26 2018 at 15:56, on Zulip):

that is, you went from a case with elision to one without

nikomatsakis (Jul 26 2018 at 15:56, on Zulip):

fn foo(&self, ..) -> Foo<'_> to fn foo(&'a self, ..) -> Foo<'a>

nikomatsakis (Jul 26 2018 at 15:56, on Zulip):

if that is needed, that seems like a bug

simulacrum (Jul 26 2018 at 15:57, on Zulip):

It's sometimes needed (when you have multiple lifetimes in input params)

simulacrum (Jul 26 2018 at 15:58, on Zulip):

But mostly not required

nikomatsakis (Jul 26 2018 at 16:00, on Zulip):

but in those cases, it should have been needed before, no?

simulacrum (Jul 26 2018 at 16:01, on Zulip):

That's true, yes

simulacrum (Jul 26 2018 at 16:02, on Zulip):

Another interesting question is whether (when possible) we should omit 'tcx lifetimes too, e.g. if the function doesn't actually use that property/tie

nikomatsakis (Jul 26 2018 at 16:02, on Zulip):

Yeah, I lack a strong opinion there. I think I would probably keep that particular one just for simplicity somehow.

nikomatsakis (Jul 26 2018 at 16:02, on Zulip):

but I also think it's fine not to

simulacrum (Jul 26 2018 at 16:03, on Zulip):

It feels like we should have better answers here...

nikomatsakis (Jul 26 2018 at 16:03, on Zulip):

but I feel like when I am writing signatures, I will generally just write 'tcx out of habit and not want to think about how tied things are

nikomatsakis (Jul 26 2018 at 16:03, on Zulip):

I..huh. I don't see a problem.

nikomatsakis (Jul 26 2018 at 16:03, on Zulip):

but, more specifically, do you mean "rustc should have better answers" or "Rust" or both?

simulacrum (Jul 26 2018 at 16:03, on Zulip):

the first more strongly but both

simulacrum (Jul 26 2018 at 16:04, on Zulip):

It's harder on newcomers if the code is inconsistent

nikomatsakis (Jul 26 2018 at 16:04, on Zulip):

What would make an answer "better"?

nikomatsakis (Jul 26 2018 at 16:04, on Zulip):

/me shrugs

nikomatsakis (Jul 26 2018 at 16:04, on Zulip):

then write 'tcx

simulacrum (Jul 26 2018 at 16:04, on Zulip):

Right, but then 'a, 'tcx, 'gcx should be everywhere, no?

nikomatsakis (Jul 26 2018 at 16:04, on Zulip):

no!

simulacrum (Jul 26 2018 at 16:04, on Zulip):

i.e. you'll get obscure errors if the impl doesn't have it

nikomatsakis (Jul 26 2018 at 16:04, on Zulip):

first off, not 'a :)

nikomatsakis (Jul 26 2018 at 16:04, on Zulip):

why?

nikomatsakis (Jul 26 2018 at 16:04, on Zulip):

I am confused

nikomatsakis (Jul 26 2018 at 16:05, on Zulip):

oh, I see what you mean

simulacrum (Jul 26 2018 at 16:05, on Zulip):

Because you're using lifetimes fromself

nikomatsakis (Jul 26 2018 at 16:05, on Zulip):

so including 'a is more likely to cause problems than not

nikomatsakis (Jul 26 2018 at 16:05, on Zulip):

leaving aside the question of name

nikomatsakis (Jul 26 2018 at 16:05, on Zulip):

because it is not a real thing

simulacrum (Jul 26 2018 at 16:05, on Zulip):

Agreed on 'a but seems like 'tcx/'gcx` are good ideas, right?

nikomatsakis (Jul 26 2018 at 16:05, on Zulip):

I think you could make a case for 'gcx

nikomatsakis (Jul 26 2018 at 16:05, on Zulip):

it probably doesn't matter too much either way

simulacrum (Jul 26 2018 at 16:06, on Zulip):

Well, I've seen errors from 'tcx and 'gcx being not associated

simulacrum (Jul 26 2018 at 16:06, on Zulip):

(while I was doing this)

nikomatsakis (Jul 26 2018 at 16:06, on Zulip):

well

nikomatsakis (Jul 26 2018 at 16:06, on Zulip):

I'd rather not write it :)

nikomatsakis (Jul 26 2018 at 16:06, on Zulip):

because it's so unusual to use

nikomatsakis (Jul 26 2018 at 16:06, on Zulip):

that I prefer to have attention called to it

simulacrum (Jul 26 2018 at 16:06, on Zulip):

Hm, sure, but the problem is that it's no longer a local consideration

simulacrum (Jul 26 2018 at 16:07, on Zulip):

i.e. I can see not writing it in functions but impl headers perhaps yes?

nikomatsakis (Jul 26 2018 at 16:07, on Zulip):

why?

nikomatsakis (Jul 26 2018 at 16:07, on Zulip):

I mean .. yes, you'll get errors

nikomatsakis (Jul 26 2018 at 16:07, on Zulip):

we'll work on reporting them well

simulacrum (Jul 26 2018 at 16:07, on Zulip):

Right, you'll get errors and as a newcomer you'll have no idea how to fix them

nikomatsakis (Jul 26 2018 at 16:07, on Zulip):

why would you have no idea?

simulacrum (Jul 26 2018 at 16:08, on Zulip):

I guess if errors are good, then maybe -- I just worry that it'll essentially be '1 does not outlive 'tcx and people will not know where '1 came from

nikomatsakis (Jul 26 2018 at 16:08, on Zulip):

e.g., if it tells you

  | impl Ctxt<'_, '_, 'tcx>
  |                ^^ data with this lifetime is being used as `'gcx`

then it's fairly clear. You have to understand the scheme, of course.

simulacrum (Jul 26 2018 at 16:08, on Zulip):

but if we can point at the impl block then that's good enough

nikomatsakis (Jul 26 2018 at 16:08, on Zulip):

I doubt we do today of course :) but it seems like something we could do

nikomatsakis (Jul 26 2018 at 16:08, on Zulip):

and should do

nikomatsakis (Jul 26 2018 at 16:08, on Zulip):

regardless of the outcome of this discussion :)

nikomatsakis (Jul 26 2018 at 16:09, on Zulip):

that said, I think i could be convinced that we should just use 'gcx and 'tcx

nikomatsakis (Jul 26 2018 at 16:09, on Zulip):

for simpicity and to head off errors

nikomatsakis (Jul 26 2018 at 16:09, on Zulip):

I think those two lifetimes are 'special'

nikomatsakis (Jul 26 2018 at 16:09, on Zulip):

most other lifetimes just connect things

simulacrum (Jul 26 2018 at 16:09, on Zulip):
error[E0623]: lifetime mismatch
   --> librustc_mir/borrow_check/nll/mod.rs:259:9
    |
217 |     infcx: &InferCtxt<'_, '_, '_>,
    |             ---------------------
...
220 |     mir: &Mir<'_>,
    |           ------- these two types are declared with different lifetimes...
...
259 |         infcx.tcx,
    |         ^^^^^^^^^ ...but data from `mir` flows into `infcx` here
nikomatsakis (Jul 26 2018 at 16:09, on Zulip):

but those lifetimes refer to very specific arenas in the compiler

nikomatsakis (Jul 26 2018 at 16:09, on Zulip):

well, the newer errors are actually better

nikomatsakis (Jul 26 2018 at 16:09, on Zulip):

we should remove that one

nikomatsakis (Jul 26 2018 at 16:10, on Zulip):

that is, that particular error form is a "fancy error" that overrides the base error

nikomatsakis (Jul 26 2018 at 16:10, on Zulip):

but the base errors are becoming better than the fancy error

nikomatsakis (Jul 26 2018 at 16:10, on Zulip):

in particular, the base errors would highlight which lifetime

nikomatsakis (Jul 26 2018 at 16:10, on Zulip):

not just the type as a whole

simulacrum (Jul 26 2018 at 16:10, on Zulip):

that's amazing

nikomatsakis (Jul 26 2018 at 16:11, on Zulip):
error[E0623]: lifetime mismatch
   --> librustc_mir/borrow_check/nll/mod.rs:259:9
    |
217 |     infcx: &InferCtxt<'_, '_, '_>,
    |                           -- let's call this '1
...
220 |     mir: &Mir<'_>,
    |               -- let's call this '2
...
259 |         infcx.tcx,
    |         ^^^^^^^^^ '1 is required to outlive '2 here
nikomatsakis (Jul 26 2018 at 16:11, on Zulip):

something like that

nikomatsakis (Jul 26 2018 at 16:11, on Zulip):

cc @David Wood :point_up: we should distill a test here

nikomatsakis (Jul 26 2018 at 16:11, on Zulip):

I think that it may be getting time to remove the "nice region errors"... or at least some of them .. in NLL mode

simulacrum (Jul 26 2018 at 16:11, on Zulip):

It'd be super cool if we could look at the struct and pull lifetime names from there

nikomatsakis (Jul 26 2018 at 16:12, on Zulip):

we do that sometimes and it's mega confusing

simulacrum (Jul 26 2018 at 16:12, on Zulip):

hm, I guess it depends on the case

nikomatsakis (Jul 26 2018 at 16:12, on Zulip):

that is, people are always like "what is this name"

nikomatsakis (Jul 26 2018 at 16:12, on Zulip):

yeah, I know, in this case it might be nice

nikomatsakis (Jul 26 2018 at 16:12, on Zulip):

I mean using names like '1 and '2 may not be better :)

nikomatsakis (Jul 26 2018 at 16:12, on Zulip):

@simulacrum can you maybe distill that test you just gave into an issue ?

nikomatsakis (Jul 26 2018 at 16:13, on Zulip):

e.g., with a simple reproduction

simulacrum (Jul 26 2018 at 16:13, on Zulip):

hm, I can point at the compiler tree, I think, that should work

nikomatsakis (Jul 26 2018 at 16:13, on Zulip):

I think though I'm sort of convinced to just 'tcx and 'gcx consistently

nikomatsakis (Jul 26 2018 at 16:13, on Zulip):

it seems like it'll be easier to explain

nikomatsakis (Jul 26 2018 at 16:13, on Zulip):

well

simulacrum (Jul 26 2018 at 16:14, on Zulip):

Note that the test case is w/o NLL enabled

nikomatsakis (Jul 26 2018 at 16:15, on Zulip):

I think that this test case will do:

#![feature(nll)]

struct Foo<'a, 'b> {
    x: &'a u32,
    y: &'b u32,
}

struct Bar<'b> {
    z: &'b u32
}

fn func(foo: Foo<'_, '_>, bar: Bar<'_>) {
    foo.y = bar.z;
}

fn main() { }
nikomatsakis (Jul 26 2018 at 16:15, on Zulip):

uh I can't connect to github for some reason :)

simulacrum (Jul 26 2018 at 16:16, on Zulip):

seems to reproduce, I'll file it

nikomatsakis (Jul 26 2018 at 16:16, on Zulip):

can you also p=1 @David Wood's PR now that tests pass? :)

nikomatsakis (Jul 26 2018 at 16:16, on Zulip):

why on earth can't I connect to github...

davidtwco (Jul 26 2018 at 16:17, on Zulip):

(thats #52648)

nikomatsakis (Jul 26 2018 at 16:17, on Zulip):

@simulacrum this is an example of the new style errors at work, though in this case we can't point at the '_:

error: unsatisfied lifetime constraints
  --> $DIR/issue-52533-1.rs:18:18
   |
LL |     gimme(|x, y| y)
   |            -  -  ^ closure was supposed to return data with lifetime `'1` but it is returning data with lifetime `'2`
   |            |  |
   |            |  has type `&Foo<'_, '1, u32>`
   |            has type `&Foo<'_, '2, u32>`
nikomatsakis (Jul 26 2018 at 16:18, on Zulip):

I'm still impressed with that one :)

nikomatsakis (Jul 26 2018 at 16:18, on Zulip):

ok I got github to work now

nikomatsakis (Jul 26 2018 at 16:18, on Zulip):

switched to my cell phone hotspot :)

nikomatsakis (Jul 26 2018 at 16:19, on Zulip):

@simulacrum here's another example to file :)

nikomatsakis (Jul 26 2018 at 16:19, on Zulip):

https://play.rust-lang.org/?gist=96fc205e5162ae48cb27063a22ea4518&version=nightly&mode=debug&edition=2015

simulacrum (Jul 26 2018 at 16:19, on Zulip):

Yes, these errors are quite good

nikomatsakis (Jul 26 2018 at 16:19, on Zulip):

did you file the other one?

davidtwco (Jul 26 2018 at 16:20, on Zulip):

#52739

nikomatsakis (Jul 26 2018 at 16:21, on Zulip):

I think that both of these are cases where the "nice region errors" are getting in the way

davidtwco (Jul 26 2018 at 16:21, on Zulip):

I've made a topic for discussing that.

davidtwco (Jul 26 2018 at 16:49, on Zulip):

Got really confused when I got assigned a issue from @simulacrum but the name on the email of @simulacrum was different.

Last update: Nov 21 2019 at 13:10UTC