It was previously failing because of a warning marking a C++20 feature
as an extension.
This is a follow-up to 85043c1c146fd5658ad4c5b5138e58994333e645 that
introduced the test.
When building the base type for constructor initializer, the case of an
UnresolvedUsingType was not being handled.
For the non-dependent case, we are also skipping adding the UsingType,
but this is just missing information in the AST. A FIXME for this is
added.
This fixes a regression introduced in #147835, which was never released,
so there are no release notes.
Fixes#154436
The new builtin `__builtin_dedup_pack` removes duplicates from list of
types.
The added builtin is special in that they produce an unexpanded pack
in the spirit of P3115R0 proposal.
Produced packs can be used directly in template argument lists and get
immediately expanded as soon as results of the computation are
available.
It allows to easily combine them, e.g.:
```cpp
template <class ...T>
struct Normalize {
// Note: sort is not included in this PR, it illustrates the idea.
using result = std::tuple<
__builtin_sort_pack<
__builtin_dedup_pack<int, double, T...>...
>...>;
}
;
```
Limitations:
- only supported in template arguments and bases,
- can only be used inside the templates, even if non-dependent,
- the builtins cannot be assigned to template template parameters.
The actual implementation proceeds as follows:
- When the compiler encounters a `__builtin_dedup_pack` or other
type-producing
builtin with dependent arguments, it creates a dependent
`TemplateSpecializationType`.
- During substitution, if the template arguments are non-dependent, we
will produce: a new type `SubstBuiltinTemplatePackType`, which stores
an argument pack that needs to be substituted. This type is similar to
the existing `SubstTemplateParmPack` in that it carries the argument
pack that needs to be expanded further. The relevant code is shared.
- On top of that, Clang also wraps the resulting type into
`TemplateSpecializationType`, but this time only as a sugar.
- To actually expand those packs, we collect the produced
`SubstBuiltinTemplatePackType` inside `CollectUnexpandedPacks`.
Because we know the size of the produces packs only after the initial
substitution, places that do the actual expansion will need to have a
second run over the substituted type to finalize the expansions (in
this patch we only support this for template arguments, see
`ExpandTemplateArgument`).
If the expansion are requested in the places we do not currently
support, we will produce an error.
More follow-up work will be needed to fully shape this:
- adding the builtin that sorts types,
- remove the restrictions for expansions,
- implementing P3115R0 (scheduled for C++29, see
https://github.com/cplusplus/papers/issues/2300).
This fixes a regression reported here
https://github.com/llvm/llvm-project/pull/147835#issuecomment-3181811371,
where getTrivialTemplateArgumentLoc can't see through template name
sugar when producing a trivial TemplateArgumentLoc for template template
arguments.
Since this regression was never released, there are no release notes.
If a template argument in a partial specialization of a variable
template directly refers to a NTTP of the specialization without
implicit type conversion it was assumed that the NTTP is identical to
that of the primary template.
This doesn't hold if the primary template's NTTP uses a deduced type, so
instead compare the types explicitly as well.
The affected function is used only to provide an improved early error if
the partial specialization has identical template arguments to the
primary template. The actual check that the partial specialization is
more specialized happens later.
Fixes#118190Fixes#152750
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
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
The synthesized deduction guides use injected template arguments for
distinguishment of explicit and implicit deduction guides.
In partial ordering, we may substitute into these injected types when
checking consistency. Properly substituting them needs the instantiated
class template specializations which isn't the case at that point. So
instead, we check their template specialization types.
No release note because I think we want a backport, after baking it for
a couple of days.
Fixes https://github.com/llvm/llvm-project/issues/134613
The checks for the 'z' and 't' format specifiers added in the original
PR #143653 had some issues and were overly strict, causing some build
failures and were consequently reverted at
4c85bf2fe8.
In the latest commit
27c58629ec,
I relaxed the checks for the 'z' and 't' format specifiers, so warnings
are now only issued when they are used with mismatched types.
The original intent of these checks was to diagnose code that assumes
the underlying type of `size_t` is `unsigned` or `unsigned long`, for
example:
```c
printf("%zu", 1ul); // Not portable, but not an error when size_t is unsigned long
```
However, it produced a significant number of false positives. This was
partly because Clang does not treat the `typedef` `size_t` and
`__size_t` as having a common "sugar" type, and partly because a large
amount of existing code either assumes `unsigned` (or `unsigned long`)
is `size_t`, or they define the equivalent of size_t in their own way
(such as
sanitizer_internal_defs.h).2e67dcfdcd/compiler-rt/lib/sanitizer_common/sanitizer_internal_defs.h (L203)
This is another case where untransformed constraint expressions led to
inconsistent transforms.
We did fix some of those issues by looking at parent scopes, however the
parent instantiation scope is not always available because we could also
reach here after the parents get instantiated.
Fixes#146614
Including the results of `sizeof`, `sizeof...`, `__datasizeof`,
`__alignof`, `_Alignof`, `alignof`, `_Countof`, `size_t` literals, and
signed `size_t` literals, the results of pointer-pointer subtraction and
checks for standard library functions (and their calls).
The goal is to enable clang and downstream tools such as clangd and
clang-tidy to provide more portable hints and diagnostics.
The previous discussion can be found at #136542.
This PR implements this feature by introducing a new subtype of `Type`
called `PredefinedSugarType`, which was considered appropriate in
discussions. I tried to keep `PredefinedSugarType` simple enough yet not
limited to `size_t` and `ptrdiff_t` so that it can be used for other
purposes. `PredefinedSugarType` wraps a canonical `Type` and provides a
name, conceptually similar to a compiler internal `TypedefType` but
without depending on a `TypedefDecl` or a source file.
Additionally, checks for the `z` and `t` format specifiers in format
strings for `scanf` and `printf` were added. It will precisely match
expressions using `typedef`s or built-in expressions.
The affected tests indicates that it works very well.
Several code require that `SizeType` is canonical, so I kept `SizeType`
to its canonical form.
The failed tests in CI are allowed to fail. See the
[comment](https://github.com/llvm/llvm-project/pull/135386#issuecomment-3049426611)
in another PR #135386.
This fixes a failed assertion with an operator call expression which
comes from a macro expansion when performing analysis for nullability
attributes.
Fixes#138371
Since the function template isn't instantiated before constraint
checking, we'll not be able to find the outer template arguments through
function specialization when evaluating the inner constraint that is
nested within a larger constraint expression.
The only practical solution is to get them back through the code
synthesis context, which also allows us to eliminate an overload of
getTemplateInstantiationArgs.
No release note because it's a regression on trunk.
Fixes https://github.com/llvm/llvm-project/issues/147772
When we create a lambda, we would skip over declaration contexts
representing a require expression body, which would lead to wrong
lookup.
Note that I wasn't able to establish why the code
in `Sema::createLambdaClosureType` was there to begin with (it's not
exactly recent)
The changes to mangling only ensure the status quo is preserved and do
not attempt to address the known issues of
mangling lambdas in require clauses.
In particular the itanium mangling is consistent with Clang before this
patch but differs from GCC's.
Fixes#147650
When a specialization was ambiguous, we would mark it as invalid, even
if the specialization occured in an immediate context.
This would subsequently lead to scenarios where invalid specialization
produced no diagnostics, causing crashes during codegen.
Fixes#51866
We were using the lexical DC as the starting point of template argument
collection when comparing declarations. This caused an issue that
template arguments from out-of-line declarations are ignored when
substituting into the constraints, which in turn led to expression
mismatching.
Fixes https://github.com/llvm/llvm-project/issues/145521
For a dependent variable template specialization, we don't build a
dependent Decl node or a DeclRefExpr to represent it. Instead, we
preserve the UnresolvedLookupExpr until instantiation.
However, this approach isn't ideal for constraint normalization. We
consider the qualifier during profiling, but since that's based on the
written code, it can introduce confusing differences, even when the
expressions resolve to the same declaration.
This change profiles the underlying VarTemplateDecl if
UnresolvedLookupExpr is used to model a dependent use of it.
Fixes https://github.com/llvm/llvm-project/issues/139476
We already evaluate the initializers for all global variables, as
required by the standard. Leverage that evaluation instead of trying to
separately validate static class members.
This has a few benefits:
- Improved diagnostics; we now get notes explaining what failed to
evaluate.
- Improved correctness: is_constant_evaluated is handled correctly.
The behavior follows the proposed resolution for CWG1721.
Fixes#88462. Fixes#99680.
CWG2369 revealed another case where we were SFINAE'ing out the invalid
result of substitution, but the expression now makes the way into evaluation.
We switch to the concept specialization's context before we check it.
This ensures that we're able to realize the invalid expression earlier,
so we can avoid evaluating invalid expression, which is a hard error.
This also fixes#115838
This variable attribute is used in HLSL to add Vulkan specific builtins
in a shader.
The attribute is documented here:
17727e88fd/proposals/0011-inline-spirv.md
Those variable, even if marked as `static` are externally initialized by
the pipeline/driver/GPU. This is handled by moving them to a specific
address space `hlsl_input`, also added by this commit.
The design for input variables in Clang can be found here:
355771361e/proposals/0019-spirv-input-builtin.md
Co-authored-by: Justin Bogner <mail@justinbogner.com>
The previous approach broke code generation for the MS ABI due to an
unintended code path during constraint substitution. This time we
address the issue by inspecting the evaluation contexts and thereby
avoiding that code path.
This reapplies 96eced624 (#102857).
This offloads some test changes from another PR in order to facilitate
review.
- Adds some new tests.
- Cleans stray spaces and newlines on existing tests.
- Regenerates some AST json dumps, as the generator now includes
offsets.
032ad59 taught the instantiator to expand template argument packs for
rewrite. However we might already be in a pack expansion when we
synthesizing the CTAD guide, so we reset the ArgPackSubstIndex to ensure
it doesn't get confused.
No release note because this is a regression in Clang 21.
Fixes https://github.com/llvm/llvm-project/issues/141425
---------
Co-authored-by: Erich Keane <ekeane@nvidia.com>
The previous approach broke the instantiation convention for templated
substitutions, as we were attempting to instantiate the initializer
even when it was still dependent.
We deferred variable template instantiation until the end of the TU.
However, type deduction requires the initializer immediately,
similar to how constant evaluation does.
Fixes https://github.com/llvm/llvm-project/issues/140773Fixes#135032Fixes#134526
Reapplies https://github.com/llvm/llvm-project/pull/138122
When using InitChecker with VerifyOnly, we create a new designated
initializer to handle anonymous fields. However in the last call to
CheckDesignatedInitializer, the subinitializer isn't properly preserved
but it gets overwritten by the cloned one. Which causes the initializer
to reference the dependent field, breaking assumptions when we
initialize the instantiated specialization.
Fixes https://github.com/llvm/llvm-project/issues/67173
Fixes https://github.com/llvm/llvm-project/issues/135032
Due to nested templates, when instantiating the outer layer (the
template class), the inner layer (the template variable) uses delayed
instantiation.
This causes the declaration (VarDecl) of the template variable to retain
the type from the original template declaration (i.e., auto), and it
loses the initializer.
Later, when instantiating the template variable, its
VarTemplateSpecializationDecl type depends on the VarDecl type.
Thus, the VarTemplateSpecializationDecl also has no initializer, and its
type remains auto.
Ultimately, when building the reference expression in
Sema::BuildDeclarationNameExpr, the expression's type is auto and stays
as auto until code generation, triggering llvm_unreachable in
CodeGenTypes::ConvertType.
Since I noticed that the deduction of auto type is caused by the
initializer
I plan to do special processing for template variables of type auto,
that is, to prevent their delayed instantiation
so that their initializers will not be lost when the outer template
class is instantiated
For a dependent variable template specialization, we don't build a
dependent Decl node or a DeclRefExpr to represent it. Instead, we
preserve the UnresolvedLookupExpr until instantiation.
However, this approach isn't ideal for constraint normalization. We
consider the qualifier during profiling, but since that's based on the
written code, it can introduce confusing differences, even when the
expressions resolve to the same declaration.
This change ensures that, if possible, we profile the resolved
declaration instead of its qualifier. For expressions that resolve to
more than one declarations, we still profile its qualifier, as otherwise
it would make us depend on the order of lookup results.
Fixes https://github.com/llvm/llvm-project/issues/139476
Since 346077aa, we began using the primary template's lexical
DeclContext for template arguments in order to properly instantiate a
friend definition.
There is a missed peculiar case, as in a friend template is specialized
within a dependent context. In this scenario, the primary template is
not a definition, whereas the specialization is. So the primary
template's DeclContext doesn't provide anything meaningful
for instantiation.
Fixes https://github.com/llvm/llvm-project/issues/139052
When profiling a pack indexing that has been partially substituted, we
should profile the expansions, rather than the pattern itseld
This is a better approach to #139057
This mirrors the fix done for SizeOfPackExpr in #124533Fixes#138255
There are a few diagnostics that are incorrectly grouped under
`-Wc++20-compat` instead of `-Wpre-c++20-compat`.
I grepped for any remaining `-Wc++xy-compat` diagnostics, but they all
seem to actually be about compatibility with C++XY.
Fixes#138775.
When forming an invalid function type, we were not diagnosing it if the
call was dependent.
However, we later rely on the function type to be sensible during
argument deduction.
We now diagnose anything that is not a potential function type, to avoid
constructing bogus call expressions.
Fixes#138657Fixes#115725Fixes#68852
We made chained comparisons an error.
Fold-expressions over a comparison operator produce chained comparisons,
so we should be consistent there too.
We only emit the warning when instantiating the fold expression so as
not to warn on types with user-defined comparisons.
Partially addresses #129570
This reapplies #134038
Since the last patch, this fixes a null pointer dereference where the
TSI of the destructor wasn't properly propagated into the
DeclarationNameInfo. We now construct a LocInfoType for dependent cases,
as done elsewhere in getDestructorName, such that GetTypeFromParser can
correctly obtain the TSI.
---
This patch fixes two long-standing bugs that prevent Clang from
instantiating local class members inside a dependent context. These bugs
were introduced in commits
21eb1af469
and
919df9d75a.
21eb1af469
introduced a concept called eligible methods such that it did an attempt
to skip past ineligible method instantiation when instantiating class
members. Unfortunately, this broke the instantiation chain for local
classes - getTemplateInstantiationPattern() would fail to find the
correct definition pattern if the class was defined within a partially
transformed dependent context.
919df9d75a
introduced a separate issue by incorrectly copying the
DeclarationNameInfo during function definition instantiation from the
template pattern, even though that DNI might contain a transformed
TypeSourceInfo. Since that TSI was already updated when the declaration
was instantiated, this led to inconsistencies. As a result, the final
instantiated function could lose track of the transformed declarations,
hence we crash: https://compiler-explorer.com/z/vjvoG76Tf.
This PR corrects them by
1. Removing the bypass logic for method instantiation. The eligible flag
is independent of instantiation and can be updated properly afterward,
so skipping instantiation is unnecessary.
2. Carefully handling TypeSourceInfo by creating a new instance that
preserves the pattern's source location while using the already
transformed type.
This implements the same overload resolution behavior as GCC,
as described in https://wg21.link/p3606 (section 1-2, not 3)
If during overload resolution, there is a non-template candidate
that would be always be picked - because each of the argument
is a perfect match (ie the source and target types are the same),
we do not perform deduction for any template candidate
that might exists.
The goal is to be able to merge
https://github.com/llvm/llvm-project/pull/122423 without being too
disruptive.
This change means that the selection of the best viable candidate and
template argument deduction become interleaved.
To avoid rewriting half of Clang we store in `OverloadCandidateSet`
enough information to be able to deduce template candidates from
`OverloadCandidateSet::BestViableFunction`. Which means
the lifetime of any object used by template argument must outlive
a call to `Add*Template*Candidate`.
This two phase resolution is not performed for some initialization
as there are cases where template candidate are better match
in these cases per the standard. It's also bypassed for code completion.
The change has a nice impact on compile times
https://llvm-compile-time-tracker.com/compare.php?from=719b029c16eeb1035da522fd641dfcc4cee6be74&to=bf7041045c9408490c395230047c5461de72fc39&stat=instructions%3Au
Fixes https://github.com/llvm/llvm-project/issues/62096
Fixes https://github.com/llvm/llvm-project/issues/74581
Reapplies #133426
It's possible that some deduced template arguments come from default
arguments, not just from the return type. So we need to recursively
visit the default arguments of the parameter if it's referenced, thereby
the template parameter referenced by the defualt arguments could come
along to the synthesized deduction guide.
Fixes https://github.com/llvm/llvm-project/issues/134471
