Stream: general

also using the const_fn feature allows to use &mut in const fns. So currently the error indicates that the user should enable theconst_fnfeature

Christian Poveda (Nov 18 2019 at 14:59, on Zulip):

should I change it so it suggests to enable the new feature?

Christian Poveda (Nov 18 2019 at 15:27, on Zulip):

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

oli (Nov 19 2019 at 10:09, on Zulip):

:face_palm: oh, sorry I didn't read the thread topic, yea you should add some tests in src/test/ui/consts

centril (Nov 19 2019 at 11:31, on Zulip):

(in a subdirectory please, not immediately in the ui/consts/)

Christian Poveda (Nov 19 2019 at 15:42, on Zulip):

and those should be the tests checking that the feature works right?

Christian Poveda (Nov 19 2019 at 15:42, on Zulip):

(not the test checking that using this is forbidden without the gate)

oli (Nov 20 2019 at 11:37, on Zulip):

yes

Christian Poveda (Nov 21 2019 at 13:53, on Zulip):

https://github.com/rust-lang/rust/issues/66556

Christian Poveda (Nov 21 2019 at 13:53, on Zulip):

Oh shoo, I forgot about tidy

Christian Poveda (Nov 21 2019 at 13:53, on Zulip):

does this have an open issue?

Christian Poveda (Nov 21 2019 at 13:54, on Zulip):

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

oli (Nov 21 2019 at 14:08, on Zulip):

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

centril (Nov 21 2019 at 14:10, on Zulip):

https://github.com/rust-lang/rust/issues/57349

Christian Poveda (Nov 22 2019 at 01:53, on Zulip):

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.

Christian Poveda (Nov 22 2019 at 01:55, on Zulip):

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
}

oli (Nov 22 2019 at 13:19, on Zulip):

yea, *x = y should be under the same feature gate

Christian Poveda (Nov 22 2019 at 14:17, on Zulip):

Christian Poveda (Nov 22 2019 at 16:32, on Zulip):

what should I do with the broken unleash-the-miri-inside-of-you tests?

Christian Poveda (Nov 22 2019 at 23:12, on Zulip):

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

centril (Nov 22 2019 at 23:26, on Zulip):

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

Christian Poveda (Nov 23 2019 at 00:59, on Zulip):

ok then, I'll push the changes.

Last update: Dec 12 2019 at 00:45UTC