When a template-name is looked up, we need to give injected-class-name
declarations of class templates special treatment, as they denote a
template rather than a type.
Previously we achieved this by applying a filter to the lookup results
after completing name lookup, but that is incorrect in various ways, not
least of which is that it lost all information about access and how
members were named, and the filtering caused us to generally lose
all ambiguity errors between templates and non-templates.
We now preserve the lookup results exactly, and the few places that need
to map from a declaration found by name lookup into a declaration of a
template do so explicitly. Deduplication of repeated lookup results of
the same injected-class-name declaration is done by name lookup instead
of after the fact.
This reinstates r354091, which was previously reverted in r354097
because it exposed bugs in lldb and compiler-rt. Those bugs were fixed
in r354173 and r354174 respectively.
llvm-svn: 354176
When a template-name is looked up, we need to give injected-class-name
declarations of class templates special treatment, as they denote a
template rather than a type.
Previously we achieved this by applying a filter to the lookup results
after completing name lookup, but that is incorrect in various ways, not
least of which is that it lost all information about access and how
members were named, and the filtering caused us to generally lose
all ambiguity errors between templates and non-templates.
We now preserve the lookup results exactly, and the few places that need
to map from a declaration found by name lookup into a declaration of a
template do so explicitly. Deduplication of repeated lookup results of
the same injected-class-name declaration is done by name lookup instead
of after the fact.
llvm-svn: 354091
When Clang/LLVM is built with the CLANG_DEFAULT_STD_CXX CMake macro that sets
the default standard to something other than C++14, there are a number of lit
tests that fail as they rely on the C++14 default.
This patch just adds the language standard option explicitly to such test cases.
Differential revision: https://reviews.llvm.org/D57581
llvm-svn: 353163
function declaration.
We'd previously often just drop these on the floor, and friend
redeclaration matching would usually (but not always) figure out the
right redeclaration anyway.
Also, don't try to match a dependent friend function template
specialization to a template until instantiation, and don't forget to
reject qualified friend declarations in dependent contexts that don't
name an already-declared entity.
llvm-svn: 350915
render the function deleted instead of rendering the program ill-formed.
This change also adds an enabled-by-default warning for the case where
an explicitly-defaulted special member function of a non-template class
is implicitly deleted by the type checking rules. (This fires either due
to this language change or due to pre-C++20 reasons for the member being
implicitly deleted). I've tested this on a large codebase and found only
bugs (where the program means something that's clearly different from
what the programmer intended), so this is enabled by default, but we
should revisit this if there are problems with this being enabled by
default.
llvm-svn: 343285
destructors.
We previously tried to patch up the exception specification after
completing the class, which went wrong when the exception specification
was needed within the class body (in particular, by a friend
redeclaration of the destructor in a nested class). We now mark the
destructor as having a not-yet-computed exception specification
immediately after creating it.
This requires delaying various checks against the exception
specification (where we'd previously have just got the wrong exception
specification, and now find we have an exception specification that we
can't compute yet) when those checks fire while the class is being
defined.
This also exposed an issue that we were missing a CodeSynthesisContext
for computation of exception specifications (otherwise we'd fail to make
the module containing the definition of the class visible when computing
its members' exception specs). Adding that incidentally also gives us a
diagnostic quality improvement.
This has also exposed an pre-existing problem: making the exception
specification evaluation context a non-SFINAE context (as it should be)
results in a bootstrap failure; PR38850 filed for this.
llvm-svn: 341499
Changes the default Windows target triple returned by
GetHostTriple.cmake from the old environment names (which we wanted to
move away from) to newer, normalized ones. This also requires updating
all tests to use the new systems names in constraints.
Differential Revision: https://reviews.llvm.org/D47381
llvm-svn: 339307
The dependent auto was getting stripped away while rebuilding the template
parameter type, so substitute it in.
rdar://41852459
Differential revision: https://reviews.llvm.org/D50088
llvm-svn: 339198
Recommit of r335084 after revert in r335516.
... instead of prepending it at the beginning (the original behavior
since implemented in r122535 2010-12-23). This builds up an
AttributeList in the the order in which the attributes appear in the
source.
The reverse order caused nodes for attributes in the AST (e.g. LoopHint)
to be in the reverse order, and therefore printed in the wrong order in
-ast-dump. Some TODO comments mention this. The order was explicitly
reversed for enable_if attribute overload resolution and name mangling,
which is not necessary anymore with this patch.
The change unfortunately has some secondary effect, especially on
diagnostic output. In the simplest cases, the CHECK lines or expected
diagnostic were changed to the the new output. If the kind of
error/warning changed, the attributes' order was changed instead.
This unfortunately causes some 'previous occurrence here' hints to be
textually after the main marker. This typically happens when attributes
are merged, but are incompatible to each other. Interchanging the role
of the the main and note SourceLocation will also cause the case where
two different declaration's attributes (in contrast to multiple
attributes of the same declaration) are merged to be reverse. There is
no easy fix because sometimes previous attributes are merged into a new
declaration's attribute list, sometimes new attributes are added to a
previous declaration's attribute list. Since 'previous occurrence here'
pointing to locations after the main marker is not rare, I left the
markers as-is; it is only relevant when the attributes are declared in
the same declaration anyway.
Differential Revision: https://reviews.llvm.org/D48100
llvm-svn: 338800
provided by an outer template.
We made the incorrect assumption in various places that the only way we
can have any arguments already provided for a pack during template
argument deduction was from a partially-specified pack. That's not true;
we can also have arguments from an enclosing already-instantiated
template, and that can even result in the function template's own pack
parameters having a fixed length and not being packs for the purposes of
template argument deduction.
llvm-svn: 337481
binary operator.
Factor out the checking for a comma within potential angle brackets and
also call it from contexts where we parse a comma-separated list of
arguments or initializers.
llvm-svn: 335699
We track when we see a name-shaped expression followed by a '<' token
and parse the '<' as a comparison. Then:
* if we see a token sequence that cannot possibly be an expression but
can be a template argument (in particular, a type-id) that follows
either a ',' or the '<', diagnose that the '<' was supposed to start
a template argument list, and
* if we see '>()', diagnose that the '<' was supposed to start a
template argument list.
This only changes the diagnostic for error cases, and in practice
appears to catch the most common cases where a missing 'template'
keyword leads to parse errors within a template.
Differential Revision: https://reviews.llvm.org/D48571
llvm-svn: 335687
... instead of prepending it at the beginning (the original behavior
since implemented in r122535 2010-12-23). This builds up an
AttributeList in the the order in which the attributes appear in the
source.
The reverse order caused nodes for attributes in the AST (e.g. LoopHint)
to be in the reverse, and therefore printed in the wrong order by
-ast-dump. Some TODO comments mention this. The order was explicitly
reversed for enable_if attribute overload resolution and name mangling,
which is not necessary anymore with this patch.
The change unfortunately has some secondary effects, especially for
diagnostic output. In the simplest cases, the CHECK lines or expected
diagnostic were changed to the the new output. If the kind of
error/warning changed, the attribute's order was changed instead.
It also causes some 'previous occurrence here' hints to be textually
after the main marker. This typically happens when attributes are
merged, but are incompatible. Interchanging the role of the the main
and note SourceLocation will also cause the case where two different
declaration's attributes (in contrast to multiple attributes of the
same declaration) are merged to be reversed. There is no easy fix
because sometimes previous attributes are merged into a new
declaration's attribute list, sometimes new attributes are added to a
previous declaration's attribute list. Since 'previous occurrence here'
pointing to locations after the main marker is not rare, I left the
markers as-is; it is only relevant when the attributes are declared in
the same declaration anyway, which often is on the same line.
Differential Revision: https://reviews.llvm.org/D48100
llvm-svn: 335084
When looking up a template name, we can find an overload set containing a
function template and an unresolved non-type using declaration.
llvm-svn: 334106
The added test case was triggering assertion
> Assertion failed: (!SpecializedTemplate.is<SpecializedPartialSpecialization*>() && "Already set to a class template partial specialization!"), function setInstantiationOf, file clang/include/clang/AST/DeclTemplate.h, line 1825.
It was happening with ClassTemplateSpecializationDecl
`enable_if_not_same<int, int>`. Because this template is specialized for
equal types not to have a definition, it wasn't instantiated and its
specialization kind remained TSK_Undeclared. And because it was implicit
instantiation, we didn't mark the decl as invalid. So when we try to
find the best matching partial specialization the second time, we hit
the assertion as partial specialization is already set.
Fix by reusing stored partial specialization when available, instead of
looking for the best match every time.
rdar://problem/39524996
Reviewers: rsmith, arphaman
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D46909
llvm-svn: 332509
After a fatal error Sema::InstantiatingTemplate doesn't allow further
instantiation and doesn't push a CodeSynthesisContext. When we tried to
synthesize implicit deduction guides from constructors we hit the
assertion
> Assertion failed: (!CodeSynthesisContexts.empty() && "Cannot perform an instantiation without some context on the " "instantiation stack"), function SubstType, file clang/lib/Sema/SemaTemplateInstantiate.cpp, line 1580.
Fix by avoiding deduction guide synthesis if InstantiatingTemplate is invalid.
rdar://problem/39051732
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D46446
llvm-svn: 332307
If the name after 'template' is an unresolved using declaration (not containing
'typename'), then we don't yet know if it's a valid template-name, so don't
reject it prior to instantiation. Instead, treat it as naming a dependent
member of the current instantiation.
llvm-svn: 332291
For 'x::template y', consistently give a "no member named 'y' in 'x'"
diagnostic if there is no such member, and give a 'template keyword not
followed by a template' name error if there is such a member but it's not a
template. In the latter case, add a note pointing at the non-template.
Don't suggest inserting a 'template' keyword in 'X::Y<' if X is dependent
if the lookup of X::Y was actually not a dependent lookup and found only
non-templates.
llvm-svn: 332076
I found that explicit template parameters that caused a
narrowing integer conversion resulted in the incorrect parameter
being mentioned in the note (see test attached). This is because
the argument checking code doesn't check to see if it caused
SFINAE errors when checking the arguments, so instead of giving
up on the first error, it continues through the list. This
makes the error reporting pick up the last template param every time.
This patch checks these parameters on each argument and gives up
if there is an error. The result is that only the required amount
of arguments are checked, and that the 'Converted' array contains
only the successful arguments before the first failure, as the
calls seem to all expect.
llvm-svn: 331651
template arguments.
This fixes some cases where we'd incorrectly accept "A::template B" when B is a
kind of template that requires template arguments (in particular, a variable
template or a concept).
llvm-svn: 331013
The diagnostic system for Clang can already handle many AST nodes. Instead
of converting them to strings first, just hand the AST node directly to
the diagnostic system and let it handle the output. Minor changes in some
diagnostic output.
llvm-svn: 328688
Summary:
This fixes PR33561 and PR34185.
Don't store pending template instantiations for late-parsed templates in
the normal PendingInstantiations queue. Instead, use a separate list
that will only be parsed and instantiated at end of TU when late
template parsing actually works and doesn't infinite loop.
Reviewers: rsmith, thakis, hans
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D44846
llvm-svn: 328567
More generally, this permits a template to be specialized in any scope in which
it could be defined, so this also supersedes DR44 and DR374 (the latter of
which we previously only implemented in C++11 mode onwards due to unclarity as
to whether it was a DR).
llvm-svn: 327705
template parameter that is an expanded parameter pack, only substitute into the
current slice, not the entire pack.
This reduces the checking of N template template arguments for an expanded
parameter pack containing N parameters from quadratic time to linear time in
the length of the pack. This is important because one (and possibly the only?)
general technique for splitting a template parameter pack in linear time
depends on doing this.
llvm-svn: 326973
When we synthesize an implicit inner initializer list when analyzing an outer
initializer list, we add it to the outer list immediately, and then fill in the
inner list. This gives the outer list no chance to update its *-dependence bits
with those of the completed inner list. To fix this, re-add the inner list to
the outer list once it's completed.
Note that we do not recompute the *-dependence bits from scratch when we
complete an outer list; this would give the wrong result for the case where a
designated initializer overwrites a dependent initializer with a non-dependent
one. The resulting list in that case should still be dependent, even though all
traces of the dependence were removed from the semantic form.
llvm-svn: 324537
We could in principle support such pack expansion, using techniques similar to
what we do for pack expansion of lambdas, but it's not clear it's worthwhile.
For now at least, cleanly reject these cases rather than crashing.
llvm-svn: 324160
each kind.
Attribute instantiation would previously default to instantiating each kind of
attribute only once. This was overridden by a flag whose intended purpose was
to permit attributes from a prior declaration to be inherited onto a new
declaration even if that new declaration had its own copy of the attribute.
This is the wrong behavior: when instantiating attributes from a template, we
should always instantiate all the attributes that were written on that
template.
This patch renames the flag in the Attr class (and TableGen sources) to more
clearly identify what it's actually for, and removes the usage of the flag from
template instantiation. I also removed the flag from AlignedAttr, which was
only added to work around the incorrect suppression of duplicate attribute
instantiation.
llvm-svn: 321834
The way to fix an undefined-template warning is to add lines to the header file that defines the template pattern. We should suppress the warnings when the template pattern is in a system header because we don't expect users to edit those.
llvm-svn: 321665
An unscoped enumeration used as template argument, should not have any
qualified information about its enclosing scope, as its visibility is
global.
In the case of scoped enumerations, they must include information
about their enclosing scope.
Patch by Carlos Alberto Enciso!
Differential Revision: https://reviews.llvm.org/D39239
llvm-svn: 321312
This allows you to dump C++ code that spells bool instead of _Bool, leaves off the elaborated type specifiers when printing struct or class names, and other C-isms.
Fixes the -Wreorder issue and fixes the ast-dump-color.cpp test.
llvm-svn: 321310
This allows you to dump C++ code that spells bool instead of _Bool, leaves off the elaborated type specifiers when printing struct or class names, and other C-isms.
llvm-svn: 321223
update the type from the definition even if we didn't instantiate a definition.
We may have instantiated the definition in an earlier stage of semantic
analysis, after creating the DeclRefExpr but before we reach a point where a
complete expression type is required.
llvm-svn: 320709
Adding the new enumerator forced a bunch more changes into this patch than I
would have liked. The -Wtautological-compare warning was extended to properly
check the new comparison operator, clang-format needed updating because it uses
precedence levels as weights for determining where to break lines (and several
operators increased their precedence levels with this change), thread-safety
analysis needed changes to build its own IL properly for the new operator.
All "real" semantic checking for this operator has been deferred to a future
patch. For now, we use the relational comparison rules and arbitrarily give
the builtin form of the operator a return type of 'void'.
llvm-svn: 320707
Reid Kleckner