-
-
Notifications
You must be signed in to change notification settings - Fork 14.4k
Open
Labels
A-closuresArea: Closures (`|…| { … }`)Area: Closures (`|…| { … }`)A-patternsRelating to patterns and pattern matchingRelating to patterns and pattern matchingC-bugCategory: This is a bug.Category: This is a bug.I-lang-radarItems that are on lang's radar and will need eventual work or consideration.Items that are on lang's radar and will need eventual work or consideration.T-langRelevant to the language teamRelevant to the language teamT-opsemRelevant to the opsem teamRelevant to the opsem team
Description
The way we generate MIR currently means that enum opsem distinguished two classes of enums
- Those with more than 1 variant or a
#[non_exhaustive]attribute - Those with 1 or 0 variants and no
#[non_exhaustive]
For the latter, we sometimes omit reading the discriminant since we "already know the result". Also see #150681 where this is point 1.
I think we should treat all enums consistently. This example should be considered UB. In particular, I think #[non_exhaustive] should not affect the opsem.
This change was separated out of #150681 at the request of @traviscross, so that it can be discussed separately. So, let's discuss. :) @scottmcm and @nikomatsakis already expressed agreement with this next step in that PR.
Cc @meithecatte -- IIRC this had a non-zero crater fallout; where are the results of that again?
Nadrieril
Metadata
Metadata
Assignees
Labels
A-closuresArea: Closures (`|…| { … }`)Area: Closures (`|…| { … }`)A-patternsRelating to patterns and pattern matchingRelating to patterns and pattern matchingC-bugCategory: This is a bug.Category: This is a bug.I-lang-radarItems that are on lang's radar and will need eventual work or consideration.Items that are on lang's radar and will need eventual work or consideration.T-langRelevant to the language teamRelevant to the language teamT-opsemRelevant to the opsem teamRelevant to the opsem team