Serialization: Ignore lookup shadowing when resolving cross-references #80009
+194
−3
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 |
|
@swift-ci please test source compatibility |
When a Swift function shadows a clang function of the same name, the assumption was that Swift code would refer only to the Swift one. However, if the Swift function is `@usableFromInline internal` it can be called only from the local module and inlined automatically in other clients. Outside of that module, sources see only the clang function, so their inlinable code calls only the clang function and ignores the Swift one. This configuration passed type checking but it could crash the compiler at inlining the call as the compiler couldn't see the clang function. Let's update the deserialization logic to support inlined calls to the shadowed or the shadower. Typical shadowing is already handled by the custom deserialization cross-reference filtering logic which looks for the defining module, scope and whether it's a Swift or clang decl. We can disable the lookup shadowing logic and rely only on the deserialization filtering. rdar://146320871 swiftlang#79801
xymus
force-pushed
the
deser-internal-shadow
branch
from
38f3f34 to
bf224e2
Compare
|
Adding a test covering more shadowing scenarios. @swift-ci Please smoke test |
tshortli
approved these changes
Mar 18, 2025
artemcm
approved these changes
Mar 18, 2025
xedin
added a commit
to xedin/swift-source-compat-suite
that referenced
this pull request
Mar 22, 2025
It was fixed by swiftlang/swift#80009
justice-adams-apple
pushed a commit
to swiftlang/swift-source-compat-suite
that referenced
this pull request
Mar 24, 2025
xymus
added a commit
to xymus/swift
that referenced
this pull request
Apr 4, 2025
Followup fix to swiftlang#80009. We can still get ambiguities from colliding decls across modules with the deserialization filtering. Bring back calling the general lookup shadowing after the filtering. This way it won't use filtered out decls to hide potential candidates. rdar://148286345
xymus
added a commit
to xymus/swift
that referenced
this pull request
Apr 8, 2025
Followup fix to swiftlang#80009. We can still get ambiguities from colliding decls across modules with the deserialization filtering. Bring back calling the general lookup shadowing after the filtering. This way it won't use filtered out decls to hide potential candidates. rdar://148286345
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
When a Swift function shadows a clang function of the same name, the assumption was that Swift code would refer only to the Swift one. However, if the Swift function is
@usableFromInline internalit can be called only from the local module and inlined automatically in other clients. Outside of that module, sources see only the clang function, so their inlinable code calls only the clang function and ignores the Swift one. This configuration passed type checking but it could crash the compiler at inlining the call as the compiler couldn't see the clang function.Let's update the deserialization logic to support inlined calls to the shadowed or the shadower. Typical shadowing is already handled by the custom deserialization cross-reference filtering logic which looks for the defining module, scope and whether it's a Swift or clang decl. We can disable the lookup shadowing logic and rely only on the deserialization filtering.
rdar://146320871
#79801