"Just using SwiftSyntax" is a good point. I suppose a fully-integrated plugin system has advantages: plugin authors could inject custom plugins during any phase of compilation (Syntax, AST, typed AST, SIL, etc), users can use multiple plugins, etc. All of this could be designed to work in Swift.
A compiler plugin consists of:
- Some code that implements an additional compiler phase.
- Some code that uses the compiler plugin API to specify when exactly this new phase should run.
- Additional code that specifies what options the plugin accepts.
Use cases:
Popular compiler plugins (as of 2018) include:
- Alternate compiler back ends such as Scala.js, Scala Native, and Fortify SCA for Scala.
- Linters such as Wartremover and Scapegoat.
- Plugins that support reformatting and other changes to source code, such as scalafix and scalafmt (which are built on the semanticdb and scalahost compiler plugins).
- Plugins that alter Scala’s syntax, such as kind-projector.
- Plugins that alter Scala’s behavior around errors and warnings, such as silencer.
- Plugins that analyze the structure of source code, such as Sculpt and acyclic.
- Plugins that instrument user code to collect information, such as the code coverage tool scoverage.
- Plugins that add metaprogramming facilities to Scala, such as Macro Paradise.
- Plugins that add entirely new constructs to Scala by restructuring user code, such as scala-continuations.
Sorry to veer off-topic about plugins: a general plugin system isn't directly related to integrating libSyntax and involves more things (related: SIL transform in Swift, C++ interoperability). But it may be nice (if it makes sense) to design new compiler phases like Transformer to be amenable to eventual support for plugins. I don't think that would require too much (enable plugins written using SwiftSyntax, support plugin registration, support plugin options).