diff options
| author | Daniel M. Katz <katzdm@gmail.com> | 2025-11-22 22:11:58 -0500 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2025-11-23 11:11:58 +0800 |
| commit | 525e68e9e9a44e88eb88ef2d6f058a482972c989 (patch) | |
| tree | 11ab6855bfc08c95fe022ea3cd146a54dcc094a8 /clang/docs/ReleaseNotes.rst | |
| parent | 0859ac5866a0228f5607dd329f83f4a9622dedcc (diff) | |
Don't mark lambda non-dependent if nested in a generic lambda. (#149121)
Fixes #118187
Fixes #156579
An instantiated `LambdaExpr` can currently be marked as
`LDK_NeverDependent` if it's nested within a generic lambda. If that
`LambdaExpr` in fact depends on template parameters introduced by the
enclosing generic lambda, then its dependence will be misreported as
"never dependent" and spurious diagnostics can result.
The fix here proposed is a bit ugly, but the condition that it's being
bolted onto already seems like a bit of a hack, so this seems no worse
for wear.
Note that #89702 surfaced this change because it caused the inner lambda
expression to (correctly) be considered in a constant-evaluated context.
The affected check for whether to mark the inner lambda as
`LDK_NeverDependent` therefore started to apply, whereas it didn't
before.
**Tested**: `check-clang` and `check-cxx`.
Diffstat (limited to 'clang/docs/ReleaseNotes.rst')
| -rw-r--r-- | clang/docs/ReleaseNotes.rst | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst index 63930f43c25e..8161ccdffca8 100644 --- a/clang/docs/ReleaseNotes.rst +++ b/clang/docs/ReleaseNotes.rst @@ -557,6 +557,7 @@ Bug Fixes to C++ Support - Diagnose unresolved overload sets in non-dependent compound requirements. (#GH51246) (#GH97753) - Fix a crash when extracting unavailable member type from alias in template deduction. (#GH165560) - Fix incorrect diagnostics for lambdas with init-captures inside braced initializers. (#GH163498) +- Fixed spurious diagnoses of certain nested lambda expressions. (#GH149121) (#GH156579) Bug Fixes to AST Handling ^^^^^^^^^^^^^^^^^^^^^^^^^ |