[2/n] Handle module names shadowed by nominal types #172
Conversation
This file contains 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
Custom build systems such as Buck or Bazel need a way to generate mocks
without an `.xcodeproj` file. This adds support for passing a JSON
project description containing all of the required module and dependency
graph information usually parsed from an Xcode project. The description
format is roughly compatible with the output from
`$ swift package describe --type JSON`, although adding the `dependency`
field needs to be upstreamed.
```json
{
"targets": [
{
"name": "MyLibrary",
"type": "library",
"path": "/path/to/my-library",
"dependencies": [],
"sources": [
"SourceFileA.swift",
"SourceFileB.swift"
]
},
{
"name": "MyOtherLibrary",
"type": "library",
"path": "/path/to/my-other-library",
"dependencies": [
"MyLibrary"
],
"sources": [
"SourceFileA.swift",
"SourceFileB.swift"
]
},
{
"name": "MyLibraryTests",
"type": "test",
"path": "/path/to/my-library-tests",
"dependencies": [
"MyLibrary"
],
"sources": [
"SourceFileA.swift",
"SourceFileB.swift"
]
}
]
}
```
The `--project` generator option now accepts arbitrary files. Iff a file
with an `xcodeproj` extension is provided then it is read as an Xcode
project. Cache metadata is stored in the same enclosing directory as the
project description file under the `.mockingbird` subdirectory.
Since builds are run outside of an Xcode testing context, it's necessary
to optionally provide a host test target with the `--testbundle` option
to enable thunk pruning support.
```bash
mockingbird generate \
--target MyLibrary \
--testbundle MyLibraryTests \
--project /path/to/project-desc.json
```
Types can shadow the module name they're declared in, which breaks the existing type qualification system. Until Swift gains a fully qualified module name syntax, there aren't many good options without splitting the output to directly mirror the source file structure (which would preserve file import namespacing and remove the need for qualification). https://forums.swift.org/t/pitch-fully-qualified-name-syntax/28482 This change strips module qualification from type references if a tracked type is found to shadow the module name. Note that untracked symbols like global functions, structs, and enums that shadow the module name aren't handled yet.
andrewchang-bird
changed the title
ryanmeisters
approved these changes
Sep 25, 2020
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.
Types can shadow the module name they're declared in, which breaks the existing type qualification system. Until Swift gains a fully qualified module name syntax, there aren't many good options without splitting the output to directly mirror the source file structure (which would preserve file import namespacing and remove the need for qualification).
https://forums.swift.org/t/pitch-fully-qualified-name-syntax/28482
This change strips module qualification from type references if a tracked type is found to shadow the module name. Note that untracked symbols like global functions, structs, and enums that shadow the module name aren't handled yet.