In PR #79382, I need to add a new type that derives from
ConstantArrayType. This means that ConstantArrayType can no longer use
`llvm::TrailingObjects` to store the trailing optional Expr*.
This change refactors ConstantArrayType to store a 60-bit integer and
4-bits for the integer size in bytes. This replaces the APInt field
previously in the type but preserves enough information to recreate it
where needed.
To reduce the number of places where the APInt is re-constructed I've
also added some helper methods to the ConstantArrayType to allow some
common use cases that operate on either the stored small integer or the
APInt as appropriate.
Resolves#85124.
Consider the following code:
```c
bool const inf = (1.0/0.0);
```
When trying to emit the initialiser of this variable in C23, we end up
hitting a code path in codegen in `VarDecl::evaluateValueImpl()` where
we check for `IsConstantInitialization && (Ctx.getLangOpts().CPlusPlus
|| Ctx.getLangOpts().C23)`, and if that is the case and we emitted any
notes, constant evaluation fails, and as a result, codegen issues this
error:
```
<source>:1:12: error: cannot compile this static initializer yet
1 | bool const inf = (1.0/0.0);
|
```
As a fix, only fail in C23 mode if we’re initialising a `constexpr`
variable.
This fixes#84784.
Previously we disabled to compute ODR hash for declarations from the
global module fragment. However, we missed the case that the functions
lives in the concept requiments (see the attached the test files for
example). And the mismatch causes the potential crashment.
Due to we will set the function body as lazy after we deserialize it and
we will only take its body when needed. However, we don't allow to take
the body during deserializing. So it is actually potentially problematic
if we set the body as lazy first and computing the hash value of the
function, which requires to deserialize its body. So we will meet a
crash here.
This patch tries to solve the issue by not taking the body of the
function from GMF. Note that we can't skip comparing the constraint
expression from the GMF directly since it is an key part of the
function selecting and it may be the reason why we can't return 0
directly for `FunctionDecl::getODRHash()` from the GMF.
Make TopLevelStmtDecl a DeclContext so that variables defined in statements
are attached to the TopLevelDeclContext. This fixes redefinition errors
from variables declared in if conditions and for-init statements. These
must be local to the inner context (C++ 3.3.2p4), but they had generated
definitions on global scope instead.
This PR makes the TopLevelStmtDecl looking more like a FunctionDecl and
that's fine because the FunctionDecl is very close in terms of semantics.
Additionally, ActOnForStmt() requires a CompoundScope when processing a
NullStmt body.
---------
Co-authored-by: Vassil Vassilev <v.g.vassilev@gmail.com>
The implementation mostly reuses C++ code paths where possible,
including narrowing check in order to provide diagnostic messages in
case initializer for constexpr variable is not exactly representable in
target type.
The following won't work due to lack of support for other features:
- Diagnosing of underspecified declarations involving constexpr
- Constexpr attached to compound literals
Also due to lack of support for char8_t some of examples with utf-8
strings don't work properly.
Fixes https://github.com/llvm/llvm-project/issues/64742
The spurious -Wunused-function warning issue for `target_version` #80227
also applied to `__attribute__((target(...)))` based FMV. #81167 removed
warnings for all `target`-based FMV. This patch restores the warnings
for `__attribute__((target("default")))`.
Previously committed as 9e08e51a20, and
reverted because a dependency commit was reverted, then committed again
as 4b574008ae and reverted again because
"dependency commit" 5a391d38ac was
reverted. But it doesn't seem that 5a391d38ac was a real dependency
for this.
This commit incorporates 4b574008ae and
18e093faf7 by Richard Smith (@zygoloid),
with some minor fixes, most notably:
- `UncommonValue` renamed to `StructuralValue`
- `VK_PRValue` instead of `VK_RValue` as default kind in lvalue and
member pointer handling branch in
`BuildExpressionFromNonTypeTemplateArgumentValue`;
- handling of `StructuralValue` in `IsTypeDeclaredInsideVisitor`;
- filling in `SugaredConverted` along with `CanonicalConverted`
parameter in `Sema::CheckTemplateArgument`;
- minor cleanup in
`TemplateInstantiator::transformNonTypeTemplateParmRef`;
- `TemplateArgument` constructors refactored;
- `ODRHash` calculation for `UncommonValue`;
- USR generation for `UncommonValue`;
- more correct MS compatibility mangling algorithm (tested on MSVC ver.
19.35; toolset ver. 143);
- IR emitting fixed on using a subobject as a template argument when the
corresponding template parameter is used in an lvalue context;
- `noundef` attribute and opaque pointers in `template-arguments` test;
- analysis for C++17 mode is turned off for templates in
`warn-bool-conversion` test; in C++17 and C++20 mode, array reference
used as a template argument of pointer type produces template argument
of UncommonValue type, and
`BuildExpressionFromNonTypeTemplateArgumentValue` makes
`OpaqueValueExpr` for it, and `DiagnoseAlwaysNonNullPointer` cannot see
through it; despite of "These cases should not warn" comment, I'm not
sure about correct behavior; I'd expect a suggestion to replace `if` by
`if constexpr`;
- `temp.arg.nontype/p1.cpp` and `dr18xx.cpp` tests fixed.
With lldb build fix.
Original message:
EnumConstantDecl is allocated by the ASTContext allocator so the
destructor is never called.
This patch takes a similar approach to IntegerLiteral by using
APIntStorage to allocate large APSInts using the ASTContext allocator as
well.
The downside is that an additional heap allocation and copy of the data
needs to be made when calling getInitValue if the APSInt is large.
Fixes#78160.
EnumConstantDecl is allocated by the ASTContext allocator so the
destructor is never called.
This patch takes a similar approach to IntegerLiteral by using
APIntStorage to allocate large APSInts using the ASTContext allocator as
well.
The downside is that an additional heap allocation and copy of the data
needs to be made when calling getInitValue if the APSInt is large.
Fixes#78160.
When initializing a union that constrain a struct with a flexible array
member, and the initializer list is empty, we currently trigger an
assertion failure. This happens because getFlexibleArrayInitChars()
assumes that the initializer list is non-empty.
Fixes https://github.com/llvm/llvm-project/issues/77085.
Per [[class.friend]p6](http://eel.is/c++draft/class.friend#6) a friend
function shall not be defined if its name isn't unqualified. A
_template-id_ is not a name, meaning that a friend function
specialization does not meet this criteria and cannot be defined.
GCC, MSVC, and EDG all consider friend function specialization
definitions to be invalid de facto explicit specializations and diagnose
them as such.
Instantiating a dependent friend function specialization definition
[currently sets off an assert](https://godbolt.org/z/Krqdq95hY) in
`FunctionDecl::setFunctionTemplateSpecialization`. This happens because
we do not set the `TemplateSpecializationKind` of the `FunctionDecl`
created by template argument deduction to `TSK_ExplicitSpecialization`
for friend functions
[here](https://github.com/llvm/llvm-project/blob/main/clang/lib/Sema/SemaTemplate.cpp#L9600).
I changed the assert condition because I believe this is the correct
behavior.
Close https://github.com/llvm/llvm-project/issues/71347
Previously I misread the concept of module purview. I thought if a
declaration attached to a unnamed module, it can't be part of the module
purview. But after the issue report, I recognized that module purview is
more of a concept about locations instead of semantics.
Concretely, the things in the language linkage after module declarations
can be exported.
This patch refactors `Module::isModulePurview()` and introduces some
possible code cleanups.
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.
During the recent refactoring (b120fe8d32) this enum was moved out of `RecordDecl`. During post-commit review it was found out that its association with `RecordDecl` should be expressed in the name.
/llvm-project/clang/lib/AST/Decl.cpp:4182:7: error: field 'TemplateArgumentsAsWritten' will be initialized after field 'NumCandidates' [-Werror,-Wreorder-ctor]
: TemplateArgumentsAsWritten(TemplateArgsWritten),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NumCandidates(Candidates.size())
1 error generated.
This removes the `ClassScopeFunctionSpecializationDecl` `Decl` node, and
instead uses `DependentFunctionTemplateSpecializationInfo` to handle
such declarations. `DependentFunctionTemplateSpecializationInfo` is also
changed to store a `const ASTTemplateArgumentListInfo*` to be more in
line with `FunctionTemplateSpecializationInfo`.
This also changes `FunctionDecl::isFunctionTemplateSpecialization` to
return `true` for dependent specializations, and
`FunctionDecl::getTemplateSpecializationKind`/`FunctionDecl::getTemplateSpecializationKindForInstantiation`
to return `TSK_ExplicitSpecialization` for non-friend dependent
specializations (the same behavior as dependent class scope
`ClassTemplateSepcializationDecl` & `VarTemplateSepcializationDecl`).
This implements the [[msvc::no_unique_address]] attribute.
There is not ABI compatibility in this patch because the attribute is
relatively new and there's still some uncertainty in the MSVC version.
The recommit changes the attribute definitions so that instead of making
two separate attributes for no_unique_address
and msvc::no_unique_address, it modifies the attributes tablegen emitter
to allow spellings to be target-specific.
This reverts commit 71f9e7695b.
Add __builtin_bcopy to the list of GNU builtins. This was causing a
series of test failures in glibc.
Adjust the tests to reflect the changes in codegen.
Fixes#51409.
Fixes#63065.
This reverts commit 4a55d42696.
Reverting because this breaks sphinx documentation, and even with it
fixed the format of the attribute makes the no_unique_address
documentation show up twice.
After commit 610ec954e1 ("[clang] allow const structs/unions/arrays to
be constant expressions for C"), attempts to evaluate
structs/unions/arrays as constants are also performed for C++98 and
C++03.
An assertion was getting tripped up since the potentially-partially
evaluated value was not being reset for those 2 language modes. Make
sure to reset it now for all C++ modes.
Fixes: #65784
Use member's type when printing.
This also fixes a bug in warning diagnostic for out of order
initialization with designated initializers so it points to a valid
source location when an anonymous member is being initialized.
Fixes https://github.com/llvm/llvm-project/issues/63759
Reviewed By: aaron.ballman, shafik
Differential Revision: https://reviews.llvm.org/D158526
This is a C++ feature that allows the use of `_` to
declare multiple variable of that name in the same scope;
these variables can then not be referred to.
In addition, while P2169 does not extend to parameter
declarations, we stop warning on unused parameters of that name,
for consistency.
The feature is backported to all C++ language modes.
Reviewed By: #clang-language-wg, aaron.ballman
Differential Revision: https://reviews.llvm.org/D153536
This patch renames the `OpenMPIRBuilderConfig` flags to reduce confusion over
their meaning. `IsTargetCodegen` becomes `IsGPU`, whereas `IsEmbedded` becomes
`IsTargetDevice`. The `-fopenmp-is-device` compiler option is also renamed to
`-fopenmp-is-target-device` and the `omp.is_device` MLIR attribute is renamed
to `omp.is_target_device`. Getters and setters of all these renamed properties
are also updated accordingly. Many unit tests have been updated to use the new
names, but an alias for the `-fopenmp-is-device` option is created so that
external programs do not stop working after the name change.
`IsGPU` is set when the target triple is AMDGCN or NVIDIA PTX, and it is only
valid if `IsTargetDevice` is specified as well. `IsTargetDevice` is set by the
`-fopenmp-is-target-device` compiler frontend option, which is only added to
the OpenMP device invocation for offloading-enabled programs.
Differential Revision: https://reviews.llvm.org/D154591
Commit 1283e9868d added getInternalLinkageFor for
ModuleInternalLinkage used by -fmodules-ts. Now that -fmodules-ts is removed, we
can simplify the call sites to use LinkageInfo::internal().
Inline builtins have a very special behavior compared to other
functions, it's better if we keep them restricted to a minimal set of
functions.
Add a linkage check which prevents considering ODR definitions as inline
builtins.
Fix#62958
Differential Revision: https://reviews.llvm.org/D148723
Reported by Coverity:
In clang::FunctionDecl::isReplaceableGlobalAllocationFunction(std::optional<unsigned int> *, bool *): Return value of function which returns null is dereferenced without checking
if (!IsSizedDelete && !Ty.isNull() && Ty->isEnumeralType()) {
QualType T = Ty;
//Condition TD, taking false branch.
while (const auto *TD = T->getAs<TypedefType>())
T = TD->getDecl()->getUnderlyingType();
//returned_null: getAs returns nullptr (checked 95 out of 97 times).
//Dereference null return value (NULL_RETURNS)
// dereference: Dereferencing a pointer that might be nullptr T->getAs() when calling getDecl.
IdentifierInfo *II = T->getAs<EnumType>()->getDecl()->getIdentifier();
if (II && II->isStr("__hot_cold_t"))
Consume();
}
This patch uses castAs instead of getAs which will assert if the type doesn't match.
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D150968
Follow up to LLVM-side change to allow conversion to hot/cold hinted
operator new, not yet standard but supported by open source tcmalloc.
The LLVM change in a35206d782 added the
necessary support to recognize these as library functions, and we
subsequently found that a clang-side change is needed to give them
builtin/nobuiltin attributes as appropriate so they have consistent
removeability.
Based on discussion with Richard Smith, converted the parameter type to
a reserved identifier (39f7b48671) and
added support in this patch to recognize it in clang.
Differential Revision: https://reviews.llvm.org/D149600
Classes can have implicit members that were added before fields were
deserialized. These members were previously silently removed from
`decls()` when fields were deserialized after them.
This was the root cause of a compilation error exposed in
bc95f27337, added a test for it.
Reviewed By: ChuanqiXu
Differential Revision: https://reviews.llvm.org/D148515
