-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
no longer promote non-pattern const functions #67531
Conversation
@bors try |
WIP: no longer promote non-pattern const functions This is trying to pack-pedal a bit on promotion feature creep, as proposed by @eddyb [here](rust-lang/const-eval#19 (comment)): possibly, a sane subset of `const fn` that we could promote are those that are just constructors -- the same subset that we might want to allow in pattern position at some point. So, this removes the `rustc_promotable` attribute from the three functions they identified that do not fit this pattern. The first step is to run crater to see if there is code in the wild that relies on this being promotable. r? @oli-obk
☀️ Try build successful - checks-azure |
@pietroalbini could we get a check-only crater run for this? |
@craterbot check (@RalfJung you should be able to do ^-- as well.) |
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
🎉 Experiment
|
Noone seems to be using this. nominating for @rust-lang/libs discussion This PR breaks hypothetical uses of let x: &'static Duration = &Duration::from_millis(42); The above happened because the The following two snippets will keep working as they would with any user defined let x: &Duration = &Duration::from_millis(42); and const X: &Duration = &Duration::from_millis(42); will keep working as they do now, as promotion inside constants has none of the problematic side effects. |
Adding the language team as well; I think it would be quite desirable from a language POV to nix the promotability of these non-constructor functions. |
We discussed in the 2020-01-02 @rust-lang/lang team meeting and decided to approve this. @bors r+ |
📋 Looks like this PR is still in progress, ignoring approval. Hint: Remove WIP from this PR's title when it is ready for review. |
Awesome, thanks :) @bors r=nikomatsakis |
📌 Commit 368ac73 has been approved by |
…akis no longer promote non-pattern const functions This is trying to pack-pedal a bit on promotion feature creep, as proposed by @eddyb [here](rust-lang/const-eval#19 (comment)): possibly, a sane subset of `const fn` that we could promote are those that are just constructors -- the same subset that we might want to allow in pattern position at some point. So, this removes the `rustc_promotable` attribute from the three functions they identified that do not fit this pattern. The first step is to run crater to see if there is code in the wild that relies on this being promotable. r? @oli-obk
⌛ Testing commit 368ac73 with merge 1eb8aca1a6dc799978a3c9f82147de7e9f909748... |
…akis no longer promote non-pattern const functions This is trying to pack-pedal a bit on promotion feature creep, as proposed by @eddyb [here](rust-lang/const-eval#19 (comment)): possibly, a sane subset of `const fn` that we could promote are those that are just constructors -- the same subset that we might want to allow in pattern position at some point. So, this removes the `rustc_promotable` attribute from the three functions they identified that do not fit this pattern. The first step is to run crater to see if there is code in the wild that relies on this being promotable. r? @oli-obk
Your PR failed (pretty log, raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem. Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
Rollup of 8 pull requests Successful merges: - #66913 (Suggest calling method when first argument is `self`) - #67531 (no longer promote non-pattern const functions) - #67773 (Add a test for #37333) - #67786 (Nix reexports from `rustc_span` in `syntax`) - #67789 (Cleanup linkchecker whitelist) - #67810 (Implement uncommon_codepoints lint.) - #67835 (tweak wording of mismatched delimiter errors) - #67845 (Also remove const-hack for abs) Failed merges: r? @ghost
I wonder if we could add a check, forcing a very trivial body for This might be easy, if entire MIR body looks like |
de-promote Duration::from_secs In rust-lang#67531, we removed the `rustc_promotable` attribute from a bunch of `Duration` methods, but not from `Duration::from_secs`. This makes the current list of promotable functions the following (courtesy of @ecstatic-morse): * `INT::min_value`, `INT::max_value` * `std::mem::size_of`, `std::mem::align_of` * `RangeInclusive::new` (backing `x..=y`) * `std::ptr::null`, `std::ptr::null_mut` * `RawWaker::new`, `RawWakerVTable::new` ??? * `Duration::from_secs` I feel like the last one stands out a bit here -- the rest are all very core language primitives, and `RawWaker` has a strong motivation for getting a `'static` vtable. But a `&'static Duration`? That seems unlikely. So I propose we no longer promote calls to `Duration::from_secs`, which is what this PR does. rust-lang#67531 saw zero regressions and I am not aware of anyone complaining that this broke their (non-cratered) code, so I consider it likely the same will be true here, but of course we'd do a crater run. See [this document](https://github.com/rust-lang/const-eval/blob/master/promotion.md) for some more background on promotion and rust-lang/const-eval#19 for some of the concerns around promoting function calls.
de-promote Duration::from_secs In rust-lang#67531, we removed the `rustc_promotable` attribute from a bunch of `Duration` methods, but not from `Duration::from_secs`. This makes the current list of promotable functions the following (courtesy of @ecstatic-morse): * `INT::min_value`, `INT::max_value` * `std::mem::size_of`, `std::mem::align_of` * `RangeInclusive::new` (backing `x..=y`) * `std::ptr::null`, `std::ptr::null_mut` * `RawWaker::new`, `RawWakerVTable::new` ??? * `Duration::from_secs` I feel like the last one stands out a bit here -- the rest are all very core language primitives, and `RawWaker` has a strong motivation for getting a `'static` vtable. But a `&'static Duration`? That seems unlikely. So I propose we no longer promote calls to `Duration::from_secs`, which is what this PR does. rust-lang#67531 saw zero regressions and I am not aware of anyone complaining that this broke their (non-cratered) code, so I consider it likely the same will be true here, but of course we'd do a crater run. See [this document](https://github.com/rust-lang/const-eval/blob/master/promotion.md) for some more background on promotion and rust-lang/const-eval#19 for some of the concerns around promoting function calls.
de-promote Duration::from_secs In rust-lang#67531, we removed the `rustc_promotable` attribute from a bunch of `Duration` methods, but not from `Duration::from_secs`. This makes the current list of promotable functions the following (courtesy of @ecstatic-morse): * `INT::min_value`, `INT::max_value` * `std::mem::size_of`, `std::mem::align_of` * `RangeInclusive::new` (backing `x..=y`) * `std::ptr::null`, `std::ptr::null_mut` * `RawWaker::new`, `RawWakerVTable::new` ??? * `Duration::from_secs` I feel like the last one stands out a bit here -- the rest are all very core language primitives, and `RawWaker` has a strong motivation for getting a `'static` vtable. But a `&'static Duration`? That seems unlikely. So I propose we no longer promote calls to `Duration::from_secs`, which is what this PR does. rust-lang#67531 saw zero regressions and I am not aware of anyone complaining that this broke their (non-cratered) code, so I consider it likely the same will be true here, but of course we'd do a crater run. See [this document](https://github.com/rust-lang/const-eval/blob/master/promotion.md) for some more background on promotion and rust-lang/const-eval#19 for some of the concerns around promoting function calls.
de-promote Duration::from_secs In rust-lang#67531, we removed the `rustc_promotable` attribute from a bunch of `Duration` methods, but not from `Duration::from_secs`. This makes the current list of promotable functions the following (courtesy of @ecstatic-morse): * `INT::min_value`, `INT::max_value` * `std::mem::size_of`, `std::mem::align_of` * `RangeInclusive::new` (backing `x..=y`) * `std::ptr::null`, `std::ptr::null_mut` * `RawWaker::new`, `RawWakerVTable::new` ??? * `Duration::from_secs` I feel like the last one stands out a bit here -- the rest are all very core language primitives, and `RawWaker` has a strong motivation for getting a `'static` vtable. But a `&'static Duration`? That seems unlikely. So I propose we no longer promote calls to `Duration::from_secs`, which is what this PR does. rust-lang#67531 saw zero regressions and I am not aware of anyone complaining that this broke their (non-cratered) code, so I consider it likely the same will be true here, but of course we'd do a crater run. See [this document](https://github.com/rust-lang/const-eval/blob/master/promotion.md) for some more background on promotion and rust-lang/const-eval#19 for some of the concerns around promoting function calls.
de-promote Duration::from_secs In rust-lang#67531, we removed the `rustc_promotable` attribute from a bunch of `Duration` methods, but not from `Duration::from_secs`. This makes the current list of promotable functions the following (courtesy of @ecstatic-morse): * `INT::min_value`, `INT::max_value` * `std::mem::size_of`, `std::mem::align_of` * `RangeInclusive::new` (backing `x..=y`) * `std::ptr::null`, `std::ptr::null_mut` * `RawWaker::new`, `RawWakerVTable::new` ??? * `Duration::from_secs` I feel like the last one stands out a bit here -- the rest are all very core language primitives, and `RawWaker` has a strong motivation for getting a `'static` vtable. But a `&'static Duration`? That seems unlikely. So I propose we no longer promote calls to `Duration::from_secs`, which is what this PR does. rust-lang#67531 saw zero regressions and I am not aware of anyone complaining that this broke their (non-cratered) code, so I consider it likely the same will be true here, but of course we'd do a crater run. See [this document](https://github.com/rust-lang/const-eval/blob/master/promotion.md) for some more background on promotion and rust-lang/const-eval#19 for some of the concerns around promoting function calls.
This is trying to pack-pedal a bit on promotion feature creep, as proposed by @eddyb here: possibly, a sane subset of
const fn
that we could promote are those that are just constructors -- the same subset that we might want to allow in pattern position at some point.So, this removes the
rustc_promotable
attribute from the three functions they identified that do not fit this pattern. The first step is to run crater to see if there is code in the wild that relies on this being promotable.r? @oli-obk