Only run dataflow for const qualification if type-based check would fail#71330
Only run dataflow for const qualification if type-based check would fail#71330bors merged 4 commits intorust-lang:masterfrom
Conversation
|
r? @varkor (rust_highfive has picked a reviewer for you, use r? to override) |
|
r? @oli-obk |
|
The job 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 |
There was a problem hiding this comment.
we can lower Drop terminators for types that have a const Drop bound to a function call before doing this analysis.
|
So... hypothetically we could now have a situation where const checking does not cause a cycle error anymore, optimizations eliminate the cycle error and then const eval (which runs on optimized MIR) does not cause a cycle error? |
|
That's correct. I think the solution is to explicitly trigger |
|
Sidebar: what do you think about renaming a few modules/types in |
|
☔ The latest upstream changes (presumably #71044) made this pull request unmergeable. Please resolve the merge conflicts. |
I have a branch for that that I'm rebasing since yesterday |
|
So yea, I'm in favour of liberally renaming modules and types to match our terminology better or just be more consistent |
|
r=me on this PR after a rebase |
f32568c to
a6bb156
Compare
|
☔ The latest upstream changes (presumably #71467) made this pull request unmergeable. Please resolve the merge conflicts. |
This was needed by an early version of dataflow-based const qualification where `QualifCursor` needed to return a full `BitSet` with the current state.
a6bb156 to
15f95b1
Compare
|
@bors r=oli-obk |
|
📌 Commit 15f95b1 has been approved by |
…=oli-obk Only run dataflow for const qualification if type-based check would fail This is the optimization discussed in rust-lang#49146 (comment). We wait for `Qualif::in_any_value_of_ty` to return `true` before running dataflow. For bodies that deal mostly with primitive types, this will avoid running dataflow at all during const qualification. This also removes the `BitSet` used to cache `in_any_value_of_ty` for each local, which was only necessary for an old version of rust-lang#64470 that also handled promotability.
Rollup of 8 pull requests Successful merges: - rust-lang#69456 (fix misleading type annotation diagonstics) - rust-lang#71330 (Only run dataflow for const qualification if type-based check would fail) - rust-lang#71480 (Improve PanicInfo examples readability) - rust-lang#71485 (Add BinaryHeap::retain as suggested in rust-lang#42849) - rust-lang#71512 (Remove useless "" args) - rust-lang#71527 (Miscellaneous cleanup in `check_consts`) - rust-lang#71534 (Avoid unused Option::map results) - rust-lang#71535 (Fix typos in docs for keyword "in") Failed merges: r? @ghost
I'd be happy to see that happen. :D |
This is the optimization discussed in #49146 (comment). We wait for
Qualif::in_any_value_of_tyto returntruebefore running dataflow. For bodies that deal mostly with primitive types, this will avoid running dataflow at all during const qualification.This also removes the
BitSetused to cachein_any_value_of_tyfor each local, which was only necessary for an old version of #64470 that also handled promotability.