Extend irony to cover Swift

[ryanprior]

swift-mode has this open issue: swift-emacs/swift-mode#123

We want to build tool support for Swift, so we're going to want to have a server to provide the necessary info. Since irony's server already uses llvm and libclang, is it a good idea to extend irony using Apple's llvm swift infrastructure and build on top of that?

cc: @nicklanasa

[Sarcasm]

Since irony's server already uses llvm and libclang

Only libclang. which is one of the reason it's easy to use.

is it a good idea to extend irony using Apple's llvm swift infrastructure and build on top of that?

As much as I would like it to be a good idea, I honestly don't think it is, you may be better of rolling your own even if I understand that's what you would like to avoid. There is honestly not much of value in irony-mode, it's just some glue to libclang. If you don't use libclang, it's not super-useful. The communication between the server/emacs is also fairly trivial and one might be better of using something else. If only Emacs has some protobuf/msgpack/capnproto library or such, that would be nice IMHO, tools could be made more generic but still efficient.

I see that company-sourcekit answer somewhat the problems for completion. syntax checking I don't know if there is already something, but there is nothing more in irony-mode for now.

I don't think irony-server will ever grow too much, it will always be a simple "libclang-server". I would like to integrate other tools in the future maybe, like kythe.io if necessary, clang-tidy or similar refactoring tools. So there might be some general improvment with regard to the communication with external tools that can be worked together and could be useful for plenty of other projects.

By the way, I see that Switch has an IDE library, which might be relevant to you:

• https://github.com/apple/swift/tree/master/include/swift/IDE

[ryanprior]

Let me check my comprehension of your response. Please correct me if I'm missing the point. :-)

Any time we're passing big buffers between Emacs and external processes, it bogs down. Thus, people tend to move all the functionality they can into external processes to cut Emacs out of the loop to the greatest extent possible - we see this pattern with Robe for Ruby, Irony for (Objective-)C/C++, Tern for JavaScript, etc. The end result is language tooling that does its work on the server side and can't really be maintained and extended in elisp.

Emacs 25 will land soon and we'll be able to load dynamic modules for the first time. Using that, we can create a dynamic Emacs module for Cap'n Proto so that we can move more language tool support into elisp without repeatedly incurring big serialization costs.

With that in place, we can efficiently share Emacs buffers with a compiler process for Swift or C++ or whatever, that likewise shares its parse tree with Emacs, maybe using a standard system like kythe.io. On top of that we build an elisp framework that reads the capnp stream and generates relevant data structures for completions, documentation, refactoring, etc either by leveraging tools that are already provided by Semantic or rolling out new tools as necessary.

Am I missing any big pieces? Does this sound like a more viable idea than trying to extend/reuse Irony? Is it a better idea than creating Yet Another External Language Support Server especially for Swift?

[Sarcasm]

Any time we're passing big buffers between Emacs and external processes, it bogs down. Thus, people tend to move all the functionality they can into external processes to cut Emacs out of the loop to the greatest extent possible - we see this pattern with Robe for Ruby, Irony for (Objective-)C/C++, Tern for JavaScript, etc. The end result is language tooling that does its work on the server side and can't really be maintained and extended in elisp.

I'm not totally sure to understand, to me there is some pros and cons to have external tools do the hard work, non-exhaustive list:

Cons:

• added complexity, you don't call a function to get the result but send a request, receive a response, parse the thing, ...(this complexity can be leveraged by libraries though).
• overhead of passing data to the external process, might impact responsiveness (i.e: not nice for things like completion)

Pros:

• emacs is not multithreaded, so if you don't want to block the editor, it's nice to work with external processes
• external process can crash without making emacs crash
• emacs cannot be extended to integrate FFI/libclang directly, this may howewer change in the near future as you point out
• one can re-use the tooling of existing languages, e.g: clang-format, one tool easily integrated into multiple editors (I like this model personnally)
• dedicated tool, sometimes coming from the compiler itself make it easier to keep up with the language, I'm not sure one should expect semantic to keep up with C++ for example

Emacs 25 will land soon and we'll be able to load dynamic modules for the first time. Using that, we can create a dynamic Emacs module for Cap'n Proto so that we can move more language tool support into elisp without repeatedly incurring big serialization costs.

Interesting, yes that would appeal to me, do you have a link to the module support in Emacs, I take a look from time to time to emacs-devel but I could not see a link to explain how module will work.

With that in place, we can efficiently share Emacs buffers with a compiler process for Swift or C++ or whatever, that likewise shares its parse tree with Emacs, maybe using a standard system like kythe.io. On top of that we build an elisp framework that reads the capnp stream and generates relevant data structures for completions, documentation, refactoring, etc either by leveraging tools that are already provided by Semantic or rolling out new tools as necessary.

Am I missing any big pieces?

Sounds okay to me.

Does this sound like a more viable idea than trying to extend/reuse Irony?

I think so.

Is it a better idea than creating Yet Another External Language Support Server especially for Swift?

Well, I'm not really opposed to dedicated server tools that provide the functionality to multiple editors, communicating using a cross-language serialization language (json, capnproto, ...).

[nicklanasa]

Sorry for the late reply. So, it seems that writing our own parsing or utilizing the Swift IDE library would be a good start? Would it be wise or needed to wait until emacs 25 to land?

I took a look at irony-mode and set it up on my local machine. It's pretty quick and completion works nicely for objective C projects. It really nice.

@ryanprior What do you think the best route to take is? Especially with all this new found knowledge.