[Self-Filed] Could we also support Swift?

[cpsauer]

Status: There's an Apple project to (basically) add Swift support to clangd here. It doesn't look mature enough yet (2/2021), but perhaps it will be by the time we'd need it.

Suggested Workaround: Use Tulsi for now.
(Hedron Friendly Faces should use our internal XcodeAdapter wrapper for Tulsi)

[yrom]

Is there any progress?

[cpsauer]

Hey, @yrom! Nope, since you're the first to express interest here. Let me check in on the Apple project.

Looks like the Apple project (linked above) is still listed as early development, but is also now bundled in Xcode and has a fairly popular, highly rated vscode extension. So maybe a good time to explore. And there's no harm to supporting it early.

I probably shouldn't just build this myself right now only because there's too much else going on. (Need to focus on the startup I'm running, and we don't currently use Swift.) But I'd be delighted to help if you'd be interested in adding this, especially since you just submitted a great pr :) I think integrating it into this tool would be be the way to go, much better and easier than doing separately.

A high level sketch of what I'd imagine could be a good way of doing it:

1. First, it'd be valuable to check that the Apple project looks to be working well enough to integrate--and needs an integration. I'd probably spin up some quick tests:
   i. First a non-bazel project using their vscode plugin and making sure that it was supplying decent autocomplete, etc.
   ii. Then using their tool with an existing bazel workspace to check on its compile_commands.json loading, checking that there's a strong need to add compile_commands.json entries to get better autocomplete, and figuring out how to get their indexing during building to work with Bazel.
2. Assuming everything looks good, add the swift compile to our aquery mnemonics filter, separating out those commands so we don't try to pass them to clang to do header extraction, but directing them into compile_commands.json
3. And finally, we'd add some docs so other people can figure out how to use it, too!

-CS

[xinzhengzhang]

Hi, @cpsauer I have done some work to extend command-extractor for apple project based on Sourcekit-lsp. It works well on swift and objective-c project using swift plugin in vscode(conflicted with clangd plugin). But the approach needs create and run a bsp(Build server protocol) server to provider compile commands to it. Do you think it should be just another fork for apple or a pull request to the command extractor?

[cpsauer]

Thanks for chiming in :) I think we should collaborate to merge it if we can! Much better to have a cross platform tool.

But I'd like to understand a little bit more.
Some questions:

• How well does sourcekit-lsp work? Do things work well, like clangd?
• Could you tell me more about this BSP server? Can sourcekit-lsp not just take in a compile_commands.json? (I thought I saw code snippets indicating yes, but I could be wrong.)

Thanks!
Chris

[xinzhengzhang]

Hi Chris,

How well does sourcekit-lsp work? Do things work well, like clangd?
- Since sourcekit-lsp is top of clangd it is exactly the same experience under objc and c (there isn't much cpp code in our project)
- Most features in https://clangd.llvm.org/features are supported under swift code
- Since plugin didn't support .swiftinterfce .swiftdoc not being able to open the module's viewer like in xcode can be frustrating (swiftlang/vscode-swift#408)

Could you tell me more about this BSP server? Can sourcekit-lsp not just take in a compile_commands.json?
- Yes, sourcekit-lsp can not take in a compile_commands.json but I found an injection point(seems that it was used for testing or remote indexing) in BuildServerBuildSystem
- We can inject our compile commands into sourcekit-lsp by creating a buildServer.json
- Build a server implement the BuildServerProtocol
- Finally there are two file generated by refresh_compile_commands in root of the workspace

• compile_commands.json
• buildServer.json

---

I have pushed my fork and created a sample project (https://github.com/xinzhengzhang/bazel-compile-commands-extractor/blob/feature/swift-commands/examples/ios/README.md)

• cd examples/ios
• bazel build //:app
  • for building swiftmodule
• bazel run //:build_bsp
• code .

[cpsauer]

Sweet! Thanks for all your good work. I need to head to bed now (it's super late my time), but I'll come back to this.

Re compile_commands.json, you're sure? I thought I saw references to watching compile_commands.json in the code for sourckit-lsp, and I see some references in the Q&A. Obviously I'm eager to simplify/not run a server if we don't have to, but I know you've played around with this much more than I have and probably had good reason to spend time writing the server :) Where does supplying a compile_commands.json fall short?

Anyway, once we've got the question of the simplest overall approach resolved, let's unify implementations! :) Ideally we'd make this work automatically for people (i.e. automatically generating swift entries if they're compiling swift code) and sharing almost all of the implementation between the languages.

[xinzhengzhang]

I didn't noticed that there is another branch to CompilationDatabaseBuildSystem and went to investigate BuildServerBuildSystem and everything as usual when I removed buildServer.json!

Fortunately, it didn't waste too much time on the service because it is just a forwarding of compilation commands. The server part has been removed in my branch

[cpsauer]

Oh yay! That simplifies things greatly.

Could I ask you to reunify the extractor implementations, and then PR it up so we can merge in? Looks like the two of you guys might work together at bilibili? Feel free to submit incremental patches, if that's faster and easier. Happy to help if things get stuck.

[xinzhengzhang]

Hey Chris @cpsauer ,
Can you please to help me review it? #89

[cpsauer]

Definitely. Sorry for being a bit slow, @xinzhengzhang. Took a quick break for thanksgiving and am scrambling to catch back up. Reading now! Will continue discussion over on #89

And again, thank you!