-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Treat const fn
like fn
for promotion.
#75586
Comments
#75502 is a crater experiment to stop doing this (at least for the case of |
One data point I want to bring up is rust-lang/rfcs#1229 (comment)
From that reading I'm getting the vibes that @nikomatsakis would be mostly fine with hard erroring on promotion or even const propagation of failing code in const fn. But since we did not address this during the stabilization of |
The reason promotion in fn foo<T: Trait>() -> &'static i32 {
if T::ASSOC != 0 { &(14/T::ASSOC) } else { panic!() }
} which would never cause div-by-zero at runtime, but will have a failing CTFE query during codegen if And all of this applies equally to |
…n-const-fn, r=RalfJung Use implicit (not explicit) rules for promotability by default in `const fn` For crater run. See rust-lang/const-eval#54 (comment). cc rust-lang#75586
…tatic-morse Some promotion cleanup Based on top of both rust-lang#75502 and rust-lang#75585, this does some cleanup of the promotion code. The last 2 commits are new. * Remove the remaining cases where `const fn` is treated different from `fn`. This means no longer promoting ptr-to-int casts, raw ptr operations, and union field accesses in `const fn` -- or anywhere, for that matter. These are all unstable in const-context so this should not break any stable code. Fixes rust-lang#75586. * ~~Promote references to statics even outside statics (i.e., in functions) for consistency.~~ * Promote `&mut []` everywhere, not just in non-`const` functions, for consistency. * Explain why we do not promote deref's of statics outside statics. ~~(This is the only remaining direct user of `const_kind`.)~~ This can only land once the other two PRs land; I am mostly putting this up already because I couldn't wait ;) and to get some feedback from @rust-lang/wg-const-eval .
…tatic-morse Some promotion cleanup Based on top of both rust-lang#75502 and rust-lang#75585, this does some cleanup of the promotion code. The last 2 commits are new. * Remove the remaining cases where `const fn` is treated different from `fn`. This means no longer promoting ptr-to-int casts, raw ptr operations, and union field accesses in `const fn` -- or anywhere, for that matter. These are all unstable in const-context so this should not break any stable code. Fixes rust-lang#75586. * ~~Promote references to statics even outside statics (i.e., in functions) for consistency.~~ * Promote `&mut []` everywhere, not just in non-`const` functions, for consistency. * Explain why we do not promote deref's of statics outside statics. ~~(This is the only remaining direct user of `const_kind`.)~~ This can only land once the other two PRs land; I am mostly putting this up already because I couldn't wait ;) and to get some feedback from @rust-lang/wg-const-eval .
…tatic-morse Some promotion cleanup Based on top of both rust-lang#75502 and rust-lang#75585, this does some cleanup of the promotion code. The last 2 commits are new. * Remove the remaining cases where `const fn` is treated different from `fn`. This means no longer promoting ptr-to-int casts, raw ptr operations, and union field accesses in `const fn` -- or anywhere, for that matter. These are all unstable in const-context so this should not break any stable code. Fixes rust-lang#75586. * ~~Promote references to statics even outside statics (i.e., in functions) for consistency.~~ * Promote `&mut []` everywhere, not just in non-`const` functions, for consistency. * Explain why we do not promote deref's of statics outside statics. ~~(This is the only remaining direct user of `const_kind`.)~~ This can only land once the other two PRs land; I am mostly putting this up already because I couldn't wait ;) and to get some feedback from @rust-lang/wg-const-eval .
…tatic-morse Some promotion cleanup Based on top of both rust-lang#75502 and rust-lang#75585, this does some cleanup of the promotion code. The last 2 commits are new. * Remove the remaining cases where `const fn` is treated different from `fn`. This means no longer promoting ptr-to-int casts, raw ptr operations, and union field accesses in `const fn` -- or anywhere, for that matter. These are all unstable in const-context so this should not break any stable code. Fixes rust-lang#75586. * ~~Promote references to statics even outside statics (i.e., in functions) for consistency.~~ * Promote `&mut []` everywhere, not just in non-`const` functions, for consistency. * Explain why we do not promote deref's of statics outside statics. ~~(This is the only remaining direct user of `const_kind`.)~~ This can only land once the other two PRs land; I am mostly putting this up already because I couldn't wait ;) and to get some feedback from @rust-lang/wg-const-eval .
rust-lang/const-eval#19 gives many arguments for why we should not promote
const fn
calls. However, we currently do promoteconst fn
calls inconst fn
, even though that has all the same problems. This fails to compile, but really we shouldn't make this a hard error:This does not just apply to
const fn
calls; all promotion insideconst fn
should be treated like insidefn
.Cc @rust-lang/wg-const-eval
The text was updated successfully, but these errors were encountered: