Fix sourcekitd interface generation crashing for modules that only have a .swiftinterface file #22514
Conversation
|
@swift-ci please smoke test |
|
Hrm. This seems like a bad idea for pure compile times—now we're going to compile Clang modules twice. |
|
Maybe forwarding on DetailedPreprocessingRecord is closer to the original intent anyway? |
|
@adrian-prantl could you verify that it is actually useful for the swift compiler to build clang modules with 'object' format ? |
|
Yes, LLDB is using the DWARF debug info for the Clang types in the pcms to display Swift variables with Clang-backed types as Clang types when a .swiftmodule containing the Swift renditions of those types couldn't be found or loaded (e.g., because Swift and LLDB are out of sync or there is an irreconsilable option conflict). |
…langImporter option on the sub invocation if it's set on the parent In addition to capturing more detailed preprocessor info, the DetailedPreprocessorRecord option sets the clang module format to 'raw' rather than the default 'object'. Sourcekitd doesn't link the code generation libs, which it looks like the default 'object' format requires, so it sets this option to true. The subinvocation generated when loading a module from a .swiftinterface file still used the default prior to this change though, so it would end up crashing sourcekitd. This change sets the DetailedProccessorRecord option if the DetailedRecord option is set on the preprocessor options of parent context's clang module loader. This fixes interface generation crashing for modules that only have a .swiftinterface file. rdar://problem/43906499
nathawes
force-pushed
the
sourcekit-support-for-parseable-interfaces-pt-2
branch
from
7f1d63c to
d164c61
Compare
|
@jrose-apple I updated the patch to not split the options and set the flag on the sub-invocation's clang importer options if it looks like it was set for the parent context. Does this seem ok? |
|
@swift-ci please test |
|
Build failed |
|
Build failed |
[ParseableInterface][sourcekitd] Set the DetailPreprocessor ClangImporter option on the sub invocation if it's set on the parent
In addition to capturing more detailed preprocessor info, the DetailedPreprocessorRecord option sets the clang module format to 'raw' rather than the default 'object'. Sourcekitd doesn't link the code generation libs, which it looks like the default 'object' format requires, so it sets this option to true. The subinvocation generated when loading a module from a .swiftinterface file still used the default prior to this change though, so it would end up crashing sourcekitd.
This change sets the DetailedProccessorRecord option if the DetailedRecord option is set on the preprocessor options of parent context's clang module loader. This fixes interface generation crashing for modules that only have a .swiftinterface file.