Scanner reads inside a block comment: 'module (' on its own line breaks the scan (regression after 2026.9.7.1)

[Sunrisepeak]

Repro — four lines

/*
  module (exe)
*/
int main() { return 0; }

$ mcpp build
error: scanner errors:
  src/main.cpp:2: '(exe) ...

A plain C++ file with a plain block comment. Nothing here is a module unit.

What triggers it

The scan breaks only when all three hold: the text is inside a block comment, the comment's opener /* is on its own line, and the word module is followed by an opening parenthesis.

source	result
/*⏎ module (exe)⏎*/	scanner errors
/* module (exe) */ (one line)	OK
/*⏎ module x⏎*/	OK
/*⏎ the module name⏎*/	OK
// module (exe)	OK

So a line inside a block comment appears to be prefix-matched as a module declaration, and the comment state is not honoured when the opener is alone on its line.

Where it bites in practice

MySQL's libmysqlclient carries this comment in sql-common/client_plugin.cc:

  In the case of external clients we expect libmysql.dll is copied to the client
  dir (to make the loader find it). We expect 3. party dependant dlls used by
  client plugins are copied there too. This function adds dir of the current
  module (exe or dll) to the dll search path, so 3. party dlls are found both in
  native MySQL client scenario nad external client scenario.

Line 4 is module (exe or dll) …, which is enough. mcpp-index's mysql-connector-cpp member consequently fails to build on linux and macOS, deterministically, on every shard that contains it. The English word "module" before a parenthesis is common enough in comments that this is unlikely to be the only affected package.

Version range

Bisected with the four-line file above:

release	result
2026.8.27.2	OK
2026.9.6.3	OK
2026.9.7.1	OK
2026.9.10.2	scanner errors

So it lands after 2026.9.7.1. (Narrowing 2026.9.8.1 / 2026.9.9.1 now; will comment with the exact release.)

Impact on downstreams

mcpp-index needs ≥ 2026.9.7.1 for a package whose build program uses mcpp::package_name() (#587), and 2026.9.7.1 happens to be the last release before this regression — so its CI pin can sit exactly there. That is luck, not a fix: the next descriptor needing a newer API will have nowhere to stand.

[Sunrisepeak]

Narrowed — the regression is introduced in 2026.9.9.1:

release	four-line repro
2026.8.27.2	OK
2026.9.6.3	OK
2026.9.7.1	OK
2026.9.8.1	OK
2026.9.9.1	scanner errors
2026.9.10.2	scanner errors

So the change is in whatever landed between v2026.9.8.1 and v2026.9.9.1.

[Sunrisepeak]

Still present in 2026.9.11.1 — the four-line repro reproduces there too:

release	four-line repro
2026.8.27.2 · 2026.9.6.3 · 2026.9.7.1 · 2026.9.8.1	OK
2026.9.9.1 · 2026.9.10.2 · 2026.9.11.1	scanner errors

So the last good release is still v2026.9.8.1, and anything from v2026.9.9.1 onward is affected.

[Sunrisepeak]

Fixed in 2026.9.11.2. The four-line repro builds clean there:

release	four-line repro
2026.8.27.2 · 2026.9.6.3 · 2026.9.7.1 · 2026.9.8.1	OK
2026.9.9.1 · 2026.9.10.2 · 2026.9.11.1	scanner errors
2026.9.11.2	OK

So the affected range is v2026.9.9.1 … v2026.9.11.1 inclusive. Thanks.