I think being able to facilitate tooling that integrates more closely with the Swift compiler would possibly be a great addition to the project, if it can be done well. The main concerns I have are stability of the plugin interface and security.
For stability of the plugin interface, Clang plugins access the raw compiler internals, which are subject to change. Even with Clang — which is far more mature than the Swift compiler — the internals of the compiler are constantly changing and don't constitute a stable API to build plugins. Is this the right interface to build a plugin ecosystem? Maybe this is not something to care about, since Swift itself as a language continues to evolve and the underlying semantics modeled in the compiler will continue to evolve as well. Plugins would need to adapt to those changes.
Security is also a concern. Plugins having arbitrary access to the compiler internals makes them a possible security liability if they can alter the output of the compilation pipeline. But in some contexts that might be OK, and others not so much. I think being able to build great tools that help with developer productivity is important goal of the project; but I think it's more than just exposing compiler internals to plugins in the simple way done by Clang Plugins.
Note that with Swift we have the opportunity to do something we cannot as easily do with Clang, and that is change the build workflow to support calling out to external tools at critical points, with those external tools possibly being built on top of the Swift compiler libraries or SourceKit. I recall years ago when I was working on the Clang Static Analyzer and we were bringing up integration of that technology in Xcode that it was so marvelous that we could actually extend the build system to call out to invoke the static analyzer, as other static analyzer tools for C had taken the approach of trying to retrofit themselves into the build model by using process interposition and other techniques. By making the tooling support — in this case the Clang Static Analyzer integration — something handled first class during the build it defined away many problems. Perhaps if we want to build a set of tools that naturally would be compiler plugins to the Swift compiler, we should look to see where they might naturally "drop in" to the build workflow. Then various higher-level tooling, be it IDEs or CI systems, could depend on such tools being naturally run at specific stages of the build pipeline.
None of this has a design, but there is a lot of great stuff that could be built here. If you are interested in exploring this more, I think a natural point would be to suss out technology directions here first on swift-dev. A swift-evolution proposal seems like a natural product of a lot of discussion and design, but I'd expect the discussion for that kind of extension to Swift to probably happen more on swift-devs than swift-evolution since it is about the internals of the compiler and tools, rather than the language.
On May 10, 2016, at 11:32 PM, Jorge Bernal via swift-dev <email@example.com> wrote:
I’ve recently been looking into implementing a lint checker for Swift code in my project. I’ve used SwiftLint so far, but I’d love to build something that integrates more closely with Xcode: only check what is being rebuild, provide Fix-Its,…
From what I’ve found there’s no equivalent of Clang Plugins in the Swift compiler.
Is this something interesting or already planned?
Should it go through a swift-evolution proposal?
Jorge Bernal | firstname.lastname@example.org | email@example.com
Mobile Engineer @ Automattic | http://automattic.com/
http://koke.me/ | http://jorgebernal.es/ | http://twitter.com/koke
swift-dev mailing list