Fix ICE on recursively defined enum variant discriminant. #26515
Conversation
|
r? @huonw (rust_highfive has picked a reviewer for you, use r? to override) |
|
Two more things:
|
|
I... don't really know much about this. r? @nrc (random selection from the compiler subteam) |
| // option. This file may not be copied, modified, or distributed | ||
| // except according to those terms. | ||
|
|
||
| enum X { |
There was a problem hiding this comment.
Please add a comment explaining what is being tested
|
r=me with a couple of comments added |
|
@nrc Is this better? (I commented the first |
|
@bors: r+ |
|
📌 Commit b952c0e has been approved by |
|
yes, thanks! |
Fixes #23302. Note that there's an odd situation regarding the following, most likely due to some inadequacy in `const_eval`: ```rust enum Y { A = 1usize, B, } ``` In this case, `Y::B as usize` might be considered a constant expression in some cases, but not others. (See #23513, for a related problem where there is only one variant, with no discriminant, and it doesn't behave nicely as a constant expression either.) Most of the complexity in this PR is basically future-proofing, to ensure that when `Y::B as usize` is fully made to be a constant expression, it can't be used to set `Y::A`, and thus indirectly itself.
Fixes #23302.
Note that there's an odd situation regarding the following, most likely due to some inadequacy in
const_eval:In this case,
Y::B as usizemight be considered a constant expression in some cases, but not others. (See #23513, for a related problem where there is only one variant, with no discriminant, and it doesn't behave nicely as a constant expression either.)Most of the complexity in this PR is basically future-proofing, to ensure that when
Y::B as usizeis fully made to be a constant expression, it can't be used to setY::A, and thus indirectly itself.