Limit the promotion of const fns to the libstd and the rustc_promotable attribute#53851
Limit the promotion of const fns to the libstd and the rustc_promotable attribute#53851bors merged 5 commits intorust-lang:masterfrom
rustc_promotable attribute#53851Conversation
|
@bors try |
|
⌛ Trying commit dc280eb2bc82f51f865c5bc3dc9cd8997cc3d69c with merge 952c7dbfa2628309f557b367929ffc17af20b332... |
|
☀️ Test successful - status-travis |
|
@craterbot run start=master#1114ab684fbad001c4e580326d8eb4d8c4e917d3 end=try#952c7dbfa2628309f557b367929ffc17af20b332 mode=check-only |
|
👌 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
|
|
One spurious regression, and one true regression: |
|
... and that could be fixed by using |
|
@eddyb said on IRC that we should instead add a whitelist of promotable const fns, and add the currently stable ones to it in order to not have any possibility of breakage even outside crates.io |
|
Anything, as long as we do it before |
dc280eb to
5f4c14d
Compare
src/librustc/ty/constness.rs
Outdated
There was a problem hiding this comment.
I collected all the logic in this one file in order to make our lives easier and have less code duplication which might cause odd inconsistencies
src/librustc_mir/const_eval.rs
Outdated
There was a problem hiding this comment.
I had to remove this because the is_const_fn above is now overly restrictive (it will forbid calling str::len with the const_str_len feature gate but without the const_slice_len feature gate because that calls [u8]::len internally). We already check all the guarantees in the const_qualif pass, there's no need to check them again at evaluation time.
There was a problem hiding this comment.
This is now just a single call to is_promotable_const_fn which seems a major improvement over the code duplication we were doing here before.
src/test/run-pass/issue-49955-2.rs
Outdated
There was a problem hiding this comment.
calls to Cell::new are not promotable anymore, thus this breaks. The crater run didn't show any cases of people actually writing this kind of code (also needs MIR borrowck)
There was a problem hiding this comment.
Diagnostics improvement or regression. Depending on your view. We used to stop at the first non-const fn, now we just stop if/when we fail to actually evaluate. An error is reported above about non const fn calls and other non-const things happening here.
There was a problem hiding this comment.
Although I like the specificity, this is not actually actionable, is it? I would not block on improving this message though.
There was a problem hiding this comment.
We could probably make it a delay_span_bug, but i fear that we'll overlook some case and then run into that hypothetical ICE at some point.
These kind of errors only happen for repeat/array lengths and enum variant discriminant initializers (or constants used in such). Everything else reports only the other errors above.
Alternatively we can try to figure out a scheme that prevents const eval of constants with const qualification errors.
|
r? @eddyb |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
6939244 to
c793391
Compare
|
@bors r=eddyb |
|
📌 Commit c793391 has been approved by |
Limit the promotion of const fns to the libstd and the `rustc_promotable` attribute There are so many questions around promoting const fn calls... it seems saner to try to limit automatic promotion to const fns which were explicitly opted in for promotion. I added the attribute to all public stable const fns that were already promotable (e.g. not Cell::new) in order to not cause any breakage r? @eddyb cc @nikomatsakis
|
☀️ Test successful - status-appveyor, status-travis |
|
Broader discussion continues in rust-lang/const-eval#19 |
There are so many questions around promoting const fn calls... it seems saner to try to limit automatic promotion to const fns which were explicitly opted in for promotion.
I added the attribute to all public stable const fns that were already promotable (e.g. not Cell::new) in order to not cause any breakage
r? @eddyb
cc @nikomatsakis