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 ...
|