History log of /llvm-project-15.0.7/clang/test/AST/ast-dump-constant-expr.cpp (Results 1 – 6 of 6)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
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, 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
# 7a8c7946 18-Oct-2021 Nathan Ridge <[email protected]>

[clang] Allocate 2 bits to store the constexpr specifier kind when serializing

Now that consteval and constinit are possible values, 1 bit
is no longer enough.

Fixes https://github.com/clangd/clang

[clang] Allocate 2 bits to store the constexpr specifier kind when serializing

Now that consteval and constinit are possible values, 1 bit
is no longer enough.

Fixes https://github.com/clangd/clangd/issues/887

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

show more ...


Revision tags: 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, 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, 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
# f63e3ea5 06-Jul-2020 Bruno Ricci <[email protected]>

[clang] Rework how and when APValues are dumped

Currently APValues are dumped as a single string. This becomes quickly
completely unreadable since APValue is a tree-like structure. Even a simple
exa

[clang] Rework how and when APValues are dumped

Currently APValues are dumped as a single string. This becomes quickly
completely unreadable since APValue is a tree-like structure. Even a simple
example is not pretty:

struct S { int arr[4]; float f; };
constexpr S s = { .arr = {1,2}, .f = 3.1415f };
// Struct fields: Array: Int: 1, Int: 2, 2 x Int: 0, Float: 3.141500e+00

With this patch this becomes:

-Struct
|-field: Array size=4
| |-elements: Int 1, Int 2
| `-filler: 2 x Int 0
`-field: Float 3.141500e+00

Additionally APValues are currently only dumped as part of visiting a
ConstantExpr. This patch also dump the value of the initializer of constexpr
variable declarations:

constexpr int foo(int a, int b) { return a + b - 42; }
constexpr int a = 1, b = 2;
constexpr int c = foo(a, b) > 0 ? foo(a, b) : foo(b, a);
// VarDecl 0x62100008aec8 <col:3, col:57> col:17 c 'const int' constexpr cinit
// |-value: Int -39
// `-ConditionalOperator 0x62100008b4d0 <col:21, col:57> 'int'
// <snip>

Do the above by moving the dump functions to TextNodeDumper which already has
the machinery to display trees. The cases APValue::LValue, APValue::MemberPointer
and APValue::AddrLabelDiff are left as they were before (unimplemented).

We try to display multiple elements on the same line if they are considered to
be "simple". This is to avoid wasting large amounts of vertical space in an
example like:

constexpr int arr[8] = {0,1,2,3,4,5,6,7};
// VarDecl 0x62100008bb78 <col:3, col:42> col:17 arr 'int const[8]' constexpr cinit
// |-value: Array size=8
// | |-elements: Int 0, Int 1, Int 2, Int 3
// | `-elements: Int 4, Int 5, Int 6, Int 7

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

Reviewed By: aaron.ballman

show more ...


Revision tags: llvmorg-10.0.1-rc2
# e7ce0528 21-Jun-2020 Bruno Ricci <[email protected]>

[clang][Serialization] Fix the serialization of ConstantExpr.

The serialization of ConstantExpr has currently a number of problems:

- Some fields are just not serialized (ConstantExprBits.APValueKi

[clang][Serialization] Fix the serialization of ConstantExpr.

The serialization of ConstantExpr has currently a number of problems:

- Some fields are just not serialized (ConstantExprBits.APValueKind and
ConstantExprBits.IsImmediateInvocation).

- ASTStmtReader::VisitConstantExpr forgets to add the trailing APValue
to the list of objects to be destroyed when the APValue needs cleanup.

While we are at it, bring the serialization of ConstantExpr more in-line
with what is done with the other expressions by doing the following NFCs:

- Get rid of ConstantExpr::DefaultInit. It is better to not initialize
the fields of an empty ConstantExpr since this will allow msan to
detect if a field was not deserialized.

- Move the initialization of the fields of ConstantExpr to the constructor;
ConstantExpr::Create allocates the memory and ConstantExpr::ConstantExpr
is responsible for the initialization.

Review after commit since this is a straightforward mechanical fix
similar to the other serialization fixes.

show more ...