https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127132
--- Comment #5 from Vladislav Semykin <vladislav.semykin at gmail dot com> ---
This turns out to be a side effect of the same [expr.typeid]/4-5
two-pass parse the PR125886 fix introduced (r17-2200-g621661f7d2e9).
process_outer_var_ref (the lambda capture decision) and typeid_evaluated_p
both key off the same cp_unevaluated_operand flag, so anything referenced
during the two-pass's unevaluated "probe" of the typeid operand never gets
captured - not only in generic lambdas.
Per [expr.prim.lambda.capture]/7, capture must happen "regardless of
whether [the operand] is an unevaluated operand" - the standard's own
example (g3) is literally typeid(a + x) inside a generic lambda. So the
same root cause also silently drops capture for genuinely unevaluated
typeid operands in any lambda, generic or not - harmless in practice
since the operand's value is never read at runtime for those, but
non-conformant:
```cpp
void capture_regardless_of_evaluated(int n) {
auto lam = [=] { (void) typeid(n); };
static_assert(sizeof(lam) == sizeof(int),
"n must be captured regardless of typeid(n) being "
"unevaluated");
}
```
https://godbolt.org/z/9rqex4q85 - clean on GCC 16.2, fails on trunk.
Discussing a redesign around process_outer_var_ref with Jason Merrill on
gcc-patches (the currently posted patch only addressed the generic-lambda
symptom). Will post the revised patch once we agree on the approach.
