doing this "right" is blocked on
&mut
-in-const
cc @Christian Poveda fun coincidence
I'll get this done ASAP
There's no rush! I just found it funny
Also I forgot to link to the post: https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/const.20fn.20wishlist/near/180904827
does this feature has an RFC or something?
to give it a proper name
nope
const_mut_refs
or sth
idk, be creative :D
unleash-the-const-mut-ref-inside-you?
:P
heh
I'll submit a PR later today
where should the tests go?
mir-opt
I'd wager some mir opt tests will be affected even without you adding a test
if that is the case... just don't add a test
the other tests are covering you
unfortunately these tests don't know about --bless
so they are a pain to adjust
also using the const_fn
feature allows to use &mut
in const fns. So currently the error indicates that the user should enable theconst_fn
feature
should I change it so it suggests to enable the new feature?
I'd wager some mir opt tests will be affected even without you adding a test
none of the tests in ./x.py test --stage 1 src/test/mir-opt/
failed
:face_palm: oh, sorry I didn't read the thread topic, yea you should add some tests in src/test/ui/consts
(in a subdirectory please, not immediately in the ui/consts/
)
and those should be the tests checking that the feature works right?
(not the test checking that using this is forbidden without the gate)
yes
Oh shoo, I forgot about tidy
does this have an open issue?
tidy check * 588 error codes * highest error code: E0744 tidy error: /home/christian/Workspace/contrib/rust/src/libsyntax/feature_gate/active.rs:533: no tracking issue for feature const_fn_mut_refs Checking which error codes lack tests... Found 441 error codes Found 0 error codes with no tests Done! some tidy checks failed
idk, check the const fn meta issue, and if there's no issue for mutable references, you can open one and point to it from the meta issue
Hmm now I'm a little confused about what to do with assignments like *x = y
. Not allowing them restricts a lot what can be done with mutable references but I'm not sure about all the implications of allowing them.
I mean, without them we can still do stuff like:
const fn bar(foo: &mut Foo) -> usize { let mut x = foo.x; let y = &mut x; x = *y + 1; x }
yea, *x = y
should be under the same feature gate
Ok
what should I do with the broken unleash-the-miri-inside-of-you
tests?
yea,
*x = y
should be under the same feature gate
Also, I'm thorn about how mutable borrows should behave outside constant contexts. So for example
struct Foo { x: usize } const fn bar(foo: &mut Foo) -> usize { let x = &mut foo.x; *x = 1; *x } fn main() { let _: [(); bar(&mut Foo { x: 0 })] = [(); 1]; }
Will work after enabling mutable dereferences. But at the same time stuff like
The second fn main
example looks correct. The final value of a constant is frozen/immutable - it would be unsound if you could actually make the value FOO.x == 1
ok then, I'll push the changes.