Sema: In embedded, consider functions as fragile unless @_neverEmitIntoClient
#84630
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@swift-ci Please smoke test |
xymus
changed the title
@_neverEmitIntoClient@_neverEmitIntoClient
|
@swift-ci Please smoke test |
xymus
force-pushed
the
non-neic-funcs-are-fragile
branch
from
660baaa to
00d64e1
Compare
|
@swift-ci Please smoke test |
1 similar comment
|
@swift-ci Please smoke test |
|
@swift-ci please test |
|
@swift-ci Please smoke test |
|
@swift-ci Please smoke test Linux |
|
@swift-ci Please smoke test Windows |
Consider functions in embedded mode to be fragile unless marked with `@_neverEmitIntoClient`. Basically treating them as if they were `@_alwaysEmitIntoClient` by default. A fragile function cannot reference restricted imports such as `@_implementationOnly`, `internal import`, etc. We consider them as fragile only for type-checking, at the SIL level they remain treated as normal functions like before. This allows the later optimization to work as expected. We may want to likely align both ends of the compiler once this is properly supported in sema. This is enabled only in embedded. Fragile functions in library-evolution are marked with attributes and are already checked. We do not need this is non-embedded non-library-evolution as CMO handles inlining and already takes into consideration `@_implementationOnly` imports. Note: We'll need a similar check for memory layouts exposed to clients. We can still see compiler crashes and miscompiles in this scenario. This will apply to both embedded and non-library-evolution modes. That will likely need to extend the `@_neverEmitIntoClient` attribute and may require a staged deployment. rdar://161365361
Availability macros are rejected from library-evolution inlinable code as the compiler didn't know how to print them in the swiftinterface. This isn't a concern with the embedded style of fragile functions, we can allow availability macros there.
xymus
force-pushed
the
non-neic-funcs-are-fragile
branch
from
991c737 to
9380507
Compare
|
@swift-ci Please smoke test |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Consider functions in embedded mode to be fragile unless marked with
@_neverEmitIntoClient. Basically treating them as if they were@_alwaysEmitIntoClientby default. A fragile function cannot reference restricted imports such as@_implementationOnly,internal import, etc.We consider them as fragile only for type-checking, at the SIL level they remain treated as normal functions like before. This allows the later optimization to work as expected. We may want to likely align both ends of the compiler once this is properly supported in sema.
This is enabled only in embedded. Fragile functions in library-evolution are marked with attributes and are already checked. We do not need this is non-embedded non-library-evolution as CMO handles inlining and already takes into consideration
@_implementationOnlyimports.Note: We'll need a similar check for memory layouts exposed to clients. We can still see compiler crashes and miscompiles in this scenario. This will apply to both embedded and non-library-evolution modes. That will likely need to extend the
@_neverEmitIntoClientattribute and may require a staged deployment.rdar://161365361