|
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, 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, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, 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, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, 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, 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 |
|
| #
97af17c5 |
| 03-Jul-2022 |
Iain Sandoe <[email protected]> |
re-land [C++20][Modules] Update handling of implicit inlines [P1779R3]
re-land fixes an unwanted interaction with module-map modules, seen in Greendragon testing.
This provides updates to [class.mf
re-land [C++20][Modules] Update handling of implicit inlines [P1779R3]
re-land fixes an unwanted interaction with module-map modules, seen in Greendragon testing.
This provides updates to [class.mfct]: Pre C++20 [class.mfct]p2: A member function may be defined (8.4) in its class definition, in which case it is an inline member function (7.1.2) Post C++20 [class.mfct]p1: If a member function is attached to the global module and is defined in its class definition, it is inline.
and [class.friend]: Pre-C++20 [class.friend]p5 A function can be defined in a friend declaration of a class . . . . Such a function is implicitly inline. Post C++20 [class.friend]p7 Such a function is implicitly an inline function if it is attached to the global module.
We add the output of implicit-inline to the TextNodeDumper, and amend a couple of existing tests to account for this, plus add tests for the cases covered above.
Differential Revision: https://reviews.llvm.org/D129045
show more ...
|
| #
c7fd7512 |
| 11-Jul-2022 |
Jonas Devlieghere <[email protected]> |
Revert "[C++20][Modules] Update handling of implicit inlines [P1779R3]"
This reverts commit ef0fa9f0ef3e as a follow up to b19d3ee7120b which reverted commit ac507102d258. See https://reviews.llvm.o
Revert "[C++20][Modules] Update handling of implicit inlines [P1779R3]"
This reverts commit ef0fa9f0ef3e as a follow up to b19d3ee7120b which reverted commit ac507102d258. See https://reviews.llvm.org/D126189 for more details.
show more ...
|
| #
ef0fa9f0 |
| 03-Jul-2022 |
Iain Sandoe <[email protected]> |
[C++20][Modules] Update handling of implicit inlines [P1779R3]
This provides updates to [class.mfct]: Pre C++20 [class.mfct]p2: A member function may be defined (8.4) in its class definition, in
[C++20][Modules] Update handling of implicit inlines [P1779R3]
This provides updates to [class.mfct]: Pre C++20 [class.mfct]p2: A member function may be defined (8.4) in its class definition, in which case it is an inline member function (7.1.2) Post C++20 [class.mfct]p1: If a member function is attached to the global module and is defined in its class definition, it is inline.
and [class.friend]: Pre-C++20 [class.friend]p5 A function can be defined in a friend declaration of a class . . . . Such a function is implicitly inline. Post C++20 [class.friend]p7 Such a function is implicitly an inline function if it is attached to the global module.
We add the output of implicit-inline to the TextNodeDumper, and amend a couple of existing tests to account for this, plus add tests for the cases covered above.
Differential Revision: https://reviews.llvm.org/D129045
show more ...
|
|
Revision tags: 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 |
|
| #
5029dce4 |
| 14-Feb-2022 |
Aaron Ballman <[email protected]> |
Implement WG14 N2764 the [[noreturn]] attribute
This adds support for http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2764.pdf, which was adopted at the Feb 2022 WG14 meeting. That paper adds [[nor
Implement WG14 N2764 the [[noreturn]] attribute
This adds support for http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2764.pdf, which was adopted at the Feb 2022 WG14 meeting. That paper adds [[noreturn]] and [[_Noreturn]] to the list of supported attributes in C2x. These attributes have the same semantics as the [[noreturn]] attribute in C++.
The [[_Noreturn]] attribute was added as a deprecated feature so that translation units which include <stdnoreturn.h> do not get an error on use of [[noreturn]] because the macro expands to _Noreturn. Users can use -Wno-deprecated-attributes to silence the diagnostic.
Use of <stdnotreturn.h> or the noreturn macro were both deprecated. Users can define the _CLANG_DISABLE_CRT_DEPRECATION_WARNINGS macro to suppress the deprecation diagnostics coming from the header file.
show more ...
|
|
Revision tags: llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3 |
|
| #
b2bc0a32 |
| 03-Mar-2021 |
Aaron Ballman <[email protected]> |
Implement P2173 for attributes on lambdas
https://wg21.link/P2173 is making its way through WG21 currently and has not been formally adopted yet. This feature provides very useful functionality in t
Implement P2173 for attributes on lambdas
https://wg21.link/P2173 is making its way through WG21 currently and has not been formally adopted yet. This feature provides very useful functionality in that you can specify attributes on the various function *declarations* generated by a lambda expression, where the current C++ grammar only allows attributes which apply to the various function *types* so generated.
This patch implements P2173 on the assumption that it will be adopted by WG21 with this syntax for C++23.
show more ...
|
|
Revision tags: llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3 |
|
| #
23f700c7 |
| 07-Sep-2020 |
Raphael Isemann <[email protected]> |
Revert "[clang] Prevent that Decl::dump on a CXXRecordDecl deserialises further declarations."
This reverts commit 0478720157f6413fad7595b8eff9c70d2d99b637. This probably doesn't work when forcing d
Revert "[clang] Prevent that Decl::dump on a CXXRecordDecl deserialises further declarations."
This reverts commit 0478720157f6413fad7595b8eff9c70d2d99b637. This probably doesn't work when forcing deserialising while dumping (which the ASTDumper optionally supports).
show more ...
|
| #
04787201 |
| 07-Sep-2020 |
Raphael Isemann <[email protected]> |
[clang] Prevent that Decl::dump on a CXXRecordDecl deserialises further declarations.
Decl::dump is primarily used for debugging to visualise the current state of a declaration. Usually Decl::dump j
[clang] Prevent that Decl::dump on a CXXRecordDecl deserialises further declarations.
Decl::dump is primarily used for debugging to visualise the current state of a declaration. Usually Decl::dump just displays the current state of the Decl and doesn't actually change any of its state, however since commit 457226e02a6e8533eaaa864a3fd7c8eeccd2bf58 the method actually started loading additional declarations from the ExternalASTSource. This causes that calling Decl::dump during a debugging session now actually does permanent changes to the AST and will cause the debugged program run to deviate from the original run.
The change that caused this behaviour is the addition of `hasConstexprDestructor` (which is called from the TextNodeDumper) which performs a lookup into the current CXXRecordDecl to find the destructor. All other similar methods just return their respective bit in the DefinitionData (which obviously doesn't have such side effects).
This just changes the node printer to emit "unknown_constexpr" in case a CXXRecordDecl is dumped that could potentially call into the ExternalASTSource instead of the usually empty string/"constexpr". For CXXRecordDecls that can safely be dumped the old behaviour is preserved
Reviewed By: bruno
Differential Revision: https://reviews.llvm.org/D80878
show more ...
|
|
Revision tags: llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3 |
|
| #
c10295e1 |
| 03-Jul-2020 |
Bruno Ricci <[email protected]> |
[clang][NFC] Add a missing /dev/null in test/AST/ast-dump-lambda.cpp
|
|
Revision tags: llvmorg-10.0.1-rc2 |
|
| #
e560280c |
| 21-Jun-2020 |
Bruno Ricci <[email protected]> |
[clang][NFC] Regenerate test/AST/ast-dump-lambda.cpp with --match-full-lines.
|
| #
6f9fe31c |
| 19-Jun-2020 |
Richard Smith <[email protected]> |
More test cleanup for c36b03e32556a966e584386ac7dbb110bc7e4bc5.
|
| #
05843dc6 |
| 18-Jun-2020 |
Bruno Ricci <[email protected]> |
[clang] Fix the serialization of LambdaExpr and the bogus mutation in LambdaExpr::getBody
The body of LambdaExpr is currently not properly serialized. Instead LambdaExpr::getBody checks if the body
[clang] Fix the serialization of LambdaExpr and the bogus mutation in LambdaExpr::getBody
The body of LambdaExpr is currently not properly serialized. Instead LambdaExpr::getBody checks if the body has been already deserialized and if not mutates LambdaExpr. This can be observed with an AST dump test, where the body of the LambdaExpr will be null.
The mutation in LambdaExpr::getBody was left because of another bug: it is not true that the body of a LambdaExpr is always a CompoundStmt; it can also be a CoroutineBodyStmt wrapping a CompoundStmt. This is fixed by returning a Stmt * from getBody and introducing a convenience function getCompoundStmtBody which always returns a CompoundStmt *. This function can be used by callers who do not care about the coroutine node.
Happily all but one user of getBody treat it as a Stmt * and so this change is non-intrusive.
Differential Revision: https://reviews.llvm.org/D81787
Reviewed By: aaron.ballman
show more ...
|
| #
6a79f5aa |
| 13-Jun-2020 |
Bruno Ricci <[email protected]> |
[clang][NFC] Add an AST dump test for LambdaExpr
This test illustrate the bug fixed in D81787.
|