Google's requirements have drifted away from the already very broad range that lld, and llvm-project at large, serves. A feature only one company's internal pipeline might need should prove itself there before it lands upstream, where everyone maintains it.

I was junior; he was far more senior. Landing a feature on a promise of future use, and deferring the reviewer's design concern to "a later patch", is not how open source should work.

and another lld maintainer independently flagged the misplacement and found my 2020 comment. When I left Google in 2024, --optimize-bb-jumps still had no users. The answer was always "we will use it." Today nothing in llvm-project passes the flag; only three lld tests do.

That placement was a wrong-code bug from day one: the pass shrinks .text after .relr.dyn is computed, so RELR entries point at the wrong words. Since a change this year, .eh_frame_hdr search keys go stale too. An AI-assisted patch surfaced it recently,

In 2020, reviewing lld's --optimize-bb-jumps (reviews.llvm.org/D68065), I asked that the pass run inside finalizeAddressDependentContent "to accommodate thunks and linker script symbol changes." The author replied: "Could we do this in a later patch?" There was no later patch.

The Zola+tabi migration is vibecoded:) The website was stuck using github.com/hexojs/hexo-theme… for 10+ years...

maskray.me/blog/who-pays-for… Who pays for Clang Another AI slop post. Commits by employer, What each funder works on, Review, Shared and vendor-specific work

Comment on "RFC: Enable ClangIR Build By Default-" discourse.llvm.org/t/rfc-ena… Current feeling: it might be a huge opportunity cost

For C++ programmers who were Clang's main constituency, CIR has to earn its place by being better at what the AST, the CFG, and classic CodeGen do today: diagnostics, safety analyses, and optimizations that need C++ semantics, without making the compiler slower to build or run

The new funders build GPU and accelerator compilers, and their other compilers (Flang, Triton, IREE, their own stacks) are built on MLIR. For them, a Clang that emits an MLIR dialect is the point, not an implementation detail.

I spent many hours driving the agent through Discourse threads, slides, source trees, and LinkedIn profiles to generate this AI slop: maskray.me/blog/clangir-and-… ClangIR and the cost of MLIR

github.com/MaskRay/ccls/rele… Indexed forwarding functions such as std::make_unique<A>(...) and std::vector<A>::emplace_back(...). Hover on an auto variable in a function template shows the deduced type when the template has exactly one instantiation. Adapt to LLVM 22, 23 and 24.

edgls is a C/C++ language server built on the EDG C/C++ front end. It is a fork of ccls with the clang-based parts replaced: the indexer, diagnostics, compile command handling, code completion, signature help, and formatting. github.com/MaskRay/edgls Verdict: Slower than clang

Credit where it's due - I'm glad I could connect with the original author six years later. For features added today, I doubt maintainers in one year will be as lucky in finding the original authors.

Settling an old score: --fortran-common (added in 2020) was removed from lld/ELF in September 2026, removing one blocker of fully parallel input file parsing and symbol resolution.

I made a typo earlier and wrote 'useful' instead of 'useless' regarding the 'testsuite must pass' requirement. The author agreed without question. Their other replies are almost direct copy pastes.

Extractive patches from a new contributor to llvm binary tuilities. "But it's Codex output the author doesn't really own, so reviewers end up supplying the understanding." llvm-project really should really adopt a ghostty-style vouch system.

There is finally a migration path for LLVM's llvm::cl::opt, off dynamic initialization and onto a data-only TableGen representation: one struct per library, constant-initialized, read with a single load. No option spellings change. discourse.llvm.org/t/rfc-dec…

Speaking as a maintainer across multiple components: I wish LLVM adopted a Ghostty-like policy to protect maintainers. Established contributors use AI to accelerate good work, but unvetted drive-by PRs generated with the same tools are swamping the project with low-quality code.

`# RUN: llvm-dwarfdump --debug-names %t.bolt FileCheck --check-prefix=POSTCHECK %s` It passed even if the pipe `|` was missing: llvm::cl:: parsed --check-prefix as grouped -c -h…, hit -h, printed --help, exit 0. FileCheck never ran. No "Unknown command line argument" error.