Update the `operator%` overload that accepts `CharUnits` to return
`CharUnits` to match the other `operator%`. This is more logical than
returning an `int64` and cleans up users that want to continue to do
math with the result.
Many users of this were explicitly comparing against 0. I considered
updating these to compare against `CharUnits::Zero` or even introducing
an `explicit operator bool()`, but they all feel clearer if we update
them to use the existing `isMultipleOf()` function instead.
This reintroduces `Type.h`, having earlier been renamed to `TypeBase.h`,
as a redirection to `TypeBase.h`, and redirects most users to include
the former instead.
This is a preparatory patch for being able to provide inline definitions
for `Type` methods which would otherwise cause a circular dependency
with `Decl{,CXX}.h`.
Doing these operations into their own NFC patch helps the git rename
detection logic work, preserving the history.
This patch makes clang just a little slower to build (~0.17%), just
because it makes more code indirectly include `DeclCXX.h`.
This is a preparatory patch, to be able to provide inline definitions
for `Type` functions which depend on `Decl{,CXX}.h`. As the latter also
depends on `Type.h`, this would not be possible without some
reorganizing.
Splitting this rename into its own patch allows git to track this as a
rename, and preserve all git history, and not force any code
reformatting.
A later NFC patch will reintroduce `Type.h` as redirection to
`TypeBase.h`, rewriting most places back to directly including `Type.h`
instead of `TypeBase.h`, leaving only a handful of places where this is
necessary.
Then yet a later patch will exploit this by making more stuff inline.
This is a major change on how we represent nested name qualifications in
the AST.
* The nested name specifier itself and how it's stored is changed. The
prefixes for types are handled within the type hierarchy, which makes
canonicalization for them super cheap, no memory allocation required.
Also translating a type into nested name specifier form becomes a no-op.
An identifier is stored as a DependentNameType. The nested name
specifier gains a lightweight handle class, to be used instead of
passing around pointers, which is similar to what is implemented for
TemplateName. There is still one free bit available, and this handle can
be used within a PointerUnion and PointerIntPair, which should keep
bit-packing aficionados happy.
* The ElaboratedType node is removed, all type nodes in which it could
previously apply to can now store the elaborated keyword and name
qualifier, tail allocating when present.
* TagTypes can now point to the exact declaration found when producing
these, as opposed to the previous situation of there only existing one
TagType per entity. This increases the amount of type sugar retained,
and can have several applications, for example in tracking module
ownership, and other tools which care about source file origins, such as
IWYU. These TagTypes are lazily allocated, in order to limit the
increase in AST size.
This patch offers a great performance benefit.
It greatly improves compilation time for
[stdexec](https://github.com/NVIDIA/stdexec). For one datapoint, for
`test_on2.cpp` in that project, which is the slowest compiling test,
this patch improves `-c` compilation time by about 7.2%, with the
`-fsyntax-only` improvement being at ~12%.
This has great results on compile-time-tracker as well:
This patch also further enables other optimziations in the future, and
will reduce the performance impact of template specialization resugaring
when that lands.
It has some other miscelaneous drive-by fixes.
About the review: Yes the patch is huge, sorry about that. Part of the
reason is that I started by the nested name specifier part, before the
ElaboratedType part, but that had a huge performance downside, as
ElaboratedType is a big performance hog. I didn't have the steam to go
back and change the patch after the fact.
There is also a lot of internal API changes, and it made sense to remove
ElaboratedType in one go, versus removing it from one type at a time, as
that would present much more churn to the users. Also, the nested name
specifier having a different API avoids missing changes related to how
prefixes work now, which could make existing code compile but not work.
How to review: The important changes are all in
`clang/include/clang/AST` and `clang/lib/AST`, with also important
changes in `clang/lib/Sema/TreeTransform.h`.
The rest and bulk of the changes are mostly consequences of the changes
in API.
PS: TagType::getDecl is renamed to `getOriginalDecl` in this patch, just
for easier to rebasing. I plan to rename it back after this lands.
Fixes#136624
Fixes https://github.com/llvm/llvm-project/issues/43179
Fixes https://github.com/llvm/llvm-project/issues/68670
Fixes https://github.com/llvm/llvm-project/issues/92757
APValue::ConstexprUnknown() constructs a broken LValue that doesn't have
an lvalue path, which confuses later error handling. It turns out we
don't actually use the result of createConstexprUnknownAPValues for
anything, so just stop using it. Just construct the LValue directly when
we need it.
Make findCompleteObject emit errors more aggressively; allowing it to
succeed for constexpr-unknown objects leads to weird states where it
succeeds, but doesn't return a well-formed object.
Delete the check for constexpr-unknown in dynamic_cast handling: it's
not necessary, and breaks with the other changes in this patch.
These changes allow us to produce proper diagnostics when something
fails to be evaluated, instead of just printing a generic top-level
error without any notes.
This reverts commit 7a6435bec59010e4bb2e1e52a9ba840ed152b4ce.
This causes ubsan failures when the sentinel pointers are upcast
using static_cast<>, which checks alignment.
DenseMapInfo for pointers currently uses empty/tombstone values that are
aligned (by assuming a very conservative alignment). However, this means
that we have to work with larger immediates.
This patch proposes to use the values -1 and -2 instead, without caring
about pointer alignment. (Non-roundtrip) integer to pointer casts are
implementation-defined in C++, but the general implementer consensus
(including Clang) is that raw pointers do not carry alignment
requirements, only memory accesses do.
We already have lots of places that rely on this using variations on
`reinterpret_cast<T*>(-1)`, so it seems odd to insist on properly
aligned pointers in this one place.
It is necessary to adjust a few other places after this change, which
currently assume that `DenseMapInfo<void *>` returns a highly-aligned
pointer.
This is a small improvement for both compile-time and clang binary size.
APValue:
Additional assignment of AllowConstexprUnknown is not required since it
will be handled by copy constructor called above.
SemaInit:
Remove unnecessary null check. DestRecordDecl can't be null due to being
obtained using `cast` and assertion that DestRecordType is present.
Spotted by a static analysis tool.
P2280R4 allows the use of references in pointers of unknown origins in a
constant expression context but only in specific cases that could be
constant expressions.
We track whether a variable is a constexpr unknown in a constant
expression by setting a flag in either APValue or LValue and using this
flag to prevent using unknown values in places where it is not allowed.
Fixes: https://github.com/llvm/llvm-project/issues/63139https://github.com/llvm/llvm-project/issues/63117
* Don't call raw_string_ostream::flush(), which is essentially a no-op.
* Strip unneeded calls to raw_string_ostream::str(), to avoid extra indirection.
When printing an `_Atomic(some struct type)`, we would later run into an
assertion because we do a `Ty->castAs<RecordType>()`, which doesn't work
with an `AtomicType`.
This patch introduces a new enumerator `Invalid = 0`, shifting other enumerators by +1. Contrary to how it might sound, this actually affirms status quo of how this enum is stored in `clang::Decl`:
```
/// If 0, we have not computed the linkage of this declaration.
/// Otherwise, it is the linkage + 1.
mutable unsigned CacheValidAndLinkage : 3;
```
This patch makes debuggers to not be mistaken about enumerator stored in this bit-field. It also converts `clang::Linkage` to a scoped enum.
LValuePathSerializationHelper's type properly
Close https://github.com/llvm/llvm-project/issues/58716.
Tested with libcxx's modules build.
When we read the type of
LValuePathSerializationHelper, we didn't read the correct type. We read
the element type as its name suggests. But the problem here is that it
looks like that both the usage and serialization use its type as the
top level type. So here is the mismatch.
Actually, the type of LValuePathSerializationHelper is never used after
Deserialization without the assertion. So it doesn't matter for the
release users. And this patch shouldn't change the behavior too.
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D139406
C++20 non-type template parameter prints `MyType<{{116, 104, 105, 115}}>` when the code is as simple as `MyType<"this">`. This patch prints `MyType<{"this"}>`, with one layer of braces preserved for the intermediate structural type to trigger CTAD.
`StringLiteral` handles this case, but `StringLiteral` inside `APValue` code looks like a circular dependency. The proposed patch implements a cheap strategy to emit string literals in diagnostic messages only when they are readable and fall back to integer sequences.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D115031
The call to getTypeSizeInChars() is replaced with
getTypeSizeInCharsIfKnown(), which does not crash on forward declared
structs. This only affects printing.
Differential Revision: https://reviews.llvm.org/D113570
The implementation for (de)serialization of APValues can be shared
between Clang and Swift, so we prefer pushing the methods up
the inheritance hierarchy, instead of having the methods live in
ASTReader/ASTWriter. Fixes rdar://72592937.
Reviewed By: rjmccall
Differential Revision: https://reviews.llvm.org/D94196
Update all the users of `AlignedCharArrayUnion` to stop peeking inside
(to look at `buffer`) so that a follow-up patch can replace it with an
alias to `std::aligned_union_t`.
This was reviewed as part of https://reviews.llvm.org/D92512, but I'm
splitting this bit out to commit first to reduce churn in case the
change to `AlignedCharArrayUnion` needs to be reverted for some
unexpected reason.
mangling support for non-type template parameters of class type and
template parameter objects.
The Itanium side of this follows the approach I proposed in
https://github.com/itanium-cxx-abi/cxx-abi/issues/47 on 2020-09-06.
The MSVC side of this was determined empirically by observing MSVC's
output.
Differential Revision: https://reviews.llvm.org/D89998
Changes:
- initializer expressions of constexpr variable are now wraped in a ConstantExpr. this is mainly used for testing purposes. the old caching system has not yet been removed.
- Add all the missing Serialization and Importing for APValue.
- Improve dumping of APValue when ASTContext isn't available.
- Cleanup leftover from last patch.
- Add Tests for Import and serialization.
Differential Revision: https://reviews.llvm.org/D63640
Capitalize the profile function of APValue such that it can be used by FoldingSetNodeID
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D88643
References to different declarations of the same entity aren't different
values, so shouldn't have different representations.
Recommit of e6393ee813178e9d3306b8e3c6949a4f32f8a2cb, most recently
reverted in 9a33f027ac7d73e14ae287e78ab554142d1cbc8f due to a bug caused
by ObjCInterfaceDecls not propagating availability attributes along
their redeclaration chains; that bug was fixed in
e2d4174e9c66251d1b408234b53f53d0903c0285.
References to different declarations of the same entity aren't different
values, so shouldn't have different representations.
Recommit of e6393ee813178e9d3306b8e3c6949a4f32f8a2cb with fixed handling
for weak declarations. We now look for attributes on the most recent
declaration when determining whether a declaration is weak. (Second
recommit with further fixes for mishandling of weak declarations. Our
behavior here is fundamentally unsound -- see PR47663 -- but this
approach attempts to not make things worse.)
References to different declarations of the same entity aren't different
values, so shouldn't have different representations.
Recommit of e6393ee813178e9d3306b8e3c6949a4f32f8a2cb with fixed
handling for weak declarations. We now look for attributes on the most
recent declaration when determining whether a declaration is weak.
No functionality change intended: there doesn't seem to be any way to
cause Clang to print such a value, but they can show up when dumping
APValues from a debugger.
