clangd previously enjoyed having four active maintainers to spread responsibilities around for performing code reviews, issue triage, RFCs, etc. Unfortunately, during the latest maintainer refresh, three of those maintainers had to step away and the fourth has limited bandwidth particularly for review activities.
This leaves clangd dangerously close to being unmaintained with a significant backlog of open PRs and open issues, which puts it at risk of eventual removal from the project unless we can find more folks who are willing to take on maintainer responsibilities for it.
This is an important offering and I think we as a community would like to continue to support it. So if you are an active contributor to clangd and would be interested in taking on those responsibilities, please speak up! If you have questions or concerns, feel free to raise them here or reach out privately.
Could this be at risk because nobody from clangd side will be able to review a large feature in short period of time (including RFC, code patches, etc…).
Maybe interested parties from that gsoc project could become next maintainers?
Hi. I’d be happy to review clangd-related PRs as much as my time allows. I’m not sure I’ll be able to sort out existing PRs, but I’ll try to review new ones.I’m somewhat familiar with the clangd codebase and am running an internal fork
Thank you! Normally I’d recommend not doing any GSoC work with clangd due to questions of whether there’s sufficient mentorship. However. the current HLSL maintainer (@beanz) is one of the recently-former clangd maintainers, so that GSoC project might still be reasonable. But yeah, folks interested in helping with that GSoC project as mentors would be great candidates for maintainers for clangd.
It may be reasonable to announce that tools in limited maintenance mode in Release Notes. May be some users in corporate world could allocate some resources or sponsor development. My company uses it but it’s not in vanilla software business anymore and not as big as Google, Apple, etc.
Having played around with AI code review agents specifically for LLVM reviews, these are unlikely to improve review bandwidth, at least in their current state.
The bottleneck from what I’ve seen in most reviews is gaining an appropriate understanding of the change being made. I do not find AI agents helpful for that.
People can also already request reviews from Copilot given that’s built in to Github.
At our company, I’m responsible for everything related to llvm. We have a dozen changes on top of clangd to fit our needs. I am already trying to help out from time to time, mainly with reviewing on the vs code extension. This during my spare time, as I’m not backed by my company on this. My availability is low (+/- 1 day a month) and will be even lower in the next few months as our family will get expanded soon.
It would really be a pity if clangd would become unmaintained. I see many people recommending it as the best LSP for C++ in VS Code. (And I agree)
clangd’s CI (GitHub Actions for preparing clangd’s standalone releases)
which could also use help with code reviews.
If there are folks who would like to contribute to the maintenance of clangd and have experience with some of the relevant technologies (e.g. Typescript, VSCode plugin APIs, or Github Actions), these projects could benefit from your help without needing particular familiarity with LLVM/clang internals.
I read the policy (again just now) and I don’t understand how this would be a violation. The tool would be generating a review, not generating code and a human reviewer is free to consult that information to help them review a code change or they can ignore it entirely.
Note, I was not proposing that the AI act as an agent to accept changes, merely review the changes.
I didn’t know there was a top-level github org for clangd; does that imply that clangd’s official home is outside the llvm organization? How does the clangd organization related to the llvm organization on github?
I don’t think that’s viable. The point to needing maintainers are because we need critical thinking skills to solve architectural questions, help resolve disputes, set technical direction, etc. LLMs do not think, critically or otherwise. Ignoring the decision making necessities of being a maintainer, my personal experience with such tools is that most of the suggestions are low enough quality that I hide them as spam when I run across AI “reviews” via tools like copilot.
I’ll add, this was intended. I think it’s absolutely fine for a maintainer to fire up a tool to look at the PR and suggest comments, filter them, edit them, and use them to make reviews faster. I’m sure LLMs are great a spotting surface-level issues that we might need to get out of the way. However, when these tools directly comment on the PR, it clutters the review, adds noise, and makes it harder for the reader to focus on the blocking concerns of a real human.
I don’t think it implies that, no. My understanding is that this is just a historical artifact, as clangd adopted Github for issue tracking some time before LLVM did.