Clang C++20 Feature: P0588R1 - Simplifying implicit lambda capture

[h-vetinari]

id: P0588R1
paper: https://wg21.link/P0588R1

This paper doesn't have a tracking issue in the C++20 project yet¹. It also shows up on the cppreference implementation status page, and presumably should be tracked in https://clang.llvm.org/cxx_status.html (like other DRs that have a Pxxxx).

I found some related issues², but none dedicated to this:

• Incorrect if constexpr evaluation in nested generic lambda #58872
• Erroneous if constexpr instantiation in lambda template #44851
• decltype for lambda capture gives wrong type #37673
• decltype((x)) inside lambda is considered odr-use if x is captured #34771

Most recently, @erichkeane wrote in #58872:

DR status is tracked here : https://clang.llvm.org/cxx_dr_status.html

So it would be tracked there as CWG1632 and CWG1913.

From the looks of it, implementation will likely quickly get into a "thar be dragons" part of the compiler. We need to suppress instantiation of the body of dependent lambdas (the easy part), but getInstantiationArgs likely needs updating for it (which is a function that had some serious problems) to properly handle this and other cases.

This was followed by https://reviews.llvm.org/D138148 (open) & https://reviews.llvm.org/D137244 (merged). In the latter, @cor3ntin notes:

Either way, I think this makes support for P0588 complete, but we probably want to add a test for that in a separate PR.
(and I lack confidence I understand P0588 sufficiently to assert the completeness of our conformance).

Footnotes

1. It's obviously questionable to call this a "C++20 Feature", but I'm following the pattern of the other paper-tracking issues. ↩

2. curiously, GH search found nothing for "P0588", but did find something for "P0588R1" ↩

[llvmbot]

@llvm/issue-subscribers-clang-frontend

[llvmbot]

@llvm/issue-subscribers-c-20

[frederick-vs-ja]

1. It's obviously questionable to call this a "C++20 Feature", but I'm following the pattern of the other paper-tracking issues.

I think it'd be better to add a "C++ Defect report" category, and avoid mentioning the revision by default.

[h-vetinari]

and presumably should be tracked in https://clang.llvm.org/cxx_status.html (like other DRs that have a Pxxxx)

Actually, it is tracked, but under C++11 (which the CTRL+F search didn't find because it's hidden behind a fold-out; would be better to sort this in reverse chronological order and avoid the foldout IMO).

It seems there's a lack of consistency (both here and on https://en.cppreference.com/w/cpp/compiler_support) in which standard a DR gets noted.

@frederick-vs-ja: I think it'd be better to add a "C++ Defect report" category, and avoid mentioning the revision by default.

The problem is that there's already Defect Report status page, but with thousands of such reports, it's not going to be used other than for very specific lookup. So it might be worth to have a separate "Defect report" category on the feature page after all, for those DRs that come with separate papers (resp. are listed on cppreference).