Implement preliminary support for deserializing cc1 flags in Swift mo… #9088
Conversation
adrian-prantl
assigned
kastiglione and
cachemeifyoucan and unassigned
kastiglione and
cachemeifyoucan
adrian-prantl
requested review from
kastiglione,
fredriss,
cachemeifyoucan and
JDevlieghere
|
@swift-ci test |
…dules. There is no functional change on all other code paths. Support for cc1 flags isn't complete. Since cc1 flags are not stable it's not feasible to keep a list of all multi-arg flags, for example. It also makes it difficult to correctly identify where working directories and path remappings should applied. For all these reasons, using cc1 flags for anything but a local build with explicit modules and precise compiler invocations isn't supported yet. rdar://133249595
adrian-prantl
force-pushed
the
133249595
branch
from
2b878fa to
7c0ac3b
Compare
|
@swift-ci test |
| std::vector<std::string> &dest) { | ||
| std::vector<std::string> &dest, | ||
| bool cc1) { | ||
| // FIXME: Support for cc1 flags isn't complete. The uniquing |
There was a problem hiding this comment.
The flags from a normal build (that is planned by swift dependency scanner), this cc1 list is absolutely deterministic and have a stable ordering already but probably lldb should not rely on this fact.
What really should happen is for lldb to create a clang::CompilerInvocation and parse the args then it can be systematically collect/modify the flag values. I am ok to leave that for future improvement
There was a problem hiding this comment.
What really should happen is for lldb to create a clang::CompilerInvocation and parse the args then it can be systematically collect/modify the flag values. I am ok to leave that for future improvement
That might work, and if it does that would be a better implementation. It's possible that some modifications have to happen before parsing though, because the unmodified arguments wouldn't pass validation.
There was a problem hiding this comment.
Oh, you mean some old cc1 args that are no longer valid for current clang version? That would be tricky (even though we expect a version matching lldb for debugging swift).
There was a problem hiding this comment.
That case is hopeless for explicit modules anyway (the pcms would be incompatible), and I wouldn't expect this mode to be used for anything but explicit modules.
There was a problem hiding this comment.
That might work, and if it does that would be a better implementation. It's possible that some modifications have to happen before parsing though, because the unmodified arguments wouldn't pass validation.
I was thinking about a hypothetical scenario of the driver complaining if a path doesn't exist (which it probably doesn't do)
| // be merged with driver options. | ||
| bool fresh_invocation = importer_options.ExtraArgs.empty(); | ||
| if (fresh_invocation && !ExtraArgs.empty() && ExtraArgs.front() == "-cc1") | ||
| importer_options.DirectClangCC1ModuleBuild = true; |
There was a problem hiding this comment.
should DirectClangCC1ModuleBuild always be set to try when ExtraArgs.front() == "-cc1"?
in other words, should the mixed mode treat extra args as frontend flags when -cc1 is first?
There was a problem hiding this comment.
I think such a case is hopeless anyway. I'm planning to clean this up on the rebranch branch, where I'm going to rip out support for non-precise compiler invocations, which should allow us to simplify all this code quite a bit.
Followup to swiftlang#9088, handle the cc1 flag deserialization when swift caching is enabled. LLDB should ignore all the CAS related options from embedded flags since LLDB doesn't receive the correct CAS configuration and should just load the modules from disk directly. rdar://134090397
Followup to swiftlang#9088, handle the cc1 flag deserialization when swift caching is enabled. LLDB should ignore all the CAS related options from embedded flags since LLDB doesn't receive the correct CAS configuration and should just load the modules from disk directly. rdar://134090397 (cherry picked from commit 1162e50)
Followup to swiftlang#9088, handle the cc1 flag deserialization when swift caching is enabled. LLDB should ignore all the CAS related options from embedded flags since LLDB doesn't receive the correct CAS configuration and should just load the modules from disk directly. rdar://134090397 (cherry picked from commit 1162e50)
Followup to #9088, handle the cc1 flag deserialization when swift caching is enabled. LLDB should ignore all the CAS related options from embedded flags since LLDB doesn't receive the correct CAS configuration and should just load the modules from disk directly. rdar://134090397 (cherry picked from commit 1162e50)
Followup to #9088, handle the cc1 flag deserialization when swift caching is enabled. LLDB should ignore all the CAS related options from embedded flags since LLDB doesn't receive the correct CAS configuration and should just load the modules from disk directly. rdar://134090397 (cherry picked from commit 1162e50)
…dules.
There is no functional change on all other code paths. Support for cc1 flags isn't complete. Since cc1 flags are not stable it's not feasible to keep a list of all multi-arg flags, for example. It also makes it difficult to correctly identify where working directories and path remappings should applied. For all these reasons, using cc1 flags for anything but a local build with explicit modules and precise compiler invocations isn't supported yet.
rdar://133249595