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
Client apps can (and in the case of the MSVC STL do) set cdecl
explicitly on `new` / `delete` implementations. On the other hand, Clang
generates implicit decls with the target's default CC. This is
problematic for SPIR-V, since the default there is spir_function, which
is not compatible. Since we cannot change pre-existing headers /
implementations, this patch sets the CC to C for the implicit host-side
decls, when compiling for device, to prevent the conflict. This is fine
because the host-side overloards do not get emitted on device.
Adds the `isHLSLResourceRecordArray()` method to the `Type` class. This method returns `true` if the `Type` represents an array of HLSL resource records. Defining this method on `Type` makes it accessible from both sema and codegen.
I fixed support for varargs functions
(previously it didn't crash but the codegen was incorrect).
I added tests for structs and unions which already work. With the
multivalue abi they crash in the backend, so I added a sema check that
rejects structs and unions for that abi.
It will also crash in the backend if passed an int128 or float128 type.
private/firstprivate typically do copy operations, however copying a VLA
isn't really possible. This patch introduces a warning to alert the
person that this copy isn't happening correctly.
As a future direction, we MIGHT consider doing additional work to make
sure they are initialized/copied/deleted/etc correctly.
The vk::binding attribute allows users to explicitly set the set and
binding for a resource in SPIR-V without chaning the "register"
attribute, which will be used when targeting DXIL.
Fixes https://github.com/llvm/llvm-project/issues/136894
This patch adds the 'init recipes' to firstprivate like I did for
'private', so that we can properly init these types. At the moment,
the recipe init isn't generated (just the VarDecl), and this isn't
really used anywhere as it will be used exclusively in Codegen.
These would not give a correct initializer, but they are not possible
to generate correctly anyway, so this patch makes sure we look through
the array type to correctly diagnose these.
Adds explanation why `is_constructible` evaluates to false.
This reapplies as-is e476f968bc8e438a0435d10934f148de570db8eb.
This was reverted in 16d5db71b3c38f21aa17783a8758f947dca5883f because of
a test failure in libc++.
The test failure in libc++ is interesting in that, in the absence of
nested diagnostics a bunch of diagnostics are emitted as error instead
of notes, which we cannot silence with `-verify-ignore-unexpected`.
The fix here is to prevent the diagnostics to be emitted in the first
place.
However this is clearly not ideal and we should make sure to deploy a
better solution in the clang 22 time frame, in the lines of
https://discourse.llvm.org/t/rfc-add-a-new-text-diagnostics-format-that-supports-nested-diagnostics/87641/12Fixes#150601
---------
Co-authored-by: Shamshura Egor <164661612+egorshamshura@users.noreply.github.com>
'firstprivate' can't be generated unless we have a copy constructor, so
this patch implements the restriction as a warning, and prevents the
item from being added to the AST.
Previously, #151360 implemented 'private' clause lowering, but didn't
properly initialize the variables. This patch adds that behavior to make
sure we correctly get the constructor or other init called.
The original wording can be squinted at to pretend this was always
allowed. GCC squints at it that way, so we're doing the same and no
longer issuing an extension diagnostic for use of static_assert in the
condition-1 of a for loop in C.
Fixes#149633
This fixes an ambiguous type type_info when you try and reference the
`type_info` type while using clang modulemaps with `-fms-compatibility`
enabled
Fixes#38400
This is a first pass at implementing
[P2841R7](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p2841r7.pdf).
The implementation is far from complete; however, I'm aiming to do that
in chunks, to make our lives easier.
In particular, this does not implement
- Subsumption
- Mangling
- Satisfaction checking is minimal as we should focus on #141776 first
(note that I'm currently very stuck)
FTM, release notes, status page, etc, will be updated once the feature
is more mature. Given the state of the feature, it is not yet allowed in
older language modes.
Of note:
- Mismatches between template template arguments and template template
parameters are a bit wonky. This is addressed by #130603
- We use `UnresolvedLookupExpr` to model template-id. While this is
pre-existing, I have been wondering if we want to introduce a different
OverloadExpr subclass for that. I did not make the change in this patch.
- Closes#151787
Insert the right parenthesis one token later to correctly enclose the
expression.
---------
Co-authored-by: Corentin Jabot <corentinjabot@gmail.com>
This commit handles the following types:
- clang::ExternalASTSource
- clang::TargetInfo
- clang::ASTContext
- clang::SourceManager
- clang::FileManager
Part of cleanup #151026
The Loc param to these functions was weird and not always set in error
cases. It wasn't reliable to use.
This was almost entirely unused inside of clang and the one call site
that used the returned source location doesn't make a difference in
practice.
Previously, the `sycl_kernel_entry_point` attribute could be specified
using either the GNU or C++11 spelling styles. Future SYCL attributes
are expected to support only the C++11 spelling style, so support for
the GNU style is being removed.
In order to ensure consistent presentation of the attribute in
diagnostic messages, diagnostics specific to this attribute now require
the attribute to be provided as an argument. This delegates formatting
of the attribute name to the diagnostic engine.
As an additional nicety, "the" is added to some diagnostic messages so
that they read more like proper sentences.
Previously Clang would give an unwarranted error on the capture of '&a'
in the function below, even though the parent function and the lambda
are both `__arm_streaming` functions, when the target is compiled with
+sme only.
```
void test_both_streaming(int32_t *out) __arm_streaming {
svint32_t a;
[&a, &out]() __arm_streaming {
^
error: SVE vector type 'svint32_t' (aka '__SVInt32_t') cannot be used in a non-streaming function
a = svdup_s32(1);
svst1(svptrue_b32(), out, a);
}();
}
```
That seems to happen because when `checkTypeSupport` is called the
`FunctionDecl` context of the lambda isn't yet complete and
`FD->getType()` returns a Null `QualTy`.
This is loosely related to #94976 which removed a `FD->hasBody()` check
in the same place, because `hasBody()` may incorrectly return `false`
when Clang is still processing a function.
When searching for noreturn variable initializations, do not visit CFG
blocks that are already visited, it prevents hanging the analysis.
It must fix https://github.com/llvm/llvm-project/issues/150336.
This reverts commit e476f968bc8e438a0435d10934f148de570db8eb.
It has introduced a failure tracked by https://github.com/llvm/llvm-project/issues/150601
One libcxx test fail if libcxx is build with no exceptions and no RTTI:
- libcxx/utilities/expected/expected.expected/value.observers.verify.cpp
We allowed implicit this access when checking associated constraints
after CWG2369. As a result, some of the invalid function call
expressions were not properly SFINAE'ed out and ended up as hard errors
at evaluation time.
We tried fixing that by mucking around the CurContext, but that spawned
additional breakages and I think it's probably safe to revert to the
previous behavior to avoid churns.
Though there is CWG2589, which justifies the previous change, it's not
what we're pursuing now.
Fixes https://github.com/llvm/llvm-project/issues/151271
Fixes https://github.com/llvm/llvm-project/issues/145505
It is better to use DynamicRecursiveASTVisitor than RecursiveASTVisitor
as it can reduce the generated size. And also avoid using a template
type to present callbacks to avoid generating more code too.
The Cygwin target is generally very similar to the MinGW target. The
default auto-import behavior, the default calling convention, the
`.dll.a` import library extension, the `__GXX_TYPEINFO_EQUALITY_INLINE`
pre-define by `g++`, and the long double configuration.
Co-authored-by: Mateusz Mikuła <oss@mateuszmikula.dev>
Depending on the particular version of the AArch32 architecture,
load/store exclusive operations might be available for various subset of
8, 16, 32, and 64-bit quantities. Sema knew nothing about this and was
accepting all four sizes, leading to a compiler crash at isel time if
you used a size not available on the target architecture.
Now the Sema checking stage emits a more sensible diagnostic, pointing
at the location in the code.
In order to allow Sema to query the set of supported sizes, I've moved
the enum of LDREX_x sizes out of its Arm-specific header into
`TargetInfo.h`.
Also, in order to allow the diagnostic to specify the correct list of
supported sizes, I've filled it with `%select{}`. (The alternative was
to make separate error messages for each different list of sizes.)
Clang's current implementation only works on array types, but GCC (which
is where we got this attribute) supports it on pointers as well as
arrays.
Fixes#150951
Tracked at https://github.com/llvm/llvm-project/issues/112294
This patch implements from [basic.link]p14 to [basic.link]p18 partially.
The explicitly missing parts are:
- Anything related to specializations.
- Decide if a pointer is associated with a TU-local value at compile
time.
- [basic.link]p15.1.2 to decide if a type is TU-local.
- Diagnose if TU-local functions from other TU are collected to the
overload set. See [basic.link]p19, the call to 'h(N::A{});' in
translation unit #2
There should be other implicitly missing parts as the wording uses
"names" briefly several times. But to implement this precisely, we have
to visit the whole AST, including Decls, Expression and Types, which may
be harder to implement and be more time-consuming for compilation time.
So I choose to implement the common parts.
It won't be too bad to miss some cases since we DIDN'T do any such
checks in the past 3 years. Any new check is an improvement. Given
modules have been basically available since clang15 without such checks,
it will be user unfriendly if we give a hard error now. And there are
a lot of cases which violating the rule actually just fine. So I decide
to emit it as warnings instead of hard errors.
Tests if the runtime type of the function pointer matches the static
type. If this returns false, calling the function pointer will trap.
Uses `@llvm.wasm.ref.test.func` added in #147486.
Also adds a "gc" wasm feature to gate the use of the ref.test
instruction.
These two both allow arrays as their variable references, but it is a
common thing to use sub-arrays as a way to get a pointer to act as an
array with other compilers. This patch adds these, with an
extension-warning.
Running an external test suite (UDel) showed that our expression
comparison for the 'cache' rule checking was overly strict in the
presence of irrelevant parens/casts/etc. This patch ensures we skip
them when checking.
This also changes the diagnostic to say 'sub-expression' instead of
variable, which is more correct.