[cfe-dev] RFC: A proposal for a Clang-based service architecture
eliben at gmail.com
Tue Jun 12 11:12:31 PDT 2012
On Tue, Jun 12, 2012 at 12:43 PM, Chandler Carruth <chandlerc at gmail.com> wrote:
> Greetings all!
> What follows is a fairly lengthy and detailed design document for a proposed
> persistent Clang server (or clangd in unix-terms) to serve as infrastructure
> for increasingly advanced and interactive C++ tools. It should generalize
> and build upon libclang, and will allow us to effectively target Vim, Emacs,
> and other editors. This is something we're planning to pursue in the near
> term, so I'd appreciate any and all feedback.
> Here is a Google Docs link you can use to view and comment on the proposal:
> Its interim home is on github here, where you can see the history and the
> actual rest version in all its glory:
> I've also attached the text for email-based comments.
Great proposal, I really like the potential of such a project - it's
exactly the kind of service that can start with one thing in mind and
then find itself adapted for various interesting uses. That said, your
initial proposed application is awesome and itself worth the effort -
having real IDE-ish code completion and indexing in Vim & Emacs could
Some minor comments on the design document:
* Goal: "Provide a restartable, long-lived background process which
manages caching, compilation, indexes, and performs the business
What does "compilation" mean in this context? From the rest of the
document I understand Clang is only used for its analysis features,
not for actual code generation or full compilation.
* "The crazy stretch goal for this is O(1ms) for code-completion with
fully warm and primed caches."
It really sounds overly ambitious, taking IPC and a fairly complex
code-base into account. Why 1ms, though? Since this is user
interaction application, isn't 1ms far, far below the human detection
* "The communication protocol will take the form of serialized
messages encoded using the LLVM bitcode system"
Why the LLVM bitcode system, and not a library designed for IPC, such
as protobuf? I realize this means less external dependencies, but it
can also be a burden on a subsystem that was designed for a different
purpose. Not to mention that something like protobuf gives you IPC
bindings for other languages for free (Python, Java, etc.)
* s/filei system/file system/
* "Likely only to support Linux and local sockets"
You mean Unix domain sockets
(http://en.wikipedia.org/wiki/Unix_domain_socket) or "normal" sockets
on localhost ?
More information about the cfe-dev