Diagnose modules with circular dependencies #16075
Conversation
|
@swift-ci Please test |
|
@swift-ci Please test source compatibility |
|
Build failed |
|
Build failed |
jrose-apple
force-pushed
the
to-the-tune-of-virtual-insanity
branch
from
c94076f to
79d8ae9
Compare
|
Source compat job continuing to run here @akyrtzi Are you okay with deleting this old SourceKit test? A user-visible diagnostic seems sufficient to not worry about this case. @swift-ci Please test |
|
Build failed |
|
Build failed |
|
Whoops, deleted more than I should have. I'll pick this up in a week. |
jrose-apple
force-pushed
the
to-the-tune-of-virtual-insanity
branch
from
79d8ae9 to
313d833
Compare
|
@swift-ci Please test |
|
Build failed |
|
Build failed |
|
What happens in that index test that you deleted? Does it get your new error and produce no indexing info? |
|
Yep, that's correct. And then I tried to tweak the other test to get the same result but apparently I did it incorrectly (I didn't test it locally first). |
This can't arise from a clean build, but it can happen if you have products lingering in a search path and then either rebuild one of the modules in the cycle, or change the search paths. The way this is implemented is for each module to track whether its imports have all been resolved. If, when loading a module, one of its dependencies hasn't resolved all of its imports yet, then we know there's a cycle. This doesn't produce the best diagnostics, but it's hard to get into this state in the first place, so that's probably okay. https://bugs.swift.org/browse/SR-7483
jrose-apple
force-pushed
the
to-the-tune-of-virtual-insanity
branch
from
313d833 to
0cc297b
Compare
|
@swift-ci Please test |
|
Build failed |
|
Build failed |
This can't arise from a clean build, but it can happen if you have products lingering in a search path and then either rebuild one of the modules in the cycle, or change the search paths. The way this is implemented is for each module to track whether its imports have all been resolved. If, when loading a module, one of its dependencies hasn't resolved all of its imports yet, then we know there's a cycle. This doesn't produce the best diagnostics, but it's hard to get into this state in the first place, so that's probably okay. https://bugs.swift.org/browse/SR-7483 (cherry picked from commit df2e63d)
This can't arise from a clean build, but it can happen if you have products lingering in a search path and then either rebuild one of the modules in the cycle, or change the search paths. The way this is implemented is for each module to track whether its imports have all been resolved. If, when loading a module, one of its dependencies hasn't resolved all of its imports yet, then we know there's a cycle. This doesn't produce the best diagnostics, but it's hard to get into this state in the first place, so that's probably okay. https://bugs.swift.org/browse/SR-7483 (cherry picked from commit df2e63d)
This can't arise from a clean build, but it can happen if you have products lingering in a search path and then either rebuild one of the modules in the cycle, or change the search paths.
The way this is implemented is for each module to track whether its imports have all been resolved. If, when loading a module, one of its dependencies hasn't resolved all of its imports yet, then we know there's a cycle.
This doesn't produce the best diagnostics, but it's hard to get into this state in the first place, so that's probably okay.
SR-7483 / rdar://problem/39598696