Stream: t-compiler/const-eval

Topic: array lengths #69296


pnkfelix (Mar 26 2020 at 18:21, on Zulip):

Hi @WG-const-eval ! I had a question that originated from my looking at ways to address issue #69296

pnkfelix (Mar 26 2020 at 18:22, on Zulip):

my basic question is: are the rules governing the static+dynamic semantics of the length (const) expression in an array type meant to be the same as the rules governing the right hand side of const items?

pnkfelix (Mar 26 2020 at 18:22, on Zulip):

or is that not at all our intention?

pnkfelix (Mar 26 2020 at 18:24, on Zulip):

for some reason, when I first looked at #69296, I had assumed that an array length expression should be subject to the same static restrictions as an expression in a const item. But after thinking further on the matter, I'm not sure where I got that impression. So I figured it would be best to check with you all about it.

eddyb (Mar 26 2020 at 19:39, on Zulip):

@pnkfelix ugh that's just a duplicate

eddyb (Mar 26 2020 at 19:40, on Zulip):

@pnkfelix the main issue is #43408

eddyb (Mar 26 2020 at 19:41, on Zulip):

#![feature(const_generics)] currently acts as a toggle for the correct behavior (that without lazy normalization will cause cycle errors in some cases)

eddyb (Mar 26 2020 at 19:42, on Zulip):

but also, I've suggested recently that for array lengths inside bodies (as opposed to in signatures or where clauses), we could just apply the fix on stable (cc @varkor)

eddyb (Mar 26 2020 at 19:44, on Zulip):

I should just go do that before I forget tbh

eddyb (Mar 27 2020 at 00:57, on Zulip):

@varkor @pnkfelix taadaa #70452

eddyb (Mar 27 2020 at 00:57, on Zulip):

note that this won't handle let _: [_; size_of::<T>()];, only creating an array with a repeat expression

eddyb (Mar 27 2020 at 00:58, on Zulip):

we should be able to handle array types too but it's more effort to check correctly that they are indeed inside a body

eddyb (Mar 27 2020 at 00:59, on Zulip):

@varkor so I probably would want to just go to sleep now, but here's a conundrum: can enum discriminants depend on generics in scope

eddyb (Mar 27 2020 at 01:00, on Zulip):

this is still unstable:

enum MyWeirdOption<T> {
    None = 33,
    Some(T) = 77,
}
eddyb (Mar 27 2020 at 01:01, on Zulip):

and without (T) you get "parameter T is never used"

eddyb (Mar 27 2020 at 01:02, on Zulip):

nice, it ICEs: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=4da467fd4fe048d25c42f37853bd9c78

varkor (Mar 27 2020 at 01:14, on Zulip):

can enum discriminants depend on generics in scope

you don't mean giving an enum variant a discriminant whose value is a const generic parameter, do you? :cold_sweat:

varkor (Mar 27 2020 at 01:15, on Zulip):

you did mean that…

varkor (Mar 27 2020 at 01:18, on Zulip):

do we want that to be supported?

varkor (Mar 27 2020 at 01:18, on Zulip):

I'm going to assume not, and that we should give it a proper error message

eddyb (Mar 27 2020 at 01:19, on Zulip):

@oli @varkor btw check this out https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=ba0ae8e0eb712b342a61a776ac52c62f

eddyb (Mar 27 2020 at 01:19, on Zulip):

polymorphic evaluation ftw :D

varkor (Mar 27 2020 at 01:20, on Zulip):

I'm quite surprised that actually works

eddyb (Mar 27 2020 at 01:20, on Zulip):

anyway I just opened #70453 for the enum discriminant case

eddyb (Mar 27 2020 at 01:21, on Zulip):

@varkor I'm not, given how many miri bugs had to be fixed for it to work :P

eddyb (Mar 27 2020 at 01:21, on Zulip):

although I'm not sure we even have that as a testcase

varkor (Mar 27 2020 at 01:21, on Zulip):

haha

varkor (Mar 27 2020 at 01:22, on Zulip):

we should just stabilise it there

eddyb (Mar 27 2020 at 01:22, on Zulip):

note that it doesn't work without #![feature(const_generics)] because w/o it the generics are bugged

varkor (Mar 27 2020 at 01:22, on Zulip):

I mean, what other parts of const generics were people really waiting for?

varkor (Mar 27 2020 at 01:22, on Zulip):

this is the big one

varkor (Mar 27 2020 at 01:23, on Zulip):

oh, I guess we just need lazy normalisation for this, not const generics

eddyb (Mar 27 2020 at 01:23, on Zulip):

yeah

eddyb (Mar 27 2020 at 01:23, on Zulip):

I wonder if we can whitelist function signatures

varkor (Mar 27 2020 at 01:25, on Zulip):

I was hoping #67890 would be merged soon regardless, but it seems @Ben Lewis is busy at the moment

eddyb (Mar 27 2020 at 01:27, on Zulip):

uh oh what is this failure, I don't see a diff <https://github.com/rust-lang/rust/pull/70452/checks?check_run_id=538187978>

eddyb (Mar 27 2020 at 01:28, on Zulip):

also 21 minutes to that failure? damn GHA is fast

eddyb (Mar 27 2020 at 01:29, on Zulip):

@varkor also, this *mut T where T: Sized having fixed layout is kind of crucial for polymorphization, although not @davidtwco's initial work

varkor (Mar 27 2020 at 01:31, on Zulip):

uh oh what is this failure, I don't see a diff

that is strange

varkor (Mar 27 2020 at 01:32, on Zulip):

I'm sure I've encountered this before

varkor (Mar 27 2020 at 01:32, on Zulip):

but it's too late for me to be able to recall simple things like that

varkor (Mar 27 2020 at 01:33, on Zulip):

also, this *mut T where T: Sized having fixed layout is kind of crucial for polymorphization

ahh, okay

varkor (Mar 27 2020 at 01:36, on Zulip):

I'm falling asleep, so I'm going to head off — good luck fixing those two tests!

eddyb (Mar 27 2020 at 01:41, on Zulip):

well I don't think there's anything wrong with the tests :P

eddyb (Mar 27 2020 at 01:41, on Zulip):

unless they were added in between me branching off master and opening the PR

eddyb (Mar 27 2020 at 09:10, on Zulip):

@varkor lmao https://github.com/rust-lang/rust/pull/70452#issuecomment-604860039

varkor (Mar 27 2020 at 12:17, on Zulip):

haha

pnkfelix (Mar 27 2020 at 14:18, on Zulip):

@eddyb should we at least signal a proper error here rather than ICE'ing?

pnkfelix (Mar 27 2020 at 14:19, on Zulip):

I guess its not worth the effort to fix it

eddyb (Mar 27 2020 at 14:20, on Zulip):

@pnkfelix if it were easy (without accidentally changing the semantics irreversibly) we would've done it years ago

eddyb (Mar 27 2020 at 14:20, on Zulip):

I guess the one thing I regret is not doing a whitelisting approach and just let the weirder situations continue to ICE or w/e

pnkfelix (Mar 27 2020 at 14:20, on Zulip):

yeah. I was thinking of something along the lines of adding a rib

eddyb (Mar 27 2020 at 14:20, on Zulip):

yeah that's the one thing we don't want to do, because the generics are in scope

eddyb (Mar 27 2020 at 14:21, on Zulip):

it's typeck who has to hide them because w/o lazy normalization several situations turn into cycle errors

pnkfelix (Mar 27 2020 at 14:22, on Zulip):

okay. thanks for feedback.

eddyb (Mar 27 2020 at 14:24, on Zulip):

@pnkfelix also, funnily enough, #70452 breaks git2, so there's at least one failure mode I haven't considered (it's not a query cycle though, but rather a "broken MIR" ICE)

eddyb (Mar 27 2020 at 14:24, on Zulip):

is MIR supposed to be fully normalized or is that only for performance reasons? (and coercion during typeck I suppose)

eddyb (Mar 27 2020 at 14:25, on Zulip):

I'm starting to remember the bugs from MIR typeck missing normalization calls

pnkfelix (Mar 27 2020 at 14:25, on Zulip):

eddyb said:

is MIR supposed to be fully normalized or is that only for performance reasons? (and coercion during typeck I suppose)

this is a great question

eddyb (Mar 27 2020 at 14:26, on Zulip):

oh wait even if we normalized during typeck, Expr::Repeat goes through ty::Const::from_anon_const again during MIR building

eddyb (Mar 27 2020 at 14:26, on Zulip):

so it would have to be normalized during MIR building or during MIR typeck

Last update: Apr 03 2020 at 17:10UTC