[SR-2660][Driver] Handle .swiftmodule inputs #12507
Conversation
modocache
force-pushed
the
sr-2660-driver-swiftmodule-linker-inputs
branch
from
6337088 to
1833159
Compare
|
@swift-ci please smoke test |
lib/Driver/Driver.cpp
Outdated
| } else { | ||
| // Otherwise, pass .swiftmodule files as inputs to the linker, | ||
| // so that their debug info is available. | ||
| AllLinkerInputs.push_back(Current); |
There was a problem hiding this comment.
This should probably check that we're planning to do a link action at all (OI.shouldLink()) and continue diagnosing otherwise.
lib/Driver/ToolChains.cpp
Outdated
| addInputsOfType(Arguments, context.InputActions, types::TY_SwiftModuleFile); | ||
|
|
||
| // For each .swiftmodule file added to the linker input arguments, prepend | ||
| // an -add_ast_path option. |
There was a problem hiding this comment.
This seems a bit too clever. What do you think about adding an extra const char * argument to addInputsOfType that is inserted before each input if present?
test/Driver/linker.swift
Outdated
| @@ -265,6 +268,11 @@ | |||
| // DEBUG: linker | |||
| // DEBUG: -o linker.dSYM | |||
|
|
|||
| // LINK-SWIFTMODULES: bin/swift | |||
| // LINK-SWIFTMODULES-NEXT: bin/ld{{"? }} | |||
| // LINK-SWIFTMODULES: -add_ast_path {{.*}}/a.swiftmodule | |||
There was a problem hiding this comment.
The rest of this test doesn't do this yet, but FileCheck now has a -SAME suffix that guarantees that the check lines are on the same line as the previous match. Please use that here!
modocache
force-pushed
the
sr-2660-driver-swiftmodule-linker-inputs
branch
2 times, most recently
from
0a6e6df to
ca6cfbd
Compare
|
Thanks for the review, @jrose-apple! I addressed your comments and (hopefully) fixed the issues that popped up on Linux CI. |
modocache
force-pushed
the
sr-2660-driver-swiftmodule-linker-inputs
branch
from
ca6cfbd to
6c6a0a0
Compare
|
@swift-ci please smoke test |
test/Driver/unknown-inputs.swift
Outdated
| // LINK-SWIFTMODULES-macho: 1: link, {0}, image | ||
|
|
||
| // LINK-SWIFTMODULES-elf: 0: input, "{{.*}}.swiftmodule", swiftmodule | ||
| // LINK-SWIFTMODULES-elf: 1: swift-autolink-extract, {0}, autolink |
There was a problem hiding this comment.
Ah, this is a great test because the behavior is wrong. :-) swift-autolink-extract should not be run on swiftmodules; the trouble is that I'm not sure whether it should only run on object files or also on, say, .a files. Let's say just object files for now.
Allow users to pass `.swiftmodule` files into the Swift driver when compiling without `-g`. The `.swiftmodule` files are then passed to the linker via `-add_ast_path` so that LLDB can access their AST information. This addresses one of two driver changes suggested in the comments of https://bugs.swift.org/browse/SR-2660.
modocache
force-pushed
the
sr-2660-driver-swiftmodule-linker-inputs
branch
from
6c6a0a0 to
b81ad22
Compare
|
OK, I think I took care of it, please have another look, @jrose-apple! @swift-ci please smoke test |
|
Hooray! I'll try to disentangle |
This fixes an intermittent failure introduced by swiftlang#12507.
Allow users to pass
.swiftmodulefiles into the Swift driver when compiling without-g. The.swiftmodulefiles are then passed to the linker via-add_ast_pathso that LLDB can access their AST information.This addresses one of two driver changes suggested in the comments of https://bugs.swift.org/browse/SR-2660. The second is to detangle the
-goption with the driver logic that determines whether to run a merge module job or not.In addition to the unit tests, to make sure the debug info was being read properly by lldb, I also ran
bash build-driver.shon an updated version of the sample project attached to the original bug report, which I've uploaded here: https://github.com/modocache/SR-2660. I tested that on macOS.