Bundled Clang rejects `pre()` on a declaration, so a corpus using C++26 contracts cannot be extracted

[mpusz]

mp-units expresses preconditions as pre() on the declaration when contracts are available (P2900, C++26), guarded on __cpp_contracts >= 202502L. The bundled Clang rejects them.

Reproduced with MrDocs 2026.9.4 (LLVM 23.0.0git) on a declaration equivalent to:

[[nodiscard]] constexpr const_reference operator[](size_type pos) const pre(pos < N);

With -std=c++26, and again with -std=c++2c -fcontracts, both fail identically with expected ';' at end of declaration list followed by cascading use of undeclared identifier errors, and the corpus comes out empty (0 pages). Passing -fcontracts made no difference to the diagnostics.

So today we have to generate the reference with contracts switched off, which is a pity, because the contracts are the part of the interface a reader most wants to see.

Questions: is P2900 support in the bundled toolchain on the roadmap, and in the meantime is there a way to have the parser skip a contract annotation rather than fail the translation unit?

[alandefreitas]

This is possible to extract. If contracts don't make it into C++ and Clang ends up removing them, we would lose the feature, if that's OK.

Partially dependant on #836

[mpusz]

Losing it is not what worries me, but I would push back on the premise.

If contracts are pulled, it will be among others because of poor implementation and limited field experience. That doesn't get fixed by libraries waiting. It gets fixed by libraries using them in the interim, deploying them, and reporting what broke. mp-units already has the support, so we intend to be one of those libraries rather than sit the period out. If everyone withdraws instead, the next cycle reaches the same objection with the same evidence, three years later.

That is why I think the parser should accept them regardless of how P2900 lands. There will be code carrying pre() and post() for years either way, against whichever revision a given compiler implements. MrDocs ships Clang, and we build with GCC 16 and -fcontracts, so the two do not even have to agree on a revision for this to matter. A documentation tool that fails the translation unit on the syntax cannot document any library doing that work.

The two halves are worth separating, because only one is blocking. A single pre() on a declaration currently fails the whole translation unit: the corpus comes out empty, 0 pages, not degraded. Accepting the annotation and discarding it would unblock us completely and needs nothing from #836, at the cost of not rendering it. Rendering the predicate is the better outcome and can wait for ExprInfo.

Parse-and-ignore is also the half that stays useful whatever happens to the paper, since the alternative is a hard failure on any code using the extension.