[SourceKit] Pass the main swift executable path when constructing a compiler invocation #58852
Conversation
|
@swift-ci Please smoke test |
There was a problem hiding this comment.
Couple questions:
- Why is this only a problem on Ubuntu 22.04 AArch64?
- This seems to imply that for testing both the regular compilation and SourceKit requests fail to find Clang, which seems... not ideal. The directory is optionally passed in
swift-ide-test, but since this ends up affecting arguments I'm not sure that's really enough. @egorzhdan probably more of a question for you.
…ompiler invocation swiftlang#58786 (rdar://93030932) was failing because the `swift-frontend` invocations passed a `swiftExecutablePath` to `Invocation.parseArgs`. This caused the `ClangImporter` instance to point to a `clang` binary next to the `swift-frontend` executable while SourceKit used PATH to find `clang`. The clang executable next to `swift-frontend` doesn’t actually exist because `clang` lives in `llvm-linux-aarch64/bin` and `swift-frontend` lives in `swift-linux-aarch64/bin`. So some checks for a minimum clang verison failed for the normal build (because the executable doesn’t actually exists) while they pass during the SourceKit build (which used `clang` from `PATH`). This in turn caused the `outline-atomics` to be enabled to the SourceKit clang compiler arguments but not the clang compiler arguments for a normal build and thus resulted in two separate module cache directories (which includes the enabled features in the module directory hash). To fix this issue, also set the swift executable path for compiler invocations created from SourceKit. Fixes swiftlang#58786 (rdar://93030932)
ahoppen
force-pushed
the
pr/ubuntu-22-failure
branch
from
89383c8 to
1525f6b
Compare
It’s only an issue on AArch64 because I haven’t checked why it’s not an issue on Ubuntu 20.04 but I assume it’s because because the
My intention with this patch was to make SourceKit match the normal compilation behavior. I filed #58885 to point |
|
@swift-ci Please smoke test |
Yep, to be clear, I wasn't suggesting you fix that in this PR - just wanted to know what's going on there. |
#58786 (rdar://93030932) was failing because the
swift-frontendinvocations passed aswiftExecutablePathtoInvocation.parseArgs. This caused theClangImporterinstance to point to aclangbinary next to theswift-frontendexecutable while SourceKit used PATH to findclang. The clang executable next toswift-frontenddoesn’t actually exist becauseclanglives inllvm-linux-aarch64/binandswift-frontendlives inswift-linux-aarch64/bin.So some checks for a minimum clang verison failed for the normal build (because the executable doesn’t actually exists) while they pass during the SourceKit build (which used
clangfromPATH). This in turn caused theoutline-atomicsto be enabled to the SourceKit clang compiler arguments but not the clang compiler arguments for a normal build and thus resulted in two separate module cache directories (which includes the enabled features in the module directory hash).To fix this issue, also set the swift executable path for compiler invocations created from SourceKit.
Fixes rdar://93030932 #58786