History log of /llvm-project/clang/test/SemaCXX/lambda-expressions.cpp (Results 1 – 25 of 93)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4
# 202ad47f 13-Nov-2024 Timm Baeder <tbaeder@redhat.com>

[clang][bytecode] SourceInfo::Source might be null (#115905)

This broke in 23fbaff9a3fd2b26418e0c2f10b701049399251f, but the old
.dyn_cast<> handled null.


Revision tags: llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init
# 51d87aa4 01-Jul-2024 CedricSWA <51178026+CedricSwa@users.noreply.github.com>

[Clang] Improve error message for lambda captures that name a class member (#94865)

This introduces are more helpful error message when trying to
explicitly capture a class member in a lambda.

[Clang] Improve error message for lambda captures that name a class member (#94865)

This introduces are more helpful error message when trying to
explicitly capture a class member in a lambda.

Fixes #94764.

show more ...


Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4
# b502dc59 12-Apr-2024 Sirraide <aeternalmail@gmail.com>

[Clang] Fix test broken due to unsupported calling convention (#88472)

#88428 ended up breaking CI because it included a test that uses the
`regcall` calling convention, which isn’t supported on al

[Clang] Fix test broken due to unsupported calling convention (#88472)

#88428 ended up breaking CI because it included a test that uses the
`regcall` calling convention, which isn’t supported on all targets; I’ve
moved it into a separate file that sets the triple.

show more ...


# 505a9ae8 12-Apr-2024 Sirraide <aeternalmail@gmail.com>

[Clang] Look through type sugar when accessing FunctionProtoType (#88428)

This fixes a bug introduced by #84473: if a lambda’s type is type sugar
(e.g. an `AttributedType`), we need to use `getAs()

[Clang] Look through type sugar when accessing FunctionProtoType (#88428)

This fixes a bug introduced by #84473: if a lambda’s type is type sugar
(e.g. an `AttributedType`), we need to use `getAs()` instead of `cast()`
to retrieve the `FunctionProtoType`.

show more ...


Revision tags: llvmorg-18.1.3
# 2699072b 21-Mar-2024 Nikolas Klauser <nikolasklauser@berlin.de>

[clang] Accept lambdas in C++03 as an extensions (#73376)

Implements
https://discourse.llvm.org/t/rfc-allow-c-11-lambdas-in-c-03-as-an-extension/75262


Revision tags: llvmorg-18.1.2
# 367f355f 16-Mar-2024 Nikolas Klauser <nikolasklauser@berlin.de>

Reapply "[clang] Fix crash when declaring invalid lambda member" (#85427)

This re-applies #74110 with the crashing code disabled in C++11. I'll
try to fix the new crash in it's own patch.


# def038bc 09-Mar-2024 Vitaly Buka <vitalybuka@google.com>

Revert "[clang] Fix crash when declaring invalid lambda member" (#84615)

Reverts llvm/llvm-project#74110

Fails on many bots:
https://lab.llvm.org/buildbot/#/builders/5/builds/41633


# dc567a2e 09-Mar-2024 Nikolas Klauser <nikolasklauser@berlin.de>

[clang] Fix crash when declaring invalid lambda member (#74110)

In valid code, there should only be a very specific set of members in a
lambda definition. If the user tries to define something insi

[clang] Fix crash when declaring invalid lambda member (#74110)

In valid code, there should only be a very specific set of members in a
lambda definition. If the user tries to define something inside the
lambda class, this assumption is violated and causes an assertion error.
This can be fixed by checking whether the members are valid, and if not,
ignore that the class members are potentially unexpected.

I've come across this while working on implementing lambdas in C++03.

show more ...


# dd36138e 08-Mar-2024 Mariya Podchishchaeva <mariya.podchishchaeva@intel.com>

[clang] Error on explicit specialization of lambda call operator (#84343)

Fixes https://github.com/llvm/llvm-project/issues/83267


Revision tags: llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init
# 3eeed799 05-Jan-2024 Younan Zhang <zyn7109@gmail.com>

[clang] Correctly implement CWG 2672 (#75001)


Revision tags: llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4
# b1b9cd4e 27-Oct-2023 Congcong Cai <congcongcai0907@163.com>

[clang]set invalid for lambda which missing capture `this` (#70432)

It can suppression further crash.
Fixes: #67687


# 84a3aadf 20-Oct-2023 Aaron Ballman <aaron@aaronballman.com>

Diagnose use of VLAs in C++ by default

Reapplication of 7339c0f782d5c70e0928f8991b0c05338a90c84c with a fix
for a crash involving arrays without a size expression.

Clang supports VLAs in C++ as an

Diagnose use of VLAs in C++ by default

Reapplication of 7339c0f782d5c70e0928f8991b0c05338a90c84c with a fix
for a crash involving arrays without a size expression.

Clang supports VLAs in C++ as an extension, but we currently only warn
on their use when you pass -Wvla, -Wvla-extension, or -pedantic.
However, VLAs as they're expressed in C have been considered by WG21
and rejected, are easy to use accidentally to the surprise of users
(e.g., https://ddanilov.me/default-non-standard-features/), and they
have potential security implications beyond constant-size arrays
(https://wiki.sei.cmu.edu/confluence/display/c/ARR32-C.+Ensure+size+arguments+for+variable+length+arrays+are+in+a+valid+range).
C++ users should strongly consider using other functionality such as
std::vector instead.

This seems like sufficiently compelling evidence to warn users about
VLA use by default in C++ modes. This patch enables the -Wvla-extension
diagnostic group in C++ language modes by default, and adds the warning
group to -Wall in GNU++ language modes. The warning is still opt-in in
C language modes, where support for VLAs is somewhat less surprising to
users.

RFC: https://discourse.llvm.org/t/rfc-diagnosing-use-of-vlas-in-c/73109
Fixes https://github.com/llvm/llvm-project/issues/62836
Differential Revision: https://reviews.llvm.org/D156565

show more ...


# f5043f46 20-Oct-2023 Aaron Ballman <aaron@aaronballman.com>

Revert "Diagnose use of VLAs in C++ by default"

This reverts commit 7339c0f782d5c70e0928f8991b0c05338a90c84c.

Breaks bots:
https://lab.llvm.org/buildbot/#/builders/139/builds/51875
https://lab.llvm

Revert "Diagnose use of VLAs in C++ by default"

This reverts commit 7339c0f782d5c70e0928f8991b0c05338a90c84c.

Breaks bots:
https://lab.llvm.org/buildbot/#/builders/139/builds/51875
https://lab.llvm.org/buildbot/#/builders/164/builds/45262

show more ...


# 7339c0f7 20-Oct-2023 Aaron Ballman <aaron@aaronballman.com>

Diagnose use of VLAs in C++ by default

Clang supports VLAs in C++ as an extension, but we currently only warn
on their use when you pass -Wvla, -Wvla-extension, or -pedantic.
However, VLAs as they'r

Diagnose use of VLAs in C++ by default

Clang supports VLAs in C++ as an extension, but we currently only warn
on their use when you pass -Wvla, -Wvla-extension, or -pedantic.
However, VLAs as they're expressed in C have been considered by WG21
and rejected, are easy to use accidentally to the surprise of users
(e.g., https://ddanilov.me/default-non-standard-features/), and they
have potential security implications beyond constant-size arrays
(https://wiki.sei.cmu.edu/confluence/display/c/ARR32-C.+Ensure+size+arguments+for+variable+length+arrays+are+in+a+valid+range).
C++ users should strongly consider using other functionality such as
std::vector instead.

This seems like sufficiently compelling evidence to warn users about
VLA use by default in C++ modes. This patch enables the -Wvla-extension
diagnostic group in C++ language modes by default, and adds the warning
group to -Wall in GNU++ language modes. The warning is still opt-in in
C language modes, where support for VLAs is somewhat less surprising to
users.

RFC: https://discourse.llvm.org/t/rfc-diagnosing-use-of-vlas-in-c/73109
Fixes https://github.com/llvm/llvm-project/issues/62836
Differential Revision: https://reviews.llvm.org/D156565

show more ...


Revision tags: llvmorg-17.0.3, llvmorg-17.0.2
# 64ffe64d 28-Sep-2023 cor3ntin <corentinjabot@gmail.com>

[Clang] Handle sema of noexcept condition in their evaluation context. (#67538)

The conditions of a noexcept and explicit specifier are full
expressions. Before this patch, we would call ActOnFinis

[Clang] Handle sema of noexcept condition in their evaluation context. (#67538)

The conditions of a noexcept and explicit specifier are full
expressions. Before this patch, we would call ActOnFinishFullExpr on
these in the context of the enclosing expression, which would cause the
collect of odr-used variables (and subsequently capture attempts) in the
wrong (enclosing) context.

This was observable when parsing the noexcept specifier condition of a
lambda appearing in a wider full expression odr-using variables.

Fixes #67492

show more ...


Revision tags: llvmorg-17.0.1
# c724ac93 19-Sep-2023 Piotr Fusik <piotr@fusion-lang.org>

[clang] Fix null dereference on return in lambda attribute statement expr (#66643)

clang was crashing on a lambda attribute with a statement expression
that contained a `return`.
It attempted to a

[clang] Fix null dereference on return in lambda attribute statement expr (#66643)

clang was crashing on a lambda attribute with a statement expression
that contained a `return`.
It attempted to access the lambda type which was unknown at that point.

Fixes https://github.com/llvm/llvm-project/issues/48527

show more ...


Revision tags: llvmorg-17.0.0, llvmorg-17.0.0-rc4
# 0f1c1be1 28-Aug-2023 Aaron Ballman <aaron@aaronballman.com>

[clang] Remove rdar links; NFC

We have a new policy in place making links to private resources
something we try to avoid in source and test files. Normally, we'd
organically switch to the new policy

[clang] Remove rdar links; NFC

We have a new policy in place making links to private resources
something we try to avoid in source and test files. Normally, we'd
organically switch to the new policy rather than make a sweeping change
across a project. However, Clang is in a somewhat special circumstance
currently: recently, I've had several new contributors run into rdar
links around test code which their patch was changing the behavior of.
This turns out to be a surprisingly bad experience, especially for
newer folks, for a handful of reasons: not understanding what the link
is and feeling intimidated by it, wondering whether their changes are
actually breaking something important to a downstream in some way,
having to hunt down strangers not involved with the patch to impose on
them for help, accidental pressure from asking for potentially private
IP to be made public, etc. Because folks run into these links entirely
by chance (through fixing bugs or working on new features), there's not
really a set of problematic links to focus on -- all of the links have
basically the same potential for causing these problems. As a result,
this is an omnibus patch to remove all such links.

This was not a mechanical change; it was done by manually searching for
rdar, radar, radr, and other variants to find all the various
problematic links. From there, I tried to retain or reword the
surrounding comments so that we would lose as little context as
possible. However, because most links were just a plain link with no
supporting context, the majority of the changes are simple removals.

Differential Review: https://reviews.llvm.org/D158071

show more ...


Revision tags: llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init
# e0ac46e6 17-Jul-2023 Mehdi Amini <joker.eph@gmail.com>

Revert "Remove rdar links; NFC"

This reverts commit d618f1c3b12effd0c2bdb7d02108d3551f389d3d.
This commit wasn't reviewed ahead of time and significant concerns were
raised immediately after it land

Revert "Remove rdar links; NFC"

This reverts commit d618f1c3b12effd0c2bdb7d02108d3551f389d3d.
This commit wasn't reviewed ahead of time and significant concerns were
raised immediately after it landed. According to our developer policy
this warrants immediate revert of the commit.

https://llvm.org/docs/DeveloperPolicy.html#patch-reversion-policy

Differential Revision: https://reviews.llvm.org/D155509

show more ...


# d618f1c3 07-Jul-2023 Aaron Ballman <aaron@aaronballman.com>

Remove rdar links; NFC

This removes links to rdar, which is an internal bug tracker that the
community doesn't have visibility into.

See further discussion at:
https://discourse.llvm.org/t/code-rev

Remove rdar links; NFC

This removes links to rdar, which is an internal bug tracker that the
community doesn't have visibility into.

See further discussion at:
https://discourse.llvm.org/t/code-review-reminder-about-links-in-code-commit-messages/71847

show more ...


Revision tags: llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4
# 629170fe 09-May-2023 Ilya Biryukov <ibiryukov@google.com>

[Sema] Lambdas are not part of immediate context for deduction

This commit implements [temp.deduct]p9.
Test updates include:
- New notes in `cxx1y-init-captures.cpp`, `lambda-expressions.cpp`
and

[Sema] Lambdas are not part of immediate context for deduction

This commit implements [temp.deduct]p9.
Test updates include:
- New notes in `cxx1y-init-captures.cpp`, `lambda-expressions.cpp`
and 'warn-unused-lambda-capture.cpp'.
This seems to be caused by diagnosing errors earlier (during
deduction) that were previously surfaced later (during
instantiation).
- New error `lambda-unevaluated.cpp` is in line with [temp.deduct]p9.

Reviewed By: erichkeane, #clang-language-wg

Differential Revision: https://reviews.llvm.org/D148802

show more ...


Revision tags: llvmorg-16.0.3
# ba15d186 30-Apr-2023 Mark de Wever <koraq@xs4all.nl>

[clang] Use -std=c++23 instead of -std=c++2b

During the ISO C++ Committee meeting plenary session the C++23 Standard
has been voted as technical complete.

This updates the reference to c++2b to c++

[clang] Use -std=c++23 instead of -std=c++2b

During the ISO C++ Committee meeting plenary session the C++23 Standard
has been voted as technical complete.

This updates the reference to c++2b to c++23 and updates the __cplusplus
macro.

Drive-by fixes c++1z -> c++17 and c++2a -> c++20 when seen.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D149553

show more ...


Revision tags: llvmorg-16.0.2, llvmorg-16.0.1
# 82c83d7e 21-Mar-2023 Corentin Jabot <corentinjabot@gmail.com>

[Clang] Fix evaluation of parameters of lambda call operator attributes

Fix a regresion introduced by D124351.
Attributes of lambda call operator were evaluated in the
context of the closure object

[Clang] Fix evaluation of parameters of lambda call operator attributes

Fix a regresion introduced by D124351.
Attributes of lambda call operator were evaluated in the
context of the closure object type rather than its operator,
causing an assertion failure.

This was because we temporarily switch to the class lambda to
produce the mangling of the lambda, but we stayed in that
context too long.

Reviewed By: eandrews, aaron.ballman

Differential Revision: https://reviews.llvm.org/D146535

show more ...


Revision tags: llvmorg-16.0.0, llvmorg-16.0.0-rc4
# 2fbf18b4 06-Mar-2023 Mariya Podchishchaeva <mariya.podchishchaeva@intel.com>

[clang] Fix aggregate initialization inside lambda constexpr

Constant evaluator only considered access to `this` pointer to be
possible if `this` poitners was captured. However `this` can also appea

[clang] Fix aggregate initialization inside lambda constexpr

Constant evaluator only considered access to `this` pointer to be
possible if `this` poitners was captured. However `this` can also appear if
there was a default member initializer.

Fixes https://github.com/llvm/llvm-project/issues/60936

Reviewed By: shafik

Differential Revision: https://reviews.llvm.org/D144866

show more ...


Revision tags: llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1
# 93d7002d 06-Feb-2022 Corentin Jabot <corentinjabot@gmail.com>

[Clang] Implement Change scope of lambda trailing-return-type

This implements P2036R3 and P2579R0.
That is, explicit, int, and implicit capture become visible
at the start of the parameter head.

Re

[Clang] Implement Change scope of lambda trailing-return-type

This implements P2036R3 and P2579R0.
That is, explicit, int, and implicit capture become visible
at the start of the parameter head.

Reviewed By: aaron.ballman, rupprecht, shafik

Differential Revision: https://reviews.llvm.org/D124351

show more ...


# 19e984ef 14-Oct-2022 Aaron Ballman <aaron@aaronballman.com>

Properly print unnamed TagDecl objects in diagnostics

The diagnostics engine is very smart about being passed a NamedDecl to
print as part of a diagnostic; it gets the "right" form of the name,
quot

Properly print unnamed TagDecl objects in diagnostics

The diagnostics engine is very smart about being passed a NamedDecl to
print as part of a diagnostic; it gets the "right" form of the name,
quotes it properly, etc. However, the result of using an unnamed tag
declaration was to print '' instead of anything useful.

This patch causes us to print the same information we'd have gotten if
we had printed the type of the declaration rather than the name of it,
as that's the most relevant information we can display.

Differential Revision: https://reviews.llvm.org/D134813

show more ...


1234