Hey @Oli while investigating issues associated with PR #55532, I encountered the following seeming oddity: on the test in question, I get slightly different diagnostic output based on whether I do or don't include
I wanted to know if 1. you are aware of this, 2. if its currently expected behavior, and 3. if there's any hope of ... eliminating the difference here?
@pnkfelix seems to be related to overflow checks?
Oh ... because our semantics for overflow differ for with
-O vs without, hmmm, yes?
for anything MIR-based, that is kind-of expected. Not sure how much can be done. The MIR, once generated, encodes whether arithmetic is checked for overflow or not, so anything just executing the MIR will only do overflow checks in debug mode
the thing is the semantics of MIR do not differ
MIR building differs
(I cannot remember now whether the intention was for such checks to be controlled via
-g, but either way, its an excellent hypothesis for why this is arising)
I once was foolish enough to think that I could make MIR interpretation (miri/CTFE) check for overflow even when the MIR does not ask for it
half a year later we had a segfault because of that^^
can you point me to the issue?
well there were other things playing into this as well, it was because promotion happened and CTFE did not the same thing as run-time code
that's just to explain why we do overflow checks only when the MIR explicitly asks for it
can you point me to the issue?
the interesting thing to me here is that the diagnostic output is so similar
const_prop however does special magic to still do overflow checks even in release mode, I think
maybe that special magic is not quite close enough to what debug mode does
like, it seems like const_eval is reporting a problem in either case
but it gets tied in with the other overflow checking in different ways....?
no const_eval involved here
this is not in const context
which opportunistically walks over runtime MIR and interprets the parts of it that it can to provide some diagnostics
its a bad, horrible hack^^
let x: i8 = --128; is not const context?
okay hey I don't know
you have to ask for const context with
otherwise its not const context
I should see how this behaves if you do that
with one glaring exception: promotion
promotion makes some things const context that the user didnt write in const context.
okay, is this a case where promotion applies then?
but in this case, there's no promotion, so this must be the
(because I think that was what I was thinking of. Sure, yeah, that's the ticket)
There's no promotion... because its not a
&--128 or something?
Const prop is slightly hacky, because it had to replicate the old const folding const evaluator
We could make const prop deterministic, so that --release overflows are also detected
But we need to have a big discussion about the future of const prop anyway... I don't think it is good the way it is, because we're partially reimplementing miri
Okay. Well this isn't the only case of a test that depends on the
-O flag (cc T-compiler topic), so I'll leave this be for now