Stream: t-compiler/const-eval

Topic: #57349 `&mut T` in const fn


Lokathor (Jan 29 2020 at 04:23, on Zulip):

(There didn't seem to be a zulip topic for this one so I figured we could open one. Mods please merge this if I missed it.)

It seems like a very obvious thing to have, and there's not much design to be done for this particular thing. The language allows mutable references in const or not, there's no syntax questions or anything like that. I think that the hold up, if any, would be in the const evaluator.

Has the past year of general const evaluation improvement made this something that could be pushed towards stable any time sooner than "no ETA"?

Christian Poveda (Jan 29 2020 at 05:10, on Zulip):

I was planning on retaking this in a few weeks but I have no idea when this will be suitable for stabilization.

oli (Jan 29 2020 at 12:02, on Zulip):

I think there are still a few issues (e.g. const FOO: &mut T, let me grab the topic.

oli (Jan 29 2020 at 12:04, on Zulip):

https://rust-lang.zulipchat.com/#narrow/stream/146212-t-compiler.2Fconst-eval/topic/unsoundness.20in.20constant.20mutable.20borrows/near/183594829

oli (Jan 29 2020 at 12:05, on Zulip):

Maybe we should split the feature gate into &mut in args/variable types and &mut in const types and return types

ecstatic-morse (Jan 30 2020 at 09:25, on Zulip):

If we were to ban the creation of a mutable reference to a local at the "top-level", inside a const or static initializer, I think we can allow everything it inside const fn. Inside a const fn, the borrow checker does the "escape analysis" to ensure a mutable reference does not escape to the containing scope. However, at the top-level, everything is 'static so &mut can escape from the initializer into the final value of a const.

ecstatic-morse (Jan 30 2020 at 09:28, on Zulip):

As long as we are willing to settle for post monomorphization errors for programs with UB, we can also allow *mut in the return type of a const fn.

Christian Poveda (Jan 31 2020 at 15:59, on Zulip):

I think I'll need a bit of mentoring for this

oli (Jan 31 2020 at 17:12, on Zulip):

hmm... not 100% sure, but isn't this essentially equivalent to the existing interior mutability checks?

oli (Jan 31 2020 at 17:12, on Zulip):

ah no, &&mut T is technically ok

oli (Jan 31 2020 at 17:12, on Zulip):

I'd be fine with being overconservative for now and forbidding &&mut T right now

oli (Jan 31 2020 at 17:13, on Zulip):

So we could just extend https://github.com/rust-lang/rust/blob/ecde10fc283530db0db42e2c3e2e3132e809b139/src/librustc_mir/transform/check_consts/qualifs.rs#L196 to also cover mutable references

Last update: Jul 02 2020 at 18:55UTC