-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Move .swiftmodule output directory #7103
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@swift-ci please test |
|
Hm, #7106 suggests that these tests work on |
Install needs to be adjusted to new paths. |
I'm unable to reproduce the Linux failures outside of CI :/ |
@swift-ci please test |
@swift-ci please test windows |
1 similar comment
@swift-ci please test windows |
@swift-ci please test |
Seems like the symbol graph command doesn't actually fail when it fails to do its job? For example, it'll say
but still exit successfully. These tests also don't log any output right now. |
Ah no, the command works fine, but our harness around it completely ignores the exit code. |
So I think I have to fix the harness first, then the testing code and after that I should be able to debug properly what is actually going wrong here. |
e439947
to
18d198a
Compare
Once #7141 has landed, we should be able to rebase this PR and hopefully get more information on how / why the dump symbol graph tests are failing on Linux CI. |
18d198a
to
fe77713
Compare
@swift-ci please test |
This confirms my initial suspicion, but I am not sure I understand why there's a difference specifically on Linux CI here. |
fe77713
to
d98c8c7
Compare
@swift-ci please test |
d98c8c7
to
207a053
Compare
@swift-ci please test |
Looks like sourcekit-lsp needs changes to deal with the new modules directory |
It doesn't seem as if the failures reproduce locally :/ |
While working on #7090, we noticed that any builds of Swift sources will currently find lots of unrelated module maps because of the structure of the build arena. We pass a `-I` to the top-level of the arena which leads to *everything* being recursively searched for modules, so the compiler will find module maps that aren't intended to be included at all. Changing this so that the search paths won't include random module maps should actually solve various issues around seeing incomplete module maps, such as ones referring to ObjC compatibility headers that haven't been written, yet. rdar://89082987
7582422
to
d263869
Compare
swiftlang/sourcekit-lsp#987 |
1 similar comment
swiftlang/sourcekit-lsp#987 |
Hm, looks as if this was somehow using the old sourcekit-lsp code? |
Yah, not sure what's going on, the log says it is using 8dc46c3, which is not a commit on my PR or on main ¯\_(ツ)_/¯ |
I guess I'll retry |
swiftlang/sourcekit-lsp#987 |
swiftlang/sourcekit-lsp#987 |
2 similar comments
swiftlang/sourcekit-lsp#987 |
swiftlang/sourcekit-lsp#987 |
swiftlang/sourcekit-lsp#987 |
1 similar comment
swiftlang/sourcekit-lsp#987 |
swiftlang/sourcekit-lsp#987 |
Seems like macOS CI is busted for now, so let's wait for that to get fixed. |
swiftlang/sourcekit-lsp#987 |
When we detect that we’re running using a 5.10 toolchain, adjust the compiler arguments that we received from SwiftPM to drop any `/Modules` suffixes in the build directory, to account for the fact that 5.10 stores the modules one directory higher up (swiftlang/swift-package-manager#7103).
While working on #7090, we noticed that any builds of Swift sources will currently find lots of unrelated module maps because of the structure of the build arena. We pass a
-I
to the top-level of the arena which leads to everything being recursively searched for modules, so the compiler will find module maps that aren't intended to be included at all.Changing this so that the search paths won't include random module maps should actually solve various issues around seeing incomplete module maps, such as ones referring to ObjC compatibility headers that haven't been written, yet.
rdar://89082987