[ios,macos] Add Swift Sourcekit LSP support#189761
Conversation
cdce74c to
66d043c
Compare
There was a problem hiding this comment.
Code Review
This pull request adds support for native swiftc compilation commands in the compilation database by expanding GN swiftc.py wrapper invocations, and configures VS Code workspace settings to support Swift via SourceKit-LSP. Feedback on the changes includes removing accidentally pasted terminal progress output at the top of update_compdb.dart and appending .exe to the ninja executable path on Windows to prevent process execution failures.
I am having trouble creating individual review comments. Click here to see my feedback.
engine/src/flutter/tools/pkg/engine_build_configs/lib/src/update_compdb.dart (1-3)
It looks like a terminal command's progress output was accidentally pasted at the top of this file. This will cause compilation errors and should be removed.
engine/src/flutter/tools/pkg/engine_build_configs/lib/src/build_config_runner.dart (394-399)
On Windows, the ninja executable is named ninja.exe. We should append .exe when running on Windows to avoid process execution failures.
final String ninjaPath = p.join(
engineSrcDir.parent.parent.path,
'third_party',
'ninja',
io.Platform.isWindows ? 'ninja.exe' : 'ninja',
);
66d043c to
102b862
Compare
|
Notes for reviewers: The important things to know:
|
102b862 to
b6ee5a5
Compare
jtmcdole
left a comment
There was a problem hiding this comment.
lgtm, but some modern dart changes
This adds a post-processing pass to `complie_commands.json` that synthesizes the Swift entries that can be understood by SourceKit LSP and wires up the editor config needed to pick them up. GN's `--export-compile-commands` only understands the built-in `cc`/`cxx`/`objc`/`objcxx` tool types, and doesn't yet have built-in support for injecting `swiftc` lines, so our custom `swift` tool (which invokes `swiftc.py`) never gets an entry there, meaning Swift code in the iOS and macOS embedders isn't indexed by SourceKit LSP and other tooling that reads that file. Since GN's own compdb export omits the swift targets, `_postGn()` now shells out (once) to `ninja -t compdb` for the full compilation database (and falls back to the existing `compile_commands.json` on disk if that fails), then runs it through `expandSwiftcCommands`, which turns each `swiftc.py`-wrapped entry into one or more native `swiftc` invocations, one per compiled Swift file, with relative paths resolved to absolute against the entry's `directory`. We drop `-isystem` and `-Dkey=value` flags since that's what `swiftc.py` does; swiftc only accepts boolean -D defines not key=value flags. This scans the raw ninja output directly rather than decoding all of `compile_commands.json`, which can run past 20MB and is too slow to parse wholesale in Dart; only the small handful of matched `swiftc.py` entries get `jsonDecode`d -- fewer than 10 lines. This also wires up `.sourcekit-lsp/config.json` and the `swift.sourcekit-lsp.supported-languages` setting in `engine.code-workspace`/`engine-workspace.yaml` so that VS Code's Swift extension correctly picks up the generated compdb. Fixes flutter#185741
38311f2 to
dea901e
Compare
|
re-running flakey tests. |



This adds a post-processing pass to
complie_commands.jsonthat synthesizes the Swift entries that can be understood by SourceKit LSP and wires up the editor config needed to pick them up.GN's
--export-compile-commandsonly understands the built-incc/cxx/objc/objcxxtool types, and doesn't yet have built-in support for injectingswiftclines, so our customswifttool (which invokesswiftc.py) never gets an entry there, meaning Swift code in the iOS and macOS embedders isn't indexed by SourceKit LSP and other tooling that reads that file.Since GN's own compdb export omits the swift targets,
_postGn()now shells out (once) toninja -t compdbfor the full compilation database (and falls back to the existingcompile_commands.jsonon disk if that fails), then runs it throughexpandSwiftcCommands, which turns eachswiftc.py-wrapped entry into one or more nativeswiftcinvocations, one per compiled Swift file, with relative paths resolved to absolute against the entry'sdirectory.We drop
-isystemand-Dkey=valueflags since that's whatswiftc.pydoes; swiftc only accepts boolean -D defines not key=value flags.This scans the raw ninja output directly rather than decoding all of
compile_commands.json, which can run past 20MB and is too slow to parse wholesale in Dart; only the small handful of matchedswiftc.pyentries getjsonDecoded -- fewer than 10 lines.This also wires up
.sourcekit-lsp/config.jsonand theswift.sourcekit-lsp.supported-languagessetting inengine.code-workspace/engine-workspace.yamlso that VS Code's Swift extension correctly picks up the generated compdb.Fixes #185741
Pre-launch Checklist
///).If you need help, consider asking for advice on the #hackers-new channel on Discord.
If this change needs to override an active code freeze, provide a comment explaining why. The code freeze workflow can be overridden by code reviewers. See pinned issues for any active code freezes with guidance.
Note: The Flutter team is currently trialing the use of Gemini Code Assist for GitHub. Comments from the
gemini-code-assistbot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.