[ClangImporter] Preserve macros from all implicit submodules. #3983
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
...instead of picking one definition arbitrarily. This comes from the new "lookup table" design in Swift 3---we no longer just look for any "visible" (imported) macro definition, but instead need to know them up front. This works fine when there's only one definition per module, but for modules like 'OpenGL' on macOS, with mutually-exclusive submodules 'GL' and 'GL3', the compiler was arbitrarily deciding that all of the macros the submodules had in common belonged to 'GL'. The new model tries to decide if it's possible for two modules to be imported separately, and keeps both macro entries if possible, only deduplicating equivalent definitions at the last minute (when importing into Swift). This /still/ doesn't perfectly match the behavior you'd get in C, where a submodule and its parent module could theoretically have conflicting definitions and you'd be fine as long as you only imported one of them, but hopefully (a) it's close enough, and (b) nobody is doing that. (The Swift compiler will prefer the definition in the parent module even if the submodule is the only one imported.) rdar://problem/26731529
|
@DougGregor, mind reviewing this? @swift-ci Please test |
|
@swift-ci Please test |
|
This looks like the best solution to this problem we're likely to get, thank you! |
jrose-apple
added a commit
to jrose-apple/swift
that referenced
this pull request
Aug 4, 2016
…ang#3983) ...instead of picking one definition arbitrarily. This comes from the new "lookup table" design in Swift 3---we no longer just look for any "visible" (imported) macro definition, but instead need to know them up front. This works fine when there's only one definition per module, but for modules like 'OpenGL' on macOS, with mutually-exclusive submodules 'GL' and 'GL3', the compiler was arbitrarily deciding that all of the macros the submodules had in common belonged to 'GL'. The new model tries to decide if it's possible for two modules to be imported separately, and keeps both macro entries if possible, only deduplicating equivalent definitions at the last minute (when importing into Swift). This /still/ doesn't perfectly match the behavior you'd get in C, where a submodule and its parent module could theoretically have conflicting definitions and you'd be fine as long as you only imported one of them, but hopefully (a) it's close enough, and (b) nobody is doing that. (The Swift compiler will prefer the definition in the parent module even if the submodule is the only one imported.) rdar://problem/26731529 (cherry picked from commit 490aefa)
|
Oops, this was originally a JIRA bug, SR-1718. |
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.
...instead of picking one definition arbitrarily. This comes from the new "lookup table" design in Swift 3---we no longer just look for any "visible" (imported) macro definition, but instead need to know them up front. This works fine when there's only one definition per module, but for modules like 'OpenGL' on macOS, with mutually-exclusive submodules 'GL' and 'GL3', the compiler was arbitrarily deciding that all of the macros the submodules had in common belonged to 'GL'.
The new model tries to decide if it's possible for two modules to be imported separately, and keeps both macro entries if possible, only deduplicating equivalent definitions at the last minute (when importing into Swift). This still doesn't perfectly match the behavior you'd get in C, where a submodule and its parent module could theoretically have conflicting definitions and you'd be fine as long as you only imported one of them, but hopefully (a) it's close enough, and (b) nobody is doing that. (The Swift compiler will prefer the definition in the parent module even if the submodule is the only one imported.)
rdar://problem/26731529
Before merging this pull request to apple/swift repository:
Triggering Swift CI
The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:
Smoke Testing
A smoke test on macOS does the following:
device standard libraries are not built.
version of these tests are not run.
A smoke test on Linux does the following:
tests are not run.
Validation Testing
Lint Testing
Note: Only members of the Apple organization can trigger swift-ci.