adapt codebase to Clang

[Ichthyostega]

Clang is a well-designed modern compiler based on the LLVM compiler framework. It can be used as a drop-in replacement for GCC and is known to produce way more consistent and readable error messages. We want to support compilation with both Clang and GCC as a means to ensure good conformance to language standards, and to avoid accruing unintended technical dept.

Clang generates additional warnings and diagnostics, which should be resolved.

The purpose of this ticket is to remind and track progress for this ongoing and sometimes tedious task

[Ichthyostega]

• Wunneeded-internal-declaration

[Ichthyostega]

After a bunch of bug-fixes, we're now able to compile with Clang, and the test-suite runs without failure.

Lots of further warnings remain to be resolved though

[Ichthyostega]

put this *on hold*.

Our reference system is Debian-Wheezy; but CLang 3.0 is just not up to the job. After the C++11 transition, it segfaults when complining some inline lambdas.

We should consider to raise the minimum version level of CLang to 3.4 and we should consider to upgrad the reference system to Debian-testing (Jessie)

[Ichthyostega]

further initialisation problems when running the testsuite, compiled with Clang 3.4 on Debian-Jessie.

• problem looks quite similar to initialisation issues I've fixed one year ago, in f136220131
• we're about to init a static object field (typically templated). This field uses a _Fmt object, which lives in a local (anonymous namespace) variable in the enclosing scope
• seems like GCC initialised all local variables in a given compilation unit from top to bottom, while Clang first initialises all static fields, and later the local variables in a second pass.
• consequently the static initialisation uses a not-yet constructed _Fmt object, which leads to all kinds of segfaults and weird behaviour.

These usage situations happen to be in unit test code only, since such a usage is also not thread safe and not re-entrant (the boost::format implementation is stateful). While in theory this could be fixed by always using a Meyers singleton, in such cases the simplest fix is just to construct a new formatter object on each call....

[Ichthyostega]

currently, we can build with Clang 3.5, but still get a lot of additional warnings

[Undercover Agent]

Migration MasterTickets ⟼ Subtickets-plugin

[Ichthyostega]

This is established practice in the Lumiera project. With #1436 our buildsystem supports generation of a compilation database, so that clangd can be used for code-intelligence and diagnostics.

[Ichthyostega]

In 0661b27/Lumiera:

clean-up: resolve some Clang conformance divergences (see #928)

Knowledge-Technology(Claude Opus 5) used

• to analyse and reassess the situation
• to discuss and weigh the findings and develop solutions
• to perform the selected mitigation and verify success

---

Report by Claude

A sweep with Clang-22 over all 597 translation units (driven from the newly
generated compilation database) showed 271 of them failing, yet with the
2502 diagnostics tracing back to very few root sites. This resolves those
where GCC is simply the more permissive of the two; the remaining clusters
are a matter of design and are left alone for now.

• using Alias::OriginalName; does *not* declare inherited constructors. Per [namespace.udecl] a using-declarator names constructors only when its terminal name equals the last component of the nested-name-specifier -- so through an alias, the terminal name is read as the injected-class-name, i.e. a type, and Clang then demands typename. Clang is right here. Affects hetero-data.hpp (19 TUs) and iter-source.hpp (62 TUs); in the latter the alias is renamed _I -> Adapter while we are at it. Note iter-source as a whole awaits a design review, see #1125

• P1787R6 requires a template-argument-list after the template keyword. holder.template emplace (...) in opaque-holder.hpp and two sites in node-builder.hpp supply none, so the keyword has to go (83 TUs).

• A default template argument may be given only once per scope. The out-of-class definition of OutputSlot::AllocState repeated the default from its declaration in 'output-slot.hpp' -- note the friend-declaration further down in the same header already got this right.

• constexpr auto ROUGH_PRECISION = pow (10, -3) is not a constant expression by the standard; only GCC accepts it, through a builtin. Hence util::ipow() in 'util-quant.hpp', an exponentiation with integral exponent by square-and-multiply, as a counterpart to ilog2(). Exact for representable base and result, and the static_assert documents that ipow(10.0,-3) is bit-identical to 1e-3. 193 TUs depended on this single line.

Furthermore, two findings made while surveying:

• lib/stat/statistic.hpp held a second, dormant instance of the same pow problem, in a round<places>() helper that nothing in Lumiera ever instantiates -- which is why Clang never saw it. Since the helper is also the naive and imprecise formulation, it is removed here; a note records that it stays in use upstream in yoshimi-test, where this header comes from, and that decimal rounding belongs to #1360 if ever wanted here.

• The alias DataBuilder was defined twice, identically, in 'weaving-pattern-builder.hpp' and in 'node-builder.hpp' which includes the former. Both compilers tolerate the duplicate definition and only Clang objects to the repeated default argument, which is why this went unnoticed. The duplicate is dropped and its documentation moved to the surviving definition -- together with a @todo, since DataBuilder, SizMark and UseHeapAlloc are vocabulary of the node-builder DSL and reside where they do by accident of include order.