Stream: t-compiler/wg-nll

Topic: #54310 "dies too soon" vs "conflicts with dtor"


pnkfelix (Sep 17 2018 at 22:33, on Zulip):

@nikomatsakis as part of looking at #52059, I am trying out a change that, in a number of cases, replaces the diagnostic "borrowed value does not live long enough" with "borrow may still be in use when destructor runs"

pnkfelix (Sep 17 2018 at 22:33, on Zulip):

it certainly doesn't do that replacement in all cases; e.g. if you really do have a conflict between a StorageDead and a Borrow, then you get the old diagnostic

pnkfelix (Sep 17 2018 at 22:34, on Zulip):

But I basically wanted to double check here if anyone was particularly wedded to trying to stick to phrasing of the form "borrowed value does not live long enough"

pnkfelix (Sep 17 2018 at 22:36, on Zulip):

The reason why that message does not suffice is that for cases like #52059, the value being borrowed does live long enough. The problem is that there's another value that isn't being borrowed whose destructor is going to run (and that dtor will require &mut access to the borrow)

pnkfelix (Sep 17 2018 at 23:26, on Zulip):

(actually I think I found a reasonable way to differentiate the cases: if the borrowed_place is a prefix of the dropped place, then use the old "does not live long enough" phrasing. The new message is only interesting distinction to make when borrowed_place is not a prefix of it.)

pnkfelix (Sep 18 2018 at 00:19, on Zulip):

(updated topic so it now links to PR with proposed change)

nikomatsakis (Sep 18 2018 at 13:07, on Zulip):

@pnkfelix actually that was on my short list to change

nikomatsakis (Sep 18 2018 at 13:07, on Zulip):

I had in mind a message much like the one you describe

nikomatsakis (Sep 18 2018 at 13:08, on Zulip):

in general, I think that we use the term drop in various ambiguous-y ways

pnkfelix (Sep 18 2018 at 13:08, on Zulip):

I did find while working on #54310 that there are cases where the prior wording was nicer

pnkfelix (Sep 18 2018 at 13:08, on Zulip):

namely when you have generic types

nikomatsakis (Sep 18 2018 at 13:08, on Zulip):

hmm, example?

nikomatsakis (Sep 18 2018 at 13:09, on Zulip):

I found while talking to various people that about this error specifically that there are a number of things people don't really understand

nikomatsakis (Sep 18 2018 at 13:09, on Zulip):

and that if we could be more specific about what is happening — e.g., "when we run the destructor" — it would be good

pnkfelix (Sep 18 2018 at 13:09, on Zulip):

When you have e.g. fn foo<T>(t: T) -> ... { return &t }, I thought it seemed goofy to be talking about the destructor of t

pnkfelix (Sep 18 2018 at 13:09, on Zulip):

yes, its certainly possible T has a destructor

pnkfelix (Sep 18 2018 at 13:10, on Zulip):

but its also just generally true that t simply "does not live long enough"

nikomatsakis (Sep 18 2018 at 13:10, on Zulip):

I think in that case we should say that

nikomatsakis (Sep 18 2018 at 13:10, on Zulip):

no

nikomatsakis (Sep 18 2018 at 13:10, on Zulip):

er

nikomatsakis (Sep 18 2018 at 13:10, on Zulip):

I don't think that does not lvie long enough is basically ever a good message

pnkfelix (Sep 18 2018 at 13:10, on Zulip):

Well

nikomatsakis (Sep 18 2018 at 13:10, on Zulip):

I think we should talk about actions that are taking place

pnkfelix (Sep 18 2018 at 13:10, on Zulip):

In that case, we can land PR #54310 as is

nikomatsakis (Sep 18 2018 at 13:10, on Zulip):

it is however sometimes a challenge to deal with "may" actions :)

pnkfelix (Sep 18 2018 at 13:11, on Zulip):

and discuss whether to generalize it to apply elsewhere

nikomatsakis (Sep 18 2018 at 13:11, on Zulip):

that particular case is interesting because

nikomatsakis (Sep 18 2018 at 13:11, on Zulip):

some part of me wants to say that we should be saying something like "returning borrowed reference to content owned by this function"

nikomatsakis (Sep 18 2018 at 13:12, on Zulip):

but I think that particular wording is probably not good

nikomatsakis (Sep 18 2018 at 13:12, on Zulip):

/me thinks

nikomatsakis (Sep 18 2018 at 13:12, on Zulip):

it might also be good for a "help" or "note"

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

here, drop of foo needs exclusive access to foo.data, because the type Foo<Concrete<'_>> implements the Drop trait

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

that is nice!

nikomatsakis (Sep 18 2018 at 13:15, on Zulip):

one thing about these errors is that the "locus" of the error feels mildly inconsistent

nikomatsakis (Sep 18 2018 at 13:15, on Zulip):

e.g., we are "blaming" the borrow

nikomatsakis (Sep 18 2018 at 13:15, on Zulip):

rather than the drop or the final use

nikomatsakis (Sep 18 2018 at 13:15, on Zulip):

often we blame the "middle" point — particularly since sometimes we don't have a good "third point", although I think we should work on that (in principle there ought to always be one...?)

pnkfelix (Sep 18 2018 at 13:16, on Zulip):

https://imgflip.com/i/2i6w1u

Last update: Nov 21 2019 at 15:15UTC