Record clangd 22.1.8 modules re-canary: consolidation blocker narrowed to one failure class

[ptesavol]

Docs-only. With preconditions 1 (Android) and 3 (header DAG) resolved, I re-ran the clangd modules canary against the current toolchain (clangd 22.1.8) to get a precise reading on the last gate — precondition 2, "clangd can lint purview code". The verdict is much narrower than the memo's 2.1-era wording:

What now works (tested with clangd --check + each package's compile database):

• Module interface units lint clean — including the heavyweight folly/protobuf GMF unit streamr.dht-all.cppm. The only diagnostics are misc-unused-using-decls false positives on the export using re-export blocks: suppressible, and moot after consolidation (consolidated code lives in purview; there are no re-export blocks).
• Import-using consumers lint clean — clangd loads the build tree's BMIs through the compile command's -fmodule-file= flags. No --experimental-modules-support needed.

The one remaining failure class: preamble/BMI std-type unification. When a std type crosses the module boundary in an API — e.g. EthereumAddress = Branded<std::string> — clangd treats the preamble's textual std::string (from <string>/gtest includes) and the BMI's std::string as distinct types, producing spurious "no matching constructor/function" diagnostics. This is exactly the still-excluded toEthereumAddressOrENSNameTest.cpp, and post-consolidation it would hit any consumer passing std types to imported APIs. This class alone is what still blocks consolidation.

The memo now records a one-command re-canary recipe to run on each LLVM release; the moment that single case reports clean, all three consolidation preconditions are green and the go/no-go is purely an owner decision.

🤖 Generated with Claude Code

[cursor]

Bugbot is not enabled for this team, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.