[5.10 🍒][Dependency Scanning] Only optionally try to resolve imports of 'Foo.Private' submodules to Foo_Private
top-level modules.
#68842
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.
Cherry-pick of #68841
• Release: Swift 5.10
• Explanation: #66151 implemented support in dependency scanning for a special case of re-mapping imports of
Foo.Private
to clang modules of formFoo_Private
. Such a module may not actually exist and the user did in fact mean a submodule ofFoo
calledPrivate
instead, in which case we do not want to error out during the scan on not being able to find it.• Scope of Issue: Some projects which rely on importing a clang submodule called
Private
using the.Private
syntax may fail to resolve the dependency.• Risk: Minimal, this change only affects the code-path which currently leads to a hard scanning failure, making it not error on failure to resolve the potentially-optional
_Private
module.• Origination: Explicit Module Build feature development.
Resolves rdar://109426243