Stream: t-compiler/const-eval

Topic: Method for promotion in `const`

ecstatic-morse (Oct 23 2019 at 23:41, on Zulip):

@eddyb , you've mentioned that they'd like to create actual MIR promoteds within consts, instead of just removing Drop and StorageDead for things that need lifetime extension.

ecstatic-morse (Oct 23 2019 at 23:42, on Zulip):

I had a fix in mind for #65732 that would preserve the existing way of doing promotion, but requires changing the output of various MIR queries.

ecstatic-morse (Oct 23 2019 at 23:43, on Zulip):

It's pointless to do this if we are planning to do the same thing everywhere

ecstatic-morse (Oct 23 2019 at 23:45, on Zulip):

So what are the upsides of the current approach? Do you think it was just a premature optimization? Should I start working to make it go away? I've previously mentioned to @eddyb that this gets a bit easier once #63812 is merged

ecstatic-morse (Oct 23 2019 at 23:46, on Zulip):

It does seem a little silly to pull stuff out of one const Body and put it into another I guess.

eddyb (Oct 23 2019 at 23:50, on Zulip):

@RalfJ was confused by it and I'd rather get rid of it than try to document the confusing promotion triangle

eddyb (Oct 23 2019 at 23:53, on Zulip):

(let-like scope extension, promotion via scope extension, proper promotion)

ecstatic-morse (Oct 23 2019 at 23:55, on Zulip):

Okay, but no pressing concerns? The split has caused bugs already, so I have no problem trying to do the same thing everywhere.

ecstatic-morse (Oct 23 2019 at 23:56, on Zulip):

I should be able to make qualify_consts more understandable once I remove the old promoter/checker/qualifier.

ecstatic-morse (Oct 23 2019 at 23:57, on Zulip):

Perhaps that could help avoid bugs in the future.

ecstatic-morse (Oct 23 2019 at 23:57, on Zulip):

(if we were to continue using separate approaches)

eddyb (Oct 24 2019 at 00:09, on Zulip):

first two rely on missing StorageDead, last two involve mutating MIR in promote_consts

RalfJ (Oct 24 2019 at 07:39, on Zulip):

@eddyb I was confused mostly because I didn't expect it.^^ With proper docs I do
not see anything fundamentally wrong with the current approach. (I haven't had
the time to read ecstatic's new docs yet.) That said, if you think this should
be refactored anyway and all you need is an excuse, I am fine with being that
excuse. ;)

(Just a quick reply via email; I'm too busy for Zulip for another week I'm afraid.)

ecstatic-morse (Oct 28 2019 at 00:08, on Zulip):

One limitation is that it doesn't extend to loops, e.g. loop { x = &0 } will fail.

ecstatic-morse (Oct 28 2019 at 01:53, on Zulip):

Found this by accident while working on #65883

Last update: Apr 03 2020 at 17:05UTC