Current context set to where alias was met, not where it is declared
caused incorrect access check in case alias referenced private members
of the parent class.
This is a recommit of 6b1aa31 with a slight modification in order to fix
reported regression.
Fixes https://github.com/llvm/llvm-project/issues/41693
When checking if the constraint uses any enclosing template parameters
for [temp.friend]p9, if a containing record is used as argument, we
assume that the constraint depends on enclosing template parameters
without checking if the record is templated. The reproducer from the bug
is included as a test case.
Fixes#71595
If a template is defined via an external AST source, it won't have a
location. When we emit warnings about misusing such templates we
shouldn't emit a "template is declared here" warning with no location,
as that's just confusing.
Reviewers: llvm-beanz, erichkeane, AaronBallman
Reviewed By: erichkeane, AaronBallman
Pull Request: https://github.com/llvm/llvm-project/pull/71264
Current context set to where alias was met, not where it is declared
caused incorrect access check in case alias referenced private members
of the parent class.
Fixes https://github.com/llvm/llvm-project/issues/41693
Reland of f418319730 with proper handling
of template constructors
When a nested template is instantiated, the template pattern of the
inner class is not copied into the outer class
ClassTemplateSpecializationDecl. The specialization contains a
ClassTemplateDecl with an empty record that points to the original
template pattern instead.
As a result, when looking up the constructors of the inner class, no
results are returned. This patch finds the original template pattern and
uses that for the lookup instead.
Based on CWG2471 we must also substitute the known outer template
arguments when creating deduction guides for the inner class.
Changes from last iteration:
1. In template constructors, arguments are first rewritten to depth - 1
relative to the constructor as compared to depth 0 originally. These
arguments are needed for substitution into constraint expressions.
2. Outer arguments are then applied with the template instantiator to
produce a template argument at depth zero for use in the deduction
guide. This substitution does not evaluate constraints, which preserves
constraint arguments at the correct depth for later evaluation.
3. Tests are added that cover template constructors within nested
deduction guides for all special substitution cases.
4. Computation of the template pattern and outer instantiation arguments
are pulled into the constructor of
`ConvertConstructorToDeductionGuideTransform`.
When the top of the instantiation stack is in user code.
The goal of this PR is to allow deprecation of some char_traits
specializations in libc++ as done in https://reviews.llvm.org/D157058
which was later reverted by
https://github.com/llvm/llvm-project/pull/66153#issuecomment-1719578384
as Clang never emitted the libc++ warnings.
Because Clang likes to eagerly instantiate, we can look for the location
of the top of the instantiation stack, and emit a warning if that
location is in user code.
The warning emission is forced by temporarily instructing the diag
engine not to silence warning in system headers.
This adds `UnexpandedParameterPackContext::UPPC_ExplicitSpecialization`
and passes it to `DiagnoseUnexpandedParameterPack` when checking
class/variable template explicit specializations.
Right now we don't check for unexpanded packs in function template
explicit specializations at all, so I will be addressing that in a
followup PR.
This patch converts `CharacterLiteral::CharacterKind` to scoped enum in namespace scope. This enables forward declaration of this enum, which is useful in case like annotating bit-fields with `preferred_type`.
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.
This patch moves ElaboratedTypeKeyword before `Type` definition so that the enum is complete where bit-field for it is declared. It also converts it to scoped enum and removes `ETK_` prefix.
Reland of dd0fba1169
When a nested template is instantiated, the template pattern of the
inner class is not copied into the outer class
ClassTemplateSpecializationDecl. The specialization contains a
ClassTemplateDecl with an empty record that points to the original
template pattern instead.
As a result, when looking up the constructors of the inner class, no
results are returned. This patch finds the original template pattern and
uses that for the lookup instead.
Based on CWG2471 we must also substitute the known outer template
arguments when creating deduction guides for the inner class.
Changes from the last iteration:
1. The outer retained levels from the outer template are always added to
the `MultiLevelTemplateArgumentList` for rewriting
`FunctionTemplateDecl` arguments, even if there is no FTD and the
arguments are empty.
2. When building implicit deduction guides, the template pattern
underlying decl is pushed as the current context. This resolves the
issue where `FindInstantiatedDecl` is unable to find the inner template
class.
3. Tests are updated to cover the failing case, and to assert that the
type is correct after argument deduction in the implicit case.
Out of line class template declaration specializations aren't created at
the time they have their template arguments checked, so we previously
weren't doing any amount of work to substitute the constraints before
comparison. This resulted in the out of line definition's difference in
'depth' causing the constraints to compare differently.
This patch corrects that. Additionally, it handles ClassTemplateDecl
when collecting template arguments.
Fixes: #61763
The dependence of a template argument is not only determined by the
argument itself, but also by the type of the template parameter:
> Furthermore, a non-type
[template-argument](https://eel.is/c++draft/temp.names#nt:template-argument)
is dependent if the corresponding non-type
[template-parameter](https://eel.is/c++draft/temp.param#nt:template-parameter)
is of reference or pointer type and the
[template-argument](https://eel.is/c++draft/temp.names#nt:template-argument)
designates or points to a member of the current instantiation or a
member of a dependent
type[.](https://eel.is/c++draft/temp.dep#temp-3.sentence-1)
For example:
```cpp
struct A{};
template <const A& T>
const A JoinStringViews = T;
template <int V>
class Builder {
public:
static constexpr A Equal{};
static constexpr auto Val = JoinStringViews<Equal>;
};
```
The constant expression `Equal` is not dependent, but because the type
of the template parameter is a reference type and `Equal` is a member of
the current instantiation, the template argument of
`JoinStringViews<Equal>` is actually dependent, which makes
`JoinStringViews<Equal>` dependent.
When a template-id of a variable template is dependent,
`CheckVarTemplateId` will return an `UnresolvedLookupExpr`, but
`UnresolvedLookupExpr` calculates dependence by template arguments only
(the `ConstantExpr` `Equal` here), which is not dependent. This causes
type deduction to think that `JoinStringViews<Equal>` is `OverloadTy`
and treat it as a function template, which is clearly wrong.
This PR adds a `KnownDependent` parameter to the constructor of
`UnresolvedLookupExpr`. After canonicalization, if `CanonicalConverted`
contains any dependent argument, `KnownDependent` is set to `true`. This
fixes the dependence calculation of `UnresolvedLookupExpr` for dependent
variable templates.
Fixes#65153 .
This reverts commit dd0fba1169.
It fails on nested classes that have both an explicit deduction guide and
a constructor that has an argument of the same type as the class (i.e. a copy constructor).
When a nested template is instantiated, the template pattern of the
inner class is not copied into the outer class
ClassTemplateSpecializationDecl. The specialization contains a
ClassTemplateDecl with an empty record that points to the original
template pattern instead.
As a result, when looking up the constructors of the inner class, no
results are returned. This patch finds the original template pattern and
uses that for the lookup instead.
Based on CWG2471 we must also substitute the known outer template
arguments when creating deduction guides for the inner class.
Fixes#46200Fixes#57812
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`).
The goal of this change is to clean up some of the code surrounding
HLSL using CXXThisExpr as a non-pointer l-value. This change cleans up
a bunch of assumptions and inconsistencies around how the type of
`this` is handled through the AST and code generation.
This change is be mostly NFC for HLSL, and completely NFC for other
language modes.
This change introduces a new member to query for the this object's type
and seeks to clarify the normal usages of the this type.
With the introudction of HLSL to clang, CXXThisExpr may now be an
l-value and behave like a reference type rather than C++'s normal
method of it being an r-value of pointer type.
With this change there are now three ways in which a caller might need
to query the type of `this`:
* The type of the `CXXThisExpr`
* The type of the object `this` referrs to
* The type of the implicit (or explicit) `this` argument
This change codifies those three ways you may need to query
respectively as:
* CXXMethodDecl::getThisType()
* CXXMethodDecl::getThisObjectType()
* CXXMethodDecl::getThisArgType()
This change then revisits all uses of `getThisType()`, and in cases
where the only use was to resolve the pointee type, it replaces the
call with `getThisObjectType()`. In other cases it evaluates whether
the desired returned type is the type of the `this` expr, or the type
of the `this` function argument. The `this` expr type is used for
creating additional expr AST nodes and for member lookup, while the
argument type is used mostly for code generation.
Additionally some cases that used `getThisType` in simple queries could
be substituted for `getThisObjectType`. Since `getThisType` is
implemented in terms of `getThisObjectType` calling the later should be
more efficient if the former isn't needed.
Reviewed By: aaron.ballman, bogner
Differential Revision: https://reviews.llvm.org/D159247
This change addresses three issues:
1) A failure to propagate a MSInheritanceAttr prior to it being required by
an explicit class template instantiation definition.
2) The same MSInheritanceAttr attribute being attached to the same
ClassTemplateSpecializationDecl twice.
3) MSInheritanceAttr attributes were not being cloned nor marked as inherited
when added to new template instantiation declarations.
Sema::ActOnExplicitInstantiation() is responsible for the construction of
ClassTemplateSpecializationDecl nodes for explicit template instantiation
declarations and definitions. When invoked when a prior declaration node
corresponding to an implicit instantiation exists, the prior declaration
node is repurposed to represent the explicit instantiation declaration
or definition. When no previous declaration node exists or when the previous
node corresponds to an explicit declaration, a new node is allocated.
Previously, in either case, the function attempted to propagate any existing
MSInheritanceAttr attribute from the previous node, but did so regardless
of whether the previous node was reused (in which case the repurposed previous
node would gain a second attachment of the attribute; the second issue listed
above) or a new node was created. In the latter case, the attribute was not
propagated before it was required to be present when compiling for C++17 or
later (the first issue listed above). The absent attribute resulted in an
assertion failure that occurred during instantiation of the specialization
definition when attempting to complete the definition in order to determine
its alignment so as to resolve a lookup for a deallocation function for a
virtual destructor. This change addresses both issues by propagating the
attribute closer in time to when a new ClassTemplateSpecializationDecl node
is created and only when such a node is newly created.
Reviewed By: aaron.ballman, rnk
Differential Revision: https://reviews.llvm.org/D158869
This patch adds a concept AST node (`ConceptLoc`) and uses it at the corresponding places.
There are three objects that might have constraints via concepts:
`TypeConstraint`, `ConceptSpecializationExpr` and `AutoTypeLoc`.
The first two inherit from `ConceptReference` while the latter has
the information about a possible constraint directly stored in `AutoTypeLocInfo`. It would be nice if the concept information would be stored the same way in all three cases.
Moreover the current structure makes it difficult to deal with these concepts. For example in Clangd accessing the locations of constraints of a `AutoTypeLoc` can only be done with quite ugly hacks.
So we think that it makes sense to create a new AST node for such concepts.
In details we propose the following:
- Rename `ConceptReference` to `ConceptLoc` (or something else what is approriate)
and make it the new AST node.
- `TypeConstraint` and `ConceptSpecializationExpr` do not longer inherit from `ConceptReference` but store a pointer to a `ConceptLoc`.
- `AutoTypeLoc` stores a pointer to `ConceptLoc` instead of storing the concept info in `AutoTypeLocInfo`.
This patch implements a first version of this idea which compiles and where the existing tests pass.
To make this patch as small as possible we keep the existing member functions to access concept data. Later these can be replaced by directly calling the corresponding functions of the `ConceptLoc`s.
Differential Revision: https://reviews.llvm.org/D155858
This is recommit of 98390ccb80, reverted
in 82a3969d71, because it caused
https://github.com/llvm/llvm-project/issues/63542. Although the problem
described in the issue is independent of the reverted patch, fail of
PCH/late-parsed-instantiations.cpp indeed obseved on PowerPC and is
likely to be caused by wrong serialization of `LateParsedTemplate`
objects. In this patch the serialization is fixed.
Original commit message is below.
Previously function template instantiations occurred with FP options
that were in effect at the end of translation unit. It was a problem
for late template parsing as these FP options were used as attributes of
AST nodes and may result in crash. To fix it FP options are set to the
state of the point of template definition.
Differential Revision: https://reviews.llvm.org/D143241
Previously function template instantiations occurred with FP options
that were in effect at the end of translation unit. It was a problem
for late template parsing as these FP options were used as attributes of
AST nodes and may result in crash. To fix it FP options are set to the
state of the point of template definition.
Differential Revision: https://reviews.llvm.org/D143241
The type alias template is not diagnosed when instantiating an expected non-type template argument in a dependent scope, causing ICE.
Besides that, the diagnostic message has been updated to account for the fact that the function template is not the only non-type template.
Fixes#62533
Reviewed By: #clang-language-wg, erichkeane
Differential Revision: https://reviews.llvm.org/D151062
Decl::isInAnotherModuleUnit
Refactor `Sema::isModuleUnitOfCurrentTU` to `Decl::isInAnotherModuleUnit`
to make code simpler a little bit. Note that although this patch
introduces a FIXME, this is an existing issue and this patch just tries
to describe it explicitly.
even if its initializer has side effects
Close https://github.com/llvm/llvm-project/issues/61892
The variables whose initializer has side effects will be emitted even if
it is not used. But it shouldn't be true after we introduced modules.
The variables in other modules shouldn't be emitted if it is not used
even if its initializer has size effects.
Also this patch rename `Decl::isInCurrentModuleUnit` to
`Decl::isInAnotherModuleUnit` to make it closer to the semantics.
Decl::isInCurrentModuleUnit
Refactor `Sema::isModuleUnitOfCurrentTU` to `Decl::isInCurrentModuleUnit`
to make code simpler a little bit. Note that although this patch
introduces a FIXME, this is an existing issue and this patch just tries
to describe it explicitly.
isDeductionGuideName looks up the underlying template and if the template name
is qualified we miss that qualification resulting in an error. This issue
resurfaced in clang-repl where we call isDeductionGuideName more often to
distinguish between if we had a statement or declaration.
This patch passes the CXXScopeSpec information down to LookupTemplateName to
make the lookup more precise.
Differential revision: https://reviews.llvm.org/D147319
Sema.h is huge. This makes a small reduction to it by moving
EnterExpressionEvaluationContext into a new header, since it is an
independent component.
Differential Revision: https://reviews.llvm.org/D149796
(and deduced return types)
Previously, only type constraints applied to type parameter
were semantically checked.
A diagnostic would still be emitted on instantiation, but it was
too late, lacked clarity, and was inconsistent with type parameters.
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D147925
This follows C++ [temp.over.link]/6, which says that constraints are not
part of what determines whether two template parameters are equivalent.
This allows templates that have different constraints on nested template
template parameters to be ordered by their constraints.
Seemingly we never tested this, but the constraint on a NTTP was being
swtiched to the 'instantiated' version, but constraints need to be
relative to the 'top level', so this was causing us to not be able to
check the constraint on final use.
This patch corrects the issue by making the constraint created with the
un-instantiated version in the case of dependent constraint attachment.
Fixes: #61777
Close https://github.com/llvm/llvm-project/issues/56916
Within C++20 modules, we may have multiple same constructors in
multiple same RecordDecls. And it doesn't make sense naturally to create
duplicated deduction guides for the duplicated constructors.
**Summary**
This patch adds a `IsDefaulted` field to `clang::TemplateArgument`.
To prevent memory footprint increase we still 1 bit from `ArgKind`.
**Changes**
1. `getIsDefaulted`/`setIsDefaulted` to allow clients to communicate
an argument's defaulted-ness to the TypePrinter
2. The `TemplateArgument` properties description had to be changed
to make sure we correctly mark the defaulted-ness of arguments
that came from a deserialized AST (caught by the HLSL test-suite)
3. The `TemplateArgument` constructors now accept a `IsDefaulted`
parameter to simplify construction from the tablegen description.
Though if people don't want to clutter the constructors we can
instead call `setIsDefaulted` from tablegen
4. When `clang::Sema` checks the template arguments against template
parameters we now call `setIsDefaulted`. This makes sure that
whenever a specialization decl gets constructed, the defaulted-ness
of the associated `TemplateArgument`s has already been deduced.
This preserves the immutability of `TemplateArgumentList`s
**Background**
In LLDB we construct ASTs from debug-info and hand it to clang
to perform actions such as printing/formatting a typenames.
Some debug formats, specifically DWARF, may only encode information
about class template instantiations, losing the structure of the generic
class definition. However, the `clang::TypePrinter` needs a properly
constructed `ClassTemplateDecl` with generic default argument decls
to be able to deduce whether a `ClassTemplateSpecializationDecl` was
instantiatiated with `TemplateArgument`s that correspond to the
defaults. LLDB does know whether a particular template argument was
defaulted, but can't currently tell clang about it.
This patch allows LLDB to set the defaulted-ness of a `TemplateArgument`
and thus benefit more from `clang::TypePrinter`.
See discussion in https://reviews.llvm.org/D140423
**Testing**
* Added unit-test
* LLDB/clang/llvm test-suite passes
Differential Revision: https://reviews.llvm.org/D141826
This reverts commit e70ca7b353 and the
followup patch "[clang] Fix the location of UsingTypeLoc"
(ebbeb164c2).
The patch causes an incorrect lookup result:
```
namespace ns { struct Foo { };}
using ns::Foo;
void test() {
struct Foo {
} k; // the type of k refers to ns::Foo, rather than the local Foo!
}
```
Support building UsingType for elaborated type specifiers:
```
namespace ns { class Foo {}; }
using ns::Foo;
// The TypeLoc of `Foo` below should be a ElaboratedTypeLoc with an
// inner UsingTypeLoc rather than the underlying `CXXRecordTypeLoc`
class Foo foo;
```
Differential Revision: https://reviews.llvm.org/D141280
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2350.htm made very
clear that it is an UB having type definitions with in offsetof.
Clang supports defining a type as the first argument as a conforming
extension due to how many projects use the construct in C99 and earlier
to calculate the alignment of a type. GCC also supports defining a type
as the first argument.
This adds extension warnings and documentation for the functionality
Clang explicitly supports.
Fixes#57065
Reverts the revert of 39da55e8f5
Co-authored-by: Yingchi Long <i@lyc.dev>
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
Differential Revision: https://reviews.llvm.org/D133574
