r4nt3r
Re:Apple's investment into Clangd and refactoring tooling
on Friday April 20, 2018 @03:37AM (#16882874)
The main problem with libclang is actually that it puts another abstraction on top of the AST that nobody really had time to maintain.
That's not made better by the amount of work changing libclang requires just due to its backwards compatibility promises.
Re:Apple's investment into Clangd and refactoring tooling
on Friday April 20, 2018 @03:35AM (#16882857)
While I agree that not everything is always great, I'd say the same for our own contributions ;) I've definitely let patches unreviewed for way too long due to internal priorities, and have gotten my share of shit at conferences for that...
In this case, the collaboration with Apple and Ericsson on the underlying architecture has been going on for a while, and while not everybody always agrees on priorities and design details, I'm thrilled to see Apple double down on their involvement here!
Re:Apple's investment into Clangd and refactoring tooling
on Friday April 20, 2018 @03:30AM (#16882836)
clangd already has a layered architecture, where you can either use the JSON-RPC mechanism or more directly control clangd and implement your own transport. There are no plans for this to go away, as generally large companies often have environments in which they want better control of features than a standard protocol like LSP can give you, and we don't discourage that.
We also just talked with Apple folks at Euro LLVM about this, and while the plan for the near future is for them to have a transport conversion to JSON-RPC, I expect them to want the more fine grained control in the long term.