-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[Sema] Fix availability checking in inlinable code #33855
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 |
@swift-ci Please test source compatibility |
1da45b8
to
f2f3d3e
Compare
@swift-ci Please smoke test |
f2f3d3e
to
aaba74d
Compare
@swift-ci Please smoke test |
1 similar comment
@swift-ci Please smoke test |
0286dab
to
64a48ec
Compare
@swift-ci Please smoke test |
64a48ec
to
315b01f
Compare
@swift-ci Please smoke test |
315b01f
to
692969a
Compare
@swift-ci Please smoke test |
@swift-ci Please test source compatibility |
@swift-ci Please test source compatibility |
692969a
to
c8c44d7
Compare
@swift-ci Please smoke test |
@swift-ci Please test source compatibility |
@swift-ci Please smoke test macOS platform |
1 similar comment
@swift-ci Please smoke test macOS platform |
@swift-ci Please test source compatibility |
c8c44d7
to
94608f9
Compare
@swift-ci Please smoke test |
@swift-ci Please test source compatibility |
@swift-ci Please smoke test macOS platform |
@swift-ci Please smoke test Linux platform |
@swift-ci Please test source compatibility |
@swift-ci Please smoke test |
@swift-ci Please test source compatibility |
Inlinable functions can be inlined in clients with a lower OS target version than the framework defining the function. For this reason, the availability in inlinable functions should always be checked using the explicit introduction OS version as lower bound and not the minimum deployment version. rdar://problem/67975153
This has the effect of rejecting unavailable overrides to available methods in a similar way as overrides that are less available than the introduction are rejected.
The errors on explicit unavailability are more precise than those on availablity version. Make sure we prioritize the unavailability ones first.
Don't raise the error availability_decl_more_than_enclosing in the context is unavailable and if read in a swiftinterface file. This error was present in the stdlib in 5.3 without side effects so we still want to accept it.
Preserve the old behavior of accepted unavailable override of constructors as this change would be source breaking.
…aces Preserve the previous behavior when parsing swiftinterfaces as the Swift stdlib for Swift 5.3 and a few other swiftinterfaces in Xcode 12.0 had issues that would now be reported as errors.
94608f9
to
fca7d36
Compare
@swift-ci Please smoke test |
Restarting doomed Linux tests. @swift-ci please smoke test Linux platform |
@swift-ci Please test source compatibility |
1 similar comment
@swift-ci Please test source compatibility |
Report unavailable overrides as a warning to avoid breaking sources.
@swift-ci Please smoke test |
@swift-ci Please test source compatibility |
Inlinable and
@_alwaysEmitIntoClient
functions can be inlined in clients with a lower OS target version than the framework defining the function. For this reason, the availability in inlinable functions should always be checked by using the introduction OS version specified by the explicit attributes as lower bound and not the minimum deployment version of the framework.A side-effect of this change is rejecting unavailable overrides to available methods, in a similar way as overrides that are less available than the introduction are rejected. I believe this is the intended behavior as it provided inconsistent diagnostics and surprising behaviors.
rdar://problem/67975153