-
-
Notifications
You must be signed in to change notification settings - Fork 14.2k
mir_build: Rename TestCase to TestableCase
#150051
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
Some changes occurred in match lowering cc @Nadrieril |
This comment has been minimized.
This comment has been minimized.
| enum TestCase<'tcx> { | ||
| enum TestableCase<'tcx> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For me TestableCase is more confusing than TestCase. I would prefer TestOutcome for example
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, my main motivation is to get rid of the Test prefix, because that's the part that keeps confusing me.
I think I would find TestOutcome even more confusing, because of TestBranch.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh, fair point x)
|
r? me |
|
I would like to give this thing a better name, but I think it's only worth changing if we can agree on a new name that's clearly better. So I would be fine with closing this for now, since it would conflict with some other simplifications/improvements that I'm investigating. |
|
I can live with @bors r+ rollup |
In the spirit of #149946, this is another renaming of something I've always found confusing.
When lowering match conditions, there is a subtle distinction between the kind of test being performed (on a scrutinee place), the possible outcomes of that test, and the different “cases” (corresponding to pattern nodes) that the test is distinguishing. Cases imply a particular preferred test, but once a test is chosen it can also interact with other cases as well.
I have often mixed up
TestKindandTestCase, since the names are so similar, and they share several variant names. Therefore, this PR renamesTestCasetoTestableCase, to emphasise that these are the things selected by whatever test is being performed.There should be no change to compiler behaviour.