Repository navigation
Never allow const fn calls in promoteds #19
Description
Activity
I suggest that we never allow promoting const fn calls without an explicit request for constness, e.g. by inserting a constant and promoting a use of that constant, or by a future extension to the language for unnamed constant expressions.
Full agreement!
This means we'll need to split const qualification into "allowed in const context" and "allowed in a promoted", where the latter will be a strict subset of the former. Semantically, heap allocations and panics and ptr comparison will be allowed in the former but not in the latter. Promotion-safe is more strict than const-safe. Is that correct?
One more question: The user could write all of these things in a
constas well, not just in aconst fn. Why are things any different (better, presumably) then?The user could write all of these things in a const as well, not just in a const fn. Why are things any different (better, presumably) then?
When you use a constant, you are explicitly opting into this behavior. Promotion on the other hand happens silently. So if we expand on what promotion can do, we'd turn existing code into promoted code, which might change behavior.
Promotion-safe is more strict than const-safe. Is that correct?
Yes, the set of promotable code is a strict subset of const code. There's nothing that gets promoted that is not also allowed inside constants.
When you use a constant, you are explicitly opting into this behavior.
Constants follow the principle that they should be equivalent to copy-pasting their definition at every use site. I agree with your reasoning for panics, but not for heap allocations: Following the aforementioned principle,
const FOO: *mut i32 = Box::leak(Box::new(0))should not be accepted.Yes, the set of promotable code is a strict subset of const code. There's nothing that gets promoted that is not also allowed inside constants.
Okay, that's great. :)
As usual, I propose we aim for getting a precise semantic understanding of what makes code const-(un)safe and promotion-(un)safe -- meaning a criterion on program executions, not source code. Something that you could even code into the miri engine (also see #17).For heap allocations and pointer comparisons, that's easy: A promotion-safe execution never dos either. For panics, though... we do promote arithmetic, which can also panic. What's the criterion here?
we promote arithmetics, but not their assertions. While we could do the same for panics, that requires quite some compiler complexity that I'd rather avoid having to support for forever.
Constants follow the principle that they should be equivalent to copy-pasting their definition at every use site.
Copy-pasting their value at every use site, not their code. This is not a preprocessor. Constants are evaluated once and the result is copied at every use site. We already do this e.g. for
const FOO: &&&&u32 = &&&&1;. We only copy the value, so the outer most reference, everything else stays the same. We do reserve the right to arbitrarily duplicate any reference in that constant though.I agree with your reasoning for panics, but not for heap allocations: Following the aforementioned principle, const FOO: *mut i32 = Box::leak(Box::new(0)) should not be accepted.
We are not copy pasting the
Box::leak(Box::New(0)), but the memory of the evaluated version ofFOO(so an Allocation withsize_of<usize>()bytes whose relocation points to another allocation of4bytes which contains a0. There's nothing relating to the heap in this value. Values do not care about heap, stack, static, ... The only thing we do care about is the identity of the memory ofstaticitems.we promote arithmetics, but not their assertions. While we could do the same for panics, that requires quite some compiler complexity that I'd rather avoid having to support for forever.
Oh right! The arithmetic doesn't panic, it just returns a bool that later triggers a panic. (And once upon a time I made arithmetic panic itself and that broke promotion.^^)
Okay, this makes sense. So we can just add "does not panic" as a third criterion for code being promotion-safe. All
#[rustc_promoteable]functions must satisfy this.Copy-pasting their value at every use site, not their code. This is not a preprocessor. Constants are evaluated once and the result is copied at every use site. We already do this e.g. for const FOO: &&&&u32 = &&&&1;. We only copy the value, so the outer most reference, everything else stays the same. We do reserve the right to arbitrarily duplicate any reference in that constant though.
Hm... I always saw this as promotion happening after copy-pasting. But I guess this makes sense.
Can we have value-based checks for Drop, Sync and UnsafeCell then, please? :D
Can we have value-based checks for Drop, Sync and UnsafeCell then, please? :D
With your value visitor that is entirely reasonable now. Last time I tried to implement it I was hooking closures into the validation code and it was horrible
For future searchers, it's spelled
rustc_promotable.So... apparently there is desire for implicit promotion of certain const fns.
What we could do is stabilize a
#[promotable]attribute for const fns which is much stricter about the things that you may do. We'd basically restrict it to integer math, trivial casts, aggregate construction, let bindings and calls to other#[promotable]functions or intrinsics. (this covers all the current use cases)🕯️ summons @Centril 🕯️
Maybe we call it
#[pure]😆@eddyb mentions that
This is another reason for my position that "cheating" with "exposed bodies" is actually good overall, as it significantly reduces complexity while allowing maximal features but still keeping "significance of fn bodies to stability" opt-in.
This would help with const fns that were const fn to start out with, but not e.g. when changing
foofrom not const to const in the following code:fn foo() { panic!() } fn main() { let x = &foo(); // ERROR if `foo` is `const`, `panic` if not }
Also, specifically for cases like that, you can/should leave behind a MIR terminator shaped like the call (with its success and unwind edges), that would be replaced with an unconditional panic invoke (basically an always-failing
Assertterminator) at monomorphization time.EDIT: It's how we promote things like indexing or checked divisions: we promote the computation, while the checking code, including the
Assert, stays where it was.So... apparently there is desire for implicit promotion of certain const fns.
Well, there's desire for many things. ;) What's the argument against explicit promotion through e.g.
constblocks?What's the argument against explicit promotion through e.g. const blocks?
I guess the argument is that we already stabilized a few of these XD
That sounds like "we made a mistake, so now let's go full steam ahead to get more of it".
I do not see how that's an argument for introducing another attribute with its own analysis etc.
🕯 summons @Centril 🕯
😂
Maybe we call it
#[pure]😆Eh... twas a joke?
That sounds like "we made a mistake, so now let's go full steam ahead to get more of it".
I do not see how that's an argument for introducing another attribute with its own analysis etc.
Depends on how complicated the analysis is... We already do have it sort of so there's no new fundamental complexity?
9 remaining items
Also Cc @ecstatic-morse, who seems to also be involved in the const-pattern effort.
A lot has happened in the last 2 years. :) See the updated promotion docs in #67 for details.
@oli-obk the only remaining promotion of
const fnis insideconst/staticbodies. There is a lot of code out there relying on this, so I currently consider it unlikely that we can take back this decision. This means we have to be careful never to evaluate constants inconst/staticbodies in potentially dead code -- but we probably can do that (we already have a test for this,src/test/ui/consts/const-eval/promoted_errors.rs; I'll expand that test a bit in rust-lang/rust#85112).So I think this issue can be closed, finally.
I want to reiterate on the discussion about
const fncalls to promoteds. During the stabilization ofmin_const_fn, we recently punted on the topic by not promoting anyconst fncalls, except a specific list of "known to be safe" functions likestd::mem::size_of.I want to argue for forbidding the promotion of
const fncalls forever (leaving in the existing escape hatch for the libstd is not very expensive, and we may just want to start linting about it for a few years and remove it at some point).I show how three future extensions to the const evaluator are either incompatible with promoting
const fncalls or increase the compiler complexity, suprises for users and general lanugage complexity.panicky code in
const fnThe function
foo, defined aswill panic when executed. If used in a promoted, e.g.
this would create a compile-time error about a panic reached during const eval. Unfortunately that means that
would also cause this compile-time error, even though the user has no reason to suspect this to not compile.
While we can demote such compile-time errors to panics by compiling them to a call to the panic machinery with the original message, this would break the backtrace and would generally require some rather complex code to support this pretty useless case.
heap allocations in
const fnThe function
foo, defined aswill create a heap allocation if executed. When evaluated during const eval, it will not create a heap allocation, but sort of create a new unnamed static item for every call.
This means that
would be perfectly legal code. When used in a promoted,
we'd also not create a heap allocation, but rather another unnamed static.
This also means that
would do that, even though the user expects that to produce a new heap allocation, place it in a temporary and return a reference to it. In reality there would be only one single allocation. The user might even be tempted to mutate memory via that
*mut u32, which would definitely be UB. While I don't expect the above code to be written, I imagine that there are many ways for accidentally sneaking a&operator into some expression that will end up causing a promotion to happen.Defined runtime code can be promoted and suddenly stop compiling
Will work just fine at compile-time, but at runtime, comparing pointers to different allocations can be problematic. While this case is deterministic between compile-time and runtime due to the "check every element" fallback,
depends on its arguments. E.g.
foo(&42, &42)may returnfalseat compile-time andtrueat runtime due to deduplication in llvm.If we extend this to promotion,
will get evaluated at compile-time, but have a result different from runtime, even though the user did not request that.
Conclusion
Since I presume that we'll want all of the above const eval features (we even support the first one on stable rustc) at some point or another, I suggest that we never allow promoting const fn calls without an explicit request for constness, e.g. by inserting a constant and promoting a use of that constant, or by a future extension to the language for unnamed constant expressions.