[Dependency Scanning] Avoid querying Swift Overlay for underlying module #84443
Conversation
|
@swift-ci smoke test |
| return; | ||
| } | ||
|
|
||
| // Avoid overlay lookup for the underlying module of a known Swift module |
There was a problem hiding this comment.
I suggest reword this comment and commit message a bit. Overlay/underlying is a generic term but here we only skip the current module and its underlying (@_exported import) module. I didn't quite get what this does in the first place when I read the comment and message.
There was a problem hiding this comment.
Do we have a test case for the overlay/underlying module change?
It's very tricky to write one, as even when it was queried we already had logic in place to ensure we don't add the result to the graph. e.g. When scanning A, we would query Swift overlay for underlying Clang module A and find some other A.swiftmodule in the search paths, we would simply discard this result. Now we don't even query it but it's challenging to verify this behavior change.
artemcm
force-pushed
the
RestrictEmbeddedToBinarySwift
branch
from
221b96d to
34a314d
Compare
|
@swift-ci smoke test |
|
@swift-ci smoke test Linux platform |
|
@swift-ci smoke test macOS platform |
|
@swift-ci smoke test |
Avoid Swift Overlay lookup for the underlying clang module of a known Swift module. i.e. When computing set of Swift Overlay dependencies for module 'A', which depends on a Clang module 'A', ensure we don't lookup Swift module 'A' itself here - this can lead to bizarre interactions where the source module under scan is queried as a dependency of itself. Resolves rdar://159706486
artemcm
force-pushed
the
RestrictEmbeddedToBinarySwift
branch
from
34a314d to
e9a7519
Compare
|
@swift-ci smoke test |
This can lead to bizarre interactions where the source module under scan is queried as a dependency of itself.
On top of that, properly restrict embedded compilation mode to load serialized binary modules, only.
Resolves rdar://159706486