GeezerVison

Duplicate — see my other review on this PR.

Reviewed at bce7f59 against current develop.

Fixes the #385 case and the harder valid C++20 forms that a same-line ]<...> check misses — multiline template parameter lists, ]<T> with ( on the next line, and trailing requires-clauses. I compiled those with g++ -std=c++20 -pedantic-errors -fsyntax-only and confirmed they stay clean here while ordinary templated/constrained functions and operator[] (including multiline) still warn. Full unit suite: 206 passed.

This conflicts with #458; I’d take this one — it’s the more complete coverage for the same issue.

Rechecked at fee646d. Merge with current develop looks clean — both changelog entries are preserved, and the templated-lambda logic is unchanged from bcf7f59.

Re-ran the earlier cases against this head: #385, multiline template params, ]<T>n(, and requires-clauses stay clean; templated/constrained functions and multiline operator[] still warn. Full suite: 206 passed. Still LGTM.

Reviewed at fee646d.

The matcher keeps ordinary constrained functions and multiline operator[] declarations in the trailing-semicolon path while recognizing the C++20 templated-lambda forms. I also checked a trailing requires-clause lambda and confirmed it stays clean under the repository's brace-style rule.

Verified locally:

python -m pytest --no-cov -q
231 passed

git diff --check upstream/develop...HEAD
Passed

LGTM.

Reviewed current head fee646d.

The lambda-capture matcher follows multiline template parameter lists and requires clauses while the negative controls keep ordinary operator[] and constrained function definitions in the trailing-semicolon path.

The focused coverage includes the same-line #385 case plus multiline template/requires variants, and the current checks are green. LGTM.

I found one remaining false positive on the current head with a templated lambda whose template requires-clause contains a multiline requires-expression:

auto identity = []<typename T>
    requires requires(T t) {
      t.foo();
    }
(T t) {
  return t;
};

This still reports readability/braces on the final };.

I reproduced it with a focused TestMultiLineLint regression. The issue is in MatchLambdaRequiresClause(): walking backward from (T t) { first reaches the requires-expression's closing }. The [;{}] boundary check returns immediately there, so the scan never reaches the preceding requires clause / lambda capture.

A robust direction is to skip a matched multiline brace region with the existing ReverseCloseExpression() helper when the scan encounters }, then continue looking for the enclosing requires-clause. I tested that locally with positive requires-expression cases and negative controls for ordinary functions / operator[]; the full suite remains green.

Local validation on the candidate fix: 231 tests passed, Pylint/Mypy/pre-commit passed, and git diff --check passed.

I don't have a working C++ compiler in this environment (cc1plus is missing), so I couldn't independently compile this syntax locally.