[Dependency Scanning] Remove hard failure mode (crash) during cross-import resolution #79702
Conversation
|
@swift-ci test |
artemcm
force-pushed
the
FixCrossImportFailureMode
branch
from
7ca7c4e to
c56ca92
Compare
|
@swift-ci test |
| @@ -1,6 +1,6 @@ | |||
| // RUN: %empty-directory(%t) | |||
| // RUN: %empty-directory(%t/module-cache) | |||
| // RUN: %target-swift-frontend -scan-dependencies -module-cache-path %t/module-cache %s -o %t/deps.json -I %S/Inputs/CHeaders -I %S/Inputs/Swift -target %target-cpu-apple-macosx10.14 | |||
| // RUN: %target-swift-frontend -scan-dependencies -module-cache-path %t/module-cache %s -o %t/deps.json -I %S/Inputs/CHeaders -I %S/Inputs/Swift -target %target-cpu-apple-macosx10.14 -disable-implicit-concurrency-module-import -disable-implicit-string-processing-module-import | |||
There was a problem hiding this comment.
Does this test mean it usually triggered from implicit imported modules? And implicit module cannot trigger cross import?
There was a problem hiding this comment.
No, these implicit imports do not actually result in any cross-import overlays. The way we noticed an issue here is that implicitly-imported Concurrency module was not able to be resolved for a given target platform. And that caused there to be a hanging unresolved import, which caused the code this PR is changing to crash.
So I wanted to both address this issue and also fix the test to not have a possibility of this missing module error which is fully unrelated to what it is meant to be testing.
There was a problem hiding this comment.
Is it possible to write a test for the failing case previously?
artemcm
force-pushed
the
FixCrossImportFailureMode
branch
from
c56ca92 to
6f0bc1e
Compare
|
@swift-ci test |
When failing to resolve an
importto a module ID, proceed ignoring thisimport, instead of crashing.Unresolved imports will be properly handled downstream in the scanner, with corresponding diagnostics.