no longer promote non-pattern const functions #67531

RalfJung · 2019-12-22T17:37:46Z

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

RalfJung · 2019-12-22T17:38:06Z

@bors try

bors · 2019-12-22T17:38:22Z

⌛ Trying commit 368ac73 with merge 662bf71...

@eddyb

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

bors · 2019-12-22T20:39:43Z

☀️ Try build successful - checks-azure
Build commit: 662bf71 (662bf71cc5bbfe44a109ab5b7205e12ec319754c)

RalfJung · 2019-12-22T20:49:05Z

@pietroalbini could we get a check-only crater run for this?

Centril · 2019-12-22T21:06:16Z

@craterbot check

(@RalfJung you should be able to do ^-- as well.)

craterbot · 2019-12-22T21:06:18Z

👌 Experiment pr-67531 created and queued.
🤖 Automatically detected try build 662bf71
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

craterbot · 2019-12-26T19:09:53Z

🚧 Experiment pr-67531 is now running

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

craterbot · 2019-12-28T23:05:39Z

🎉 Experiment pr-67531 is completed!
📊 0 regressed and 0 fixed (81904 total)
📰 Open the full report.

⚠️ If you notice any spurious failure please add them to the blacklist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

oli-obk · 2019-12-28T23:37:59Z

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 Duration constructors were one of the very first const fn, created when we didn't know about the unfortunate side effects of permitting const fn calls to get promoted. A detailed explanation of the issues can be found in rust-lang/const-eval#19

The following two snippets will keep working as they would with any user defined const fn. Only the backwards compat hack in libstd will be removed.

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.

Centril · 2019-12-28T23:56:42Z

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.

nikomatsakis · 2020-01-02T20:21:19Z

We discussed in the 2020-01-02 @rust-lang/lang team meeting and decided to approve this.

@bors r+

bors · 2020-01-02T20:21:21Z

📋 Looks like this PR is still in progress, ignoring approval.

Hint: Remove WIP from this PR's title when it is ready for review.

RalfJung · 2020-01-02T20:22:20Z

Awesome, thanks :)

@bors r=nikomatsakis

bors · 2020-01-02T20:22:21Z

📌 Commit 368ac73 has been approved by nikomatsakis

@eddyb

…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

bors · 2020-01-04T01:18:41Z

⌛ Testing commit 368ac73 with merge 1eb8aca1a6dc799978a3c9f82147de7e9f909748...

@eddyb

…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

Centril · 2020-01-04T01:20:37Z

Rolled up into #67853, @bors retry

rust-highfive · 2020-01-04T02:57:48Z

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 @TimNN. (Feature Requests)

@ghost

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

eddyb · 2020-01-16T20:18:34Z

I wonder if we could add a check, forcing a very trivial body for #[rustc_promotable] functions.

This might be easy, if entire MIR body looks like _0 = Foo { x: _1, y: _2, ... } (it should be using all of the fn arguments as fields, possibly using constants for some other fields).

@ecstatic-morse

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.

@ecstatic-morse

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.

@ecstatic-morse

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.

@ecstatic-morse

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.

@ecstatic-morse

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.

no longer promote non-pattern const functions

368ac73

rust-highfive assigned oli-obk Dec 22, 2019

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Dec 22, 2019

craterbot added S-waiting-on-crater Status: Waiting on a crater run to be completed. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 22, 2019

craterbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-crater Status: Waiting on a crater run to be completed. labels Dec 28, 2019

oli-obk added I-nominated T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Dec 28, 2019

Centril added the T-lang Relevant to the language team, which will review and decide on the PR/issue. label Dec 28, 2019

RalfJung changed the title ~~WIP: no longer promote non-pattern const functions~~ no longer promote non-pattern const functions Jan 2, 2020

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 2, 2020

Centril mentioned this pull request Jan 3, 2020

Rollup of 8 pull requests #67846

Closed

Centril mentioned this pull request Jan 4, 2020

Rollup of 8 pull requests #67853

Merged

bors merged commit 368ac73 into rust-lang:master Jan 4, 2020

RalfJung deleted the tame-promotion branch January 8, 2020 09:44

RalfJung mentioned this pull request May 2, 2020

de-promote Duration::from_secs #71796

Merged

RalfJung mentioned this pull request Aug 12, 2020

Solving the problem with promotion rust-lang/const-eval#53

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

no longer promote non-pattern const functions #67531

no longer promote non-pattern const functions #67531

RalfJung commented Dec 22, 2019

RalfJung commented Dec 22, 2019

bors commented Dec 22, 2019

bors commented Dec 22, 2019

RalfJung commented Dec 22, 2019

Centril commented Dec 22, 2019

craterbot commented Dec 22, 2019

craterbot commented Dec 26, 2019

craterbot commented Dec 28, 2019

oli-obk commented Dec 28, 2019

Centril commented Dec 28, 2019

nikomatsakis commented Jan 2, 2020

bors commented Jan 2, 2020

RalfJung commented Jan 2, 2020

bors commented Jan 2, 2020

bors commented Jan 4, 2020

Centril commented Jan 4, 2020

rust-highfive commented Jan 4, 2020

eddyb commented Jan 16, 2020

no longer promote non-pattern const functions #67531

no longer promote non-pattern const functions #67531

Conversation

RalfJung commented Dec 22, 2019

RalfJung commented Dec 22, 2019

bors commented Dec 22, 2019

bors commented Dec 22, 2019

RalfJung commented Dec 22, 2019

Centril commented Dec 22, 2019

craterbot commented Dec 22, 2019

craterbot commented Dec 26, 2019

craterbot commented Dec 28, 2019

oli-obk commented Dec 28, 2019

Centril commented Dec 28, 2019

nikomatsakis commented Jan 2, 2020

bors commented Jan 2, 2020

RalfJung commented Jan 2, 2020

bors commented Jan 2, 2020

bors commented Jan 4, 2020

Centril commented Jan 4, 2020

rust-highfive commented Jan 4, 2020

eddyb commented Jan 16, 2020