The instantiation of a VarDecl's initializer might be deferred until the
variable is actually used. However, we were still building the
DeclRefExpr with a type that could later be changed by the initializer's
instantiation, which is incorrect when incomplete arrays are involved.
Fixes#79750Fixes#113936Fixes#133047
We have more than 32 extensions in our downstream and had to change this
type from uint32_t to uint64_t.
To simplify our downstream and make the code more flexible, I propose to
make it an array of uint32_t that we can size based on the number of
extensions. I really wanted to use std::bitset, but we have to print the
bits to a .inc file which can't easily be done with std::bitset.
* Move parts of `InitializationSequence::InitializeFrom` corresponding
to C++ [dcl.init.general] p16.6.1 and p16.6.2 into a separate
function,`TryConstructorOrParenListInitialization`
* Use it in `TryListInitialization` to implement [dcl.init.list] p3.2
* Fix parenthesized aggregate initialization being attempted in
copy-initialization contexts or when the constructor call is ambiguous
Co-authored-by: cor3ntin <corentinjabot@gmail.com>
Moving builder classes into separate files
`HLSLBuiltinTypeDeclBuilder.cpp`/`.h`, changing a some
`HLSLExternalSemaSource` methods to private and removing unused methods.
This is a prep work before we start adding more builtin types and
methods, like textures, resource constructors or matrices. For example
constructors could make use of the `BuiltinTypeMethodBuilder`, but this
helper class was defined in `HLSLExternalSemaSource.cpp` after the
method that creates a constructor. Rather than reshuffling the code one
big source file I am moving the builders into a separate cpp & header
file and placing the helper classes declarations up top.
Currently the new header only exposes `BuiltinTypeDeclBuilder` to
`HLSLExternalSemaSource`. In the future but we might decide to expose
more helper classes as needed.
Thanks to the example provided by MagentaTreehouse, I realized the
assertion I added in b8d1f3d6 didn't cover all valid cases like, when
inheriting from a class template specialization, the source of a
synthesized template parameter might be an implicit specialization,
whose inner function template is thus living at depth 0, for which we
don’t want it to overflow too.
I've decided to remove that assertion because I don't think it's
particularly useful: we're checking whether Depth = 0 parameters come
from function templates whose parents contribute no template parameters
to the depth, which is redundant given what the template depth already
means.
This also incorporates a drive-by fix for
https://github.com/llvm/llvm-project/pull/132061#discussion_r2008756718,
which I somehow missed.
DenseSet, SmallPtrSet, SmallSet, SetVector, and StringSet recently
gained C++23-style insert_range. This patch replaces:
Dest.insert(Src.begin(), Src.end());
with:
Dest.insert_range(Src);
This patch does not touch custom begin like succ_begin for now.
It turns out that TemplateParamsReferencedInTemplateArgumentList() and
MarkUsedTemplateParameters() have the similar goal, so let's drop the
hand-written ASTVisitor.
Original PR: #130537
Originally reverted due to revert of dependent commit. Relanding with no
changes.
This changes the MemberPointerType representation to use a
NestedNameSpecifier instead of a Type to represent the base class.
Since the qualifiers are always parsed as nested names, there was an
impedance mismatch when converting these back and forth into types, and
this led to issues in preserving sugar.
The nested names are indeed a better match for these, as the differences
which a QualType can represent cannot be expressed syntatically, and
they represent the use case more exactly, being either dependent or
referring to a CXXRecord, unqualified.
This patch also makes the MemberPointerType able to represent sugar for
a {up/downcast}cast conversion of the base class, although for now the
underlying type is canonical, as preserving the sugar up to that point
requires further work.
As usual, includes a few drive-by fixes in order to make use of the
improvements.
This is the last item of the OpenACC 3.3 spec. It includes the
implicit-name version of 'routine', plus significant refactorings to
make the two work together. The implicit name version is represented as
an attribute on the function call. This patch also implements the
clauses for the implicit-name version, as well as the A.3.4 warning.
This reverts commit 0dba5381d8c8e4cadc32a067bf2fe5e3486ae53d.
YMM rounding was removed from AVX10 whitepaper. Ref:
https://cdrdv2.intel.com/v1/dl/getContent/784343
The MINMAX and SATURATING CONVERT instructions will be removed as a
follow up.
Initial Parse/Sema support for reduction over private variable with
reduction clause.
Section 7.6.10 in in OpenMP 6.0 spec.
- list item in a reduction clause can now be private in the enclosing
context.
- Added support for _original-sharing-modifier_ with reduction clause.
---------
Co-authored-by: Chandra Ghale <ghale@pe31.hpc.amslabs.hpecorp.net>
This introduces some tablegen helpers for defining compatibility
warnings. The main aim of this is to both simplify adding new
compatibility warnings as well as to unify the naming of compatibility
warnings.
I’ve refactored ~half of the compatiblity warnings (that follow the
usual scheme) in `DiagnosticSemaKinds.td` for illustration purposes and
also to simplify/unify the wording of some of them (I also corrected a
typo in one of them as a drive-by fix).
I haven’t (yet) migrated *all* warnings even in that one file, and there
are some more specialised ones for which the scheme I’ve established
here doesn’t work (e.g. because they’re warning+error instead of
warning+extwarn; however, warning+extension *is* supported), but the
point of this isn’t to implement *all* compatibility-related warnings
this way, only to make the common case a bit easier to handle.
This currently also only handles C++ compatibility warnings, but it
should be fairly straight-forward to extend the tablegen code so it can
also be used for C compatibility warnings (if this gets merged, I’m
planning to do that in a follow-up pr).
The vast majority of compatibility warnings are emitted by writing
```c++
Diag(Loc, getLangOpts().CPlusPlusYZ ? diag::ext_... : diag::warn_...)
```
in accordance with which I’ve chosen the following naming scheme:
```c++
Diag(Loc, getLangOpts().CPlusPlusYZ ? diag::compat_cxxyz_foo : diag::compat_pre_cxxyz_foo)
```
That is, for a warning about a C++20 feature—i.e. C++≤17
compatibility—we get:
```c++
Diag(Loc, getLangOpts().CPlusPlus20 ? diag::compat_cxx20_foo : diag::compat_pre_cxx20_foo)
```
While there is an argument to be made against writing ‘`compat_cxx20`’
here since is technically a case of ‘C++17 compatibility’ and not ‘C++20
compatibility’, I at least find this easier to reason about, because I
can just write the same number 3 times instead of having to use
`ext_cxx20_foo` but `warn_cxx17_foo`. Instead, I like to read this as a
warning about the ‘compatibility *of* a C++20 feature’ rather than
‘*with* C++17’.
I also experimented with moving all compatibility warnings to a separate
file, but 1. I don’t think it’s worth the effort, and 2. I think it
hurts compile times a bit because at least in my testing I felt that I
had to recompile more code than if we just keep e.g. Sema-specific
compat warnings in the Sema diagnostics file.
Instead, I’ve opted to put them all in the same place within any one
file; currently this is a the very top but I don’t really have strong
opinions about this.
The `UnresolvedLookupExpr` doesn't get looked up and resolved again
while it is inside the non-dependent context. It propagates into the
codegen phase, causing the assertion failure.
We attempt to determine if the current context is dependent before
moving on with the substitution introduced in the
20a05677f9.
This fixes https://github.com/llvm/llvm-project/issues/122892.
---------
Co-authored-by: Sirraide <aeternalmail@gmail.com>
Original PR: #130537
Reland after updating lldb too.
This changes the MemberPointerType representation to use a
NestedNameSpecifier instead of a Type to represent the base class.
Since the qualifiers are always parsed as nested names, there was an
impedance mismatch when converting these back and forth into types, and
this led to issues in preserving sugar.
The nested names are indeed a better match for these, as the differences
which a QualType can represent cannot be expressed syntatically, and
they represent the use case more exactly, being either dependent or
referring to a CXXRecord, unqualified.
This patch also makes the MemberPointerType able to represent sugar for
a {up/downcast}cast conversion of the base class, although for now the
underlying type is canonical, as preserving the sugar up to that point
requires further work.
As usual, includes a few drive-by fixes in order to make use of the
improvements.
This changes the MemberPointerType representation to use a
NestedNameSpecifier instead of a Type to represent the class.
Since the qualifiers are always parsed as nested names, there was an
impedance mismatch when converting these back and forth into types, and
this led to issues in preserving sugar.
The nested names are indeed a better match for these, as the differences
which a QualType can represent cannot be expressed syntactically, and it
also represents the use case more exactly, being either dependent or
referring to a CXXRecord, unqualified.
This patch also makes the MemberPointerType able to represent sugar for
a {up/downcast}cast conversion of the base class, although for now the
underlying type is canonical, as preserving the sugar up to that point
requires further work.
As usual, includes a few drive-by fixes in order to make use of the
improvements, and removing some duplications, for example
CheckBaseClassAccess is deduplicated from across SemaAccess and
SemaCast.
WG14 N2819 clarified that a compound literal within a function prototype
has a lifetime similar to that of a local variable within the function,
not a file scope variable.
StringLiteral is used as internal data of EmbedExpr and we directly use
it as an initializer if a single EmbedExpr appears in the initializer
list of a char array. It is fast and convenient, but it is causing
problems when string literal character values are checked because #embed
data values are within a range [0-2^(char width)] but ordinary
StringLiteral is of maybe signed char type.
This PR introduces new kind of StringLiteral to hold binary data coming
from an embedded resource to mitigate these problems. The new kind of
StringLiteral is not assumed to have signed char type. The new kind of
StringLiteral also helps to prevent crashes when trying to find
StringLiteral token locations since these simply do not exist for binary
data.
Fixes https://github.com/llvm/llvm-project/issues/119256
It turns out trailing objects are uninitialized
and APValue assignment operator requires a fully initialized object.
Additionally, do some drive-by post-commit-review fixes.
Fixes#125810
---
This patch resolves an issue in Clang where the `-Wunused-variable`
warning was suppressed for structured bindings with elements marked
`[[maybe_unused]]`, causing the entire declaration to be treated as used
and preventing the warning from being emitted.
This iterates on #104717 (which we had to revert)
In a bid to increase our chances of success, we try to avoid blowing up
the stack by
- Using `runWithSufficientStackSpace` in ParseCompoundStatement
- Reducing the size of `StmtVector` a bit
- Reducing the size of `DeclsInGroup` a bit
- Removing a few `ParsedAttributes` from the stacks in places where they
are not strictly necessary. `ParsedAttributes` is a _huge_ object
On a 64 bits system, the following stack size reductions are observed
```
ParseStatementOrDeclarationAfterAttributes: 344 -> 264
ParseStatementOrDeclaration: 520 -> 376
ParseCompoundStatementBody: 1080 -> 1016
ParseDeclaration: 264 -> 120
```
Fixes#94728
See discussion in https://github.com/llvm/llvm-project/issues/125071.
Makes the note clearer for the unreachable case:
Before:
```
./hoge.h:5:12: warning: instantiation of function 'x<int>' required here, but no definition is available [-Wundefined-func-template]
5 | void f() { x<int>(); }
| ^
./shared_ptr2.h:4:6: note: forward declaration of template entity is here
4 | void x() { T t; (void)t; }
| ^
./hoge.h:5:12: note: add an explicit instantiation declaration to suppress this warning if 'x<int>' is explicitly instantiated in another translation unit
5 | void f() { x<int>(); }
|
```
After:
```
./hoge.h:5:12: warning: instantiation of function 'x<int>' required here, but no definition is available [-Wundefined-func-template]
5 | void f() { x<int>(); }
| ^
./shared_ptr2.h:4:6: note: declaration of template entity is unreachable here
4 | void x() { T t; (void)t; }
| ^
1 warning generated.
```
Introduce a trait to determine the number of bindings that would be
produced by
```cpp
auto [...p] = expr;
```
This is necessary to implement P2300
(https://eel.is/c++draft/exec#snd.concepts-5), but can also be used to
implement a general get<N> function that supports aggregates
`__builtin_structured_binding_size` is a unary type trait that evaluates
to the number of bindings in a decomposition
If the argument cannot be decomposed, a sfinae-friendly error is
produced.
A type is considered a valid tuple if `std::tuple_size_v<T>` is a valid
expression, even if there is no valid `std::tuple_element`
specialization or suitable `get` function for that type.
Fixes#46049
This commit improves the diagnostics for vector (elementwise) builtins
in a couple of ways.
It primarily provides more precise type-checking diagnostics for
builtins with specific type requirements. Previously many builtins were
receiving a catch-all diagnostic suggesting types which aren't valid.
It also makes consistent the type-checking behaviour between various
binary and ternary builtins. The binary builtins would check for
mismatched argument types before specific type requirements, whereas
ternary builtins would perform the checks in the reverse order. The
binary builtins now behave as the ternary ones do.
There's never any point to adding a `virtual` specifier to methods in a
`final` class, since the class can't be subclassed. This adds a warning
when we notice this happening, as suggested in #131108.
We don't currently implement the second part of the suggestion, to warn
on `virtual` methods which are never overridden anywhere. Although it's
feasible to do this for things with internal linkage (so we can check at
the end of the TU), it's more complicated to implement and it's not
clear it's worth the effort.
I tested the warning by compiling chromium and clang itself. Chromium
resulted in [277 warnings across 109
files](https://github.com/user-attachments/files/19234889/warnings-chromium.txt),
while clang had [38 warnings across 29
files](https://github.com/user-attachments/files/19234888/warnings-clang.txt).
I inspected a subset of the warning sites manually, and they all seemed
legitimate.
This warning is very easy to fix (just remove the `virtual` specifier)
and I haven't seen any false positives, so it's suitable for
on-by-default. However, I've currently made it off-by-default because it
fires at several places in the repo. I plan to submit a followup PR
fixing those places and enabling the warning by default.
Since a68d20e98, we've been calling HandleDelayedAccessCheck() for
concept declarations when the declaration contains invalid member
accesses.
However, a concept declaration is TemplateDecl such that doesn't contain
any TemplatedDecl.
Fixes https://github.com/llvm/llvm-project/issues/131530
