Deserialize Swift compatibility version in CompilerInvocation::loadFromSerializedAST() #19024
Conversation
…omSerializedAST() LLDB needs the -swift-version because the -D__swift__ macro affects how Clang modules are built. This currently has the really odd effect that when debugging a Swift program that is not using the very latest Swift version, the first "po" takes several seconds, because the module cache needs to be rebuilt. rdar://problem/40241256
|
@benlangmuir: Would this negatively affect SourceKit? I could imagine that SourceKit has a similar performance problem. If this is a problem we could hide this behavior behind a flag. |
|
@swift-ci test |
|
I guess this is the right default behavior, and then the expression context will override this with "newest version"? AFAIK SourceKit doesn't use |
|
It's exposed in swift-ide-test, but that may have been us (the LLDB folks). |
|
Yeah: LLDB could pick something like max(all compatibility versions from all dylibs) for the expression context and the exact match for the per-module context. |
|
Build failed |
|
@swift-ci test |
|
Build failed |
|
I have no concerns about this (as Jordan said, we don't use this API in sourcekitd), but I don't fully understand its consequences in lldb, so removing myself as reviewer. |
|
@swift-ci smoke test and merge |
1 similar comment
|
@swift-ci smoke test and merge |
LLDB needs the -swift-version because the -D__swift__ macro affects
how Clang modules are built. This currently has the really odd effect
that when debugging a Swift program that is not using the very latest
Swift version, the first "po" takes several seconds, because the
module cache needs to be rebuilt.
rdar://problem/40241256
Replace this paragraph with a description of your changes and rationale. Provide links to external references/discussions if appropriate.
Resolves SR-NNNN.