-
Notifications
You must be signed in to change notification settings - Fork 10.5k
Ensure #if $MoveOnly
feature guard evaluates to true.
#64560
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
Conversation
@swift-ci please smoke test |
d6ac073
to
7f641f3
Compare
@swift-ci please smoke test |
7f641f3
to
536ce51
Compare
#if $MoveOnly
feature guard evaluates to true.
@swift-ci please test |
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.
LGTM, man that was a silly issue :O
Thank you for investigating @kavon! I'll also run locally, I seemed to have a good chance to reproduce the issue before.
I enabled move-only types by default, but I didn't realize that the `Feature::MoveOnly` needs to graduate into a `LANGUAGE_FEATURE` so that `EvaluateIfConfigCondition` will recognize `$MoveOnly` as being true. fixes rdar://107050387
0f37c53
to
86f6941
Compare
This reverts commit abe377c. Co-authored-by: Konrad `ktoso` Malawski <konrad_malawski@apple.com>
86f6941
to
363448a
Compare
@swift-ci please smoke test and merge |
This was missing a 5.9 cherry pick; #64666 |
There was a subtle issue with feature flags after I enabled move-only types by default. Turns out that the
$MoveOnly
feature guard wasn't always evaluating to true when the-enable-experimental-move-only
isn't provided. This change now ensures that's the case so that public noncopyable types compiled in different modules are picked up correctly.There's a separate sort of oddity where
hasFeature(Feature::Something)
still evaluates to false, whereSomething
is an always-on feature. That will be addressed in a separate PR here: #64602resolves rdar://107050387