always lookup pure enum symbols if expected type is enum #23976
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
fixes #23689
Normally pure enum symbols only "exist" in lookup if nothing else with the same name is in scope. But if an expression is expected to be an enum type, we know that ambiguity can be resolved between different symbols based on their type, so we can include the normally inaccessible pure enum fields in the ambiguity resolution in the case that the expected enum type is actually a pure enum. This handles the use case in the issue of the type inference for enums reverted in #23588.
I know pure enums are supposed to be on their way out so this might seem excessive, but the
pure
pragma can't be removed in the code in the issue due to a redefinition error, they have to be separated into different modules. Normal enums can still resolve the ambiguity here though. I always think about making a list of all the remaining use cases for pure enums and I always forget.Will close #23694 if CI passes