This patch reapplies commit 759948467e. Patch was reverted due to a
clang-tidy test fail on Windows. The test has been modified. There
are no additional code changes.
Patch was tested with ninja check-all on Windows and Linux.
Summary of code changes:
Clang currently crashes for switch statements inside a template when the
condition is a non-integer field member because contextual implicit
conversion is skipped when parsing the condition. This conversion is
however later checked in an assert when the case statement is handled.
The conversion is skipped when parsing the condition because
the field member is set as type-dependent based on its containing class.
This patch sets the type dependency based on the field's type instead.
This patch fixes Bug 40982.
This patch reapplies commit 76945821b9. The first version broke
buildbots due to clang-tidy test fails. The fails are because some
errors in templates are now diagnosed earlier (does not wait till
instantiation). I have modified the tests to add checks for these
diagnostics/prevent these diagnostics. There are no additional code
changes.
Summary of code changes:
Clang currently crashes for switch statements inside a template when the
condition is a non-integer field member because contextual implicit
conversion is skipped when parsing the condition. This conversion is
however later checked in an assert when the case statement is handled.
The conversion is skipped when parsing the condition because
the field member is set as type-dependent based on its containing class.
This patch sets the type dependency based on the field's type instead.
This patch fixes Bug 40982.
Reviewers: rnk, gribozavr2
Patch by: Elizabeth Andrews (eandrews)
Differential revision: https://reviews.llvm.org/D69950
The issue was introduced by D33189 which fixed PR33189.
Fixes PR38671: "destructor cannot be declared as a template" leads to segfault in Sema::LookupSpecialMember
Differential Revision: https://reviews.llvm.org/D69225
parameter type.
We were both failing to decay the array type to a pointer and failing to
remove the top-level cv-qualifications. Fix this by decaying array
parameters even if the parameter type is dependent.
llvm-svn: 374496
We previously failed to treat an array with an instantiation-dependent
but not value-dependent bound as being an instantiation-dependent type.
We now track the array bound expression as part of a constant array type
if it's an instantiation-dependent expression.
llvm-svn: 373685
of 'typeid'.
This is a rare place where it's valid for a function type to be
substituted but not valid for a qualified function type to be
substituted, so needs a special check.
llvm-svn: 373648
Fixes PR35682. When a template in instantiated with an incomplete typo corrected type an assertion can trigger if the -ferror-limit is used to reduce the number of errors.
Patch by Mark de Wever.
llvm-svn: 371320
containing designators. The C++20 wording doesn't actually say what
happens in this case, but treating this as a non-deduced context seems
like the most natural behavior.
(We might want to consider deducing through array designators as an
extension in the future, but will need to be careful to deduce the array
bound properly if we do so. That's not permitted herein.)
llvm-svn: 370555
initializers.
This has some interesting interactions with our existing extensions to
support C99 designated initializers as an extension in C++. Those are
resolved as follows:
* We continue to permit the full breadth of C99 designated initializers
in C++, with the exception that we disallow a partial overwrite of an
initializer with a non-trivially-destructible type. (Full overwrite
is OK, because we won't run the first initializer at all.)
* The C99 extensions are disallowed in SFINAE contexts and during
overload resolution, where they could change the meaning of valid
programs.
* C++20 disallows reordering of initializers. We only check for that for
the simple cases that the C++20 rules permit (designators of the form
'.field_name =' and continue to allow reordering in other cases).
It would be nice to improve this behavior in future.
* All C99 designated initializer extensions produce a warning by
default in C++20 mode. People are going to learn the C++ rules based
on what Clang diagnoses, so it's important we diagnose these properly
by default.
* In C++ <= 17, we apply the C++20 rules rather than the C99 rules, and
so still diagnose C99 extensions as described above. We continue to
accept designated C++20-compatible initializers in C++ <= 17 silently
by default (but naturally still reject under -pedantic-errors).
This is not a complete implementation of P0329R4. In particular, that
paper introduces new non-C99-compatible syntax { .field { init } }, and
we do not support that yet.
This is based on a previous patch by Don Hinton, though I've made
substantial changes when addressing the above interactions.
Differential Revision: https://reviews.llvm.org/D59754
llvm-svn: 370544
Summary:
Clang performs various recursive operations (such as template instantiation),
and may use non-trivial amounts of stack space in each recursive step (for
instance, due to recursive AST walks). While we try to keep the stack space
used by such steps to a minimum and we have explicit limits on the number of
such steps we perform, it's impractical to guarantee that we won't blow out the
stack on deeply recursive template instantiations on complex ASTs, even with
only a moderately high instantiation depth limit.
The user experience in these cases is generally terrible: we crash with
no hint of what went wrong. Under this patch, we attempt to do better:
* Detect when the stack is nearly exhausted, and produce a warning with a
nice template instantiation backtrace, telling the user that we might
run slowly or crash.
* For cases where we're forced to trigger recursive template
instantiation in arbitrarily-deeply-nested contexts, check whether
we're nearly out of stack space and allocate a new stack (by spawning
a new thread) after producing the warning.
Reviewers: rnk, aaron.ballman
Subscribers: mgorny, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66361
llvm-svn: 369940
default template argument expression.
We already did this for type template parameters and template template
parameters, but apparently forgot to do so for non-type template
parameters. This causes the substituted default argument expression to
be substituted in the proper context, and in particular to properly mark
its subexpressions as odr-used.
llvm-svn: 369834
Clang currently crashes for switch statements inside a template when
the condition is a non-integer field. The crash is due to incorrect
type-dependency of field. Type-dependency of member expressions is
currently set based on the containing class. This patch changes this for
'members of the current instantiation' to set the type dependency based
on the member's type instead.
A few lit tests started to fail once I applied this patch because errors
are now diagnosed earlier (does not wait till instantiation). I've modified
these tests in this patch as well.
Patch fixes PR#40982
Differential Revision: https://reviews.llvm.org/D61027
llvm-svn: 368706
As discussed in D64780 the wording of this warning message is being
changed to say 'is not supported' instead of 'ignored', and the
diag ID itself is being changed to warn_cconv_not_supported.
llvm-svn: 366368
Summary:
This case is particularly important for clangd, as it is triggered after
inserting the snippet for variadic functions.
Reviewers: kadircet, ilya-biryukov
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D64677
llvm-svn: 366200
type-dependent argument packs.
We need to strip off the PackExpansionExpr to get the real (dependent)
type rather than an opaque DependentTy.
llvm-svn: 364165
template argument contains a backreference to a dependently-typed
earlier parameter.
In a case like:
template<typename T, T A, decltype(A) = A> struct X {};
template<typename U> auto Y = X<U, 0>();
we previously treated both references to `A` in the third parameter as
being of type `int` when checking the template-id in `Y`. That`s wrong;
the type of `A` in these contexts is the dependent type `U`.
When we encounter a non-type template argument that we can't convert to
the parameter type because of type-dependence, we now insert a dependent
conversion node so that the SubstNonTypeTemplateParmExpr for the
template argument will have the parameter's type rather than whatever
type the argument had.
llvm-svn: 363972
packs.
Two changes:
* Track odr-use via FunctionParmPackExprs to properly handle dependent
odr-uses of packs in generic lambdas.
* Do not instantiate implicit captures; instead, regenerate them by
instantiating the body of the lambda. This is necessary to
distinguish between cases where only one element of a pack is
captured and cases where the entire pack is captured.
This reinstates r362358 (reverted in r362375) with a fix for an
uninitialized variable use in UpdateMarkingForLValueToRValue.
llvm-svn: 362531
Two changes:
* Track odr-use via FunctionParmPackExprs to properly handle dependent
odr-uses of packs in generic lambdas.
* Do not instantiate implicit captures; instead, regenerate them by
instantiating the body of the lambda. This is necessary to
distinguish between cases where only one element of a pack is
captured and cases where the entire pack is captured.
........
Fixes http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win buildbot failures
llvm-svn: 362375
packs.
Two changes:
* Track odr-use via FunctionParmPackExprs to properly handle dependent
odr-uses of packs in generic lambdas.
* Do not instantiate implicit captures; instead, regenerate them by
instantiating the body of the lambda. This is necessary to
distinguish between cases where only one element of a pack is
captured and cases where the entire pack is captured.
llvm-svn: 362358
This permits an init-capture to introduce a new pack:
template<typename ...T> auto x = [...a = T()] { /* a is a pack */ };
To support this, the mechanism for allowing ParmVarDecls to be packs has
been extended to support arbitrary local VarDecls.
llvm-svn: 361300
(and less wrong).
It's not correct to assume that X<something, Type> is always a
template-id; there are a few cases where the comma takes us into a
non-expression syntactic context in which 'Type' might be permissible.
Stop doing that.
This slightly regresses our error recovery on the cases where the
construct is intended to be a template-id. We typically do still manage
to diagnose a missing 'template' keyword, but we realize this too late
to properly recover from the error.
This fixes a regression introduced by r360308.
llvm-svn: 360827
template name is not visible to unqualified lookup.
In order to support this without a severe degradation in our ability to
diagnose typos in template names, this change significantly restructures
the way we handle template-id-shaped syntax for which lookup of the
template name finds nothing.
Instead of eagerly diagnosing an undeclared template name, we now form a
placeholder template-name representing a name that is known to not find
any templates. When the parser sees such a name, it attempts to
disambiguate whether we have a less-than comparison or a template-id.
Any diagnostics or typo-correction for the name are delayed until its
point of use.
The upshot should be a small improvement of our diagostic quality
overall: we now take more syntactic context into account when trying to
resolve an undeclared identifier on the left hand side of a '<'. In
fact, this works well enough that the backwards-compatible portion (for
an undeclared identifier rather than a lookup that finds functions but
no function templates) is enabled in all language modes.
llvm-svn: 360308
After https://reviews.llvm.org/rL355317 we noticed that quite a decent
amount of code redeclares builtins (memcpy in particular, I believe
reduced from an MSVC header) with a calling convention specified.
This gets particularly troublesome when the user specifies a new
'default' calling convention on the command line.
When looking to add a diagnostic for this case, it was noticed that we
had 3 other diagnostics that differed only slightly. This patch ALSO
unifies those under a 'select'. Unfortunately, the order of words in
ONE of these diagnostics was reversed ("'thiscall' calling convention"
vs "calling convention 'thiscall'"), so this patch also standardizes on
the former.
Differential Revision: https://reviews.llvm.org/D59560
Change-Id: I79f99fe7c2301640755ffdd774b46eb44526bb22
llvm-svn: 356663
Before this commit, we emit unavailable errors for calls to functions during
overload resolution, and for references to all other declarations in
DiagnoseUseOfDecl. The early checks during overload resolution aren't as good as
the DiagnoseAvailabilityOfDecl based checks, as they error on the code from
PR40991. This commit fixes this by removing the early checking.
llvm.org/PR40991
rdar://48564179
Differential revision: https://reviews.llvm.org/D59394
llvm-svn: 356599
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
of its argument, perform function-to-pointer and array-to-pointer decay on the
parameter type first.
Otherwise deduction will fail, as the type of the argument will be decayed.
llvm-svn: 319584
deduction for invalid functions
The fabricated template parameters cause an assertion because their depth
is invalid.
rdar://34109988
Differential Revision: https://reviews.llvm.org/D37341
llvm-svn: 316778
constant expressions.
We permit array-to-pointer decay on such arrays, but disallow pointer
arithmetic (since we do not know whether it will have defined behavior).
This is based on r311970 and r301822 (the former by me and the latter by Robert
Haberlach). Between then and now, two things have changed: we have committee
feedback indicating that this is indeed the right direction, and the code
broken by this change has been fixed.
This is necessary in C++17 to continue accepting certain forms of non-type
template argument involving arrays of unknown bound.
llvm-svn: 316245
instantiation declarations if they are usable from constant expressions.
We are permitted to instantiate in these cases, and required to do so in order
to have an initializer available for use within constant evaluation.
llvm-svn: 316136
Currently Clang uses default address space (0) to represent private address space for OpenCL
in AST. There are two issues with this:
Multiple address spaces including private address space cannot be diagnosed.
There is no mangling for default address space. For example, if private int* is emitted as
i32 addrspace(5)* in IR. It is supposed to be mangled as PUAS5i but it is mangled as
Pi instead.
This patch attempts to represent OpenCL private address space explicitly in AST. It adds
a new enum LangAS::opencl_private and adds it to the variable types which are implicitly
private:
automatic variables without address space qualifier
function parameter
pointee type without address space qualifier (OpenCL 1.2 and below)
Differential Revision: https://reviews.llvm.org/D35082
llvm-svn: 315668
Modifying a non-type template integer arguement that is causing errors
in some builds as it's too large for 32-bit longs. This hopefully (and
seems to when testing) should fix all of the build bot errors relating
to this test. I also modified the name of the function call to be more
apt.
Differential Revision: https://reviews.llvm.org/D33666
llvm-svn: 314668
Adding regression test for Dependent Address Spaces in relation to
https://reviews.llvm.org/D33666 I forgot to svn add the test file
before commiting the prior changes. I appologies.
llvm-svn: 314650
This implements the proposed approach in https://github.com/itanium-cxx-abi/cxx-abi/issues/33
This reinstates r313827, reverted in r313856, with a fix for the 'out-of-bounds
enumeration value' ubsan error in that change.
llvm-svn: 313955
Sema::InstantiateClass should check only exception specs added during
class instantiation and ignore already present delayed specs. This fixes
a case where we instantiate a class before parsing member initializers,
check exceptions for a different class and fail to find a member
initializer. Which is required for comparing exception specs for
explicitly-defaulted and implicit default constructor. With the fix we
are still checking exception specs but only after member initializers
are present.
Removing errors in crash-unparsed-exception.cpp is acceptable according
to discussion in PR24000 because other compilers accept code in
crash-unparsed-exception.cpp as valid.
rdar://problem/34167492
Reviewers: davide, rsmith
Reviewed By: rsmith
Subscribers: dim, cfe-commits
Differential Revision: https://reviews.llvm.org/D37881
llvm-svn: 313906
When enable_if disables a particular overload resolution candidate,
rummage through the enable_if condition to find the specific condition
that caused the failure. For example, if we have something like:
template<
typename Iter,
typename = std::enable_if_t<Random_access_iterator<Iter> &&
Comparable<Iterator_value_type<Iter>>>>
void mysort(Iter first, Iter last) {}
and we call "mysort" with "std::list<int>" iterators, we'll get a
diagnostic saying that the "Random_access_iterator<Iter>" requirement
failed. If we call "mysort" with
"std::vector<something_not_comparable>", we'll get a diagnostic saying
that the "Comparable<...>" requirement failed.
llvm-svn: 307196
Summary:
This patch aims to fix the bug reported at
https://bugs.llvm.org/show_bug.cgi?id=33189. Clang hits an assertion
when a template destructor declaration is present. This is caused by
later processing that does not expect to encounter a template when
looking at a destructor. The resolution is to treat the destructor as
being not declared when later processing is interested in the properties
of the destructor of a class.
Reviewers: rcraik, hubert.reinterpretcast, aaron.ballman, rsmith
Reviewed By: rsmith
Subscribers: rsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D33833
Patch by Kuang He!
llvm-svn: 306905
This is not required by the standard (yet), but there seems to be reasonable
support for this being a defect according to CWG discussion, and libstdc++ 7.1
relies on it working.
llvm-svn: 304946
template is valid with or without it (with different meanings).
If we see "dependent.x<...", and what follows the '<' is a valid expression,
we must parse the '<' as a comparison rather than a template angle bracket.
When we later come to instantiate, if we find that the LHS of the '<' actually
names an overload set containing function templates, produce a diagnostic
suggesting that the 'template' keyword was missed rather than producing a
mysterious diagnostic saying that the function must be called (and pointing
at what looks to already be a function call!).
llvm-svn: 304852
template partial specialization.
In passing, fix the deduction-crash.cpp test to actually run all the tests. Due
to a typo, the last third of the file was being skipped by the parser and some
of the tests were not actually testing anything as a result. Switch from
FileCheck to -verify to make the problem more obvious and prevent this
happening again.
llvm-svn: 304604
When an undeclared identifier in a context that requires a type is followed by
'<', only look for type templates when typo-correcting, tweak the diagnostic
text to say that a template name (not a type name) was undeclared, and parse
the template arguments when recovering from the error.
llvm-svn: 302732
The heuristic that we use here is:
* the left-hand side must be a simple identifier or a class member access
* the right-hand side must be '<' followed by either a '>' or by a type-id that
cannot be an expression (in particular, not followed by '(' or '{')
* there is a '>' token matching the '<' token
The second condition guarantees the expression would otherwise be ill-formed.
If we're confident that the user intended the name before the '<' to be
interpreted as a template, diagnose the fact that we didn't interpret it
that way, rather than diagnosing that the template arguments are not valid
expressions.
llvm-svn: 302615
This improves our behavior in a few ways:
* We now guarantee that if a member is marked as being a member
specialization, there will actually be a member specialization declaration
somewhere on its redeclaration chain. This fixes a crash in modules builds
where we would try to check that there was a visible declaration of the
member specialization and be surprised to not find any declaration of it at
all.
* We don't set the source location of the in-class declaration of the member
specialization to the out-of-line declaration's location until we have
actually finished merging them. This fixes some very silly looking
diagnostics, where we'd point a "previous declaration is here" note at the
same declaration we're complaining about. Ideally we wouldn't mess with the
prior declaration's location at all, but too much code assumes that the
first declaration of an entity is a reasonable thing to use as an indication
of where it was declared, and that's not really true for a member
specialization unless we fake it like this.
llvm-svn: 302596
The code implements Richard Smith suggestion in comment 3 of the PR.
reviewer: Vassil Vassilev
Differential Revision: https://reviews.llvm.org/D31540
llvm-svn: 300443
This reverts an attempt to check that types match when matching a
dependently-typed non-type template parameter. (This comes up when matching the
parameters of a template template parameter against the parameters of a
template template argument.)
The matching rules here are murky at best. Our behavior after this revert is
definitely wrong for certain C++17 features (for 'auto' template parameter
types within the parameter list of a template template argument in particular),
but our behavior before this revert is wrong for some pre-existing testcases,
so reverting to our prior behavior seems like our best option.
llvm-svn: 300262
Printing typedefs or type aliases using clang_getTypeSpelling() is missing the
namespace they are defined in. This is in contrast to other types that always
yield the full typename including namespaces.
Patch by Michael Reiher!
Differential Revision: https://reviews.llvm.org/D29944
llvm-svn: 297465
compiler is run in a mode where the default C++ standard is newer than C++03.
The reason is because one of the warnings checked is only produced when the
compiler is using C++03 or lower.
This change fixes this problem as well as adds explicit run lines to run the
test in C++03 and C++11 modes.
llvm-svn: 296066
A 'decltype(auto)' parameter can match any other kind of non-type template
parameter, so should be usable in place of any other parameter in a template
template argument. The standard is sadly extremely unclear on how this is
supposed to work, but this seems like the obviously-correct result.
It's less clear whether an 'auto' parameter should be able to match
'decltype(auto)', since the former cannot be used if the latter turns out to be
used for a reference type, but if we disallow that then consistency suggests we
should also disallow 'auto' matching 'T' for the same reason, defeating
intended use cases of the feature.
llvm-svn: 295866
We need to look through the PackExpansionType in the parameter type when
deducing, and we need to consider the possibility of deducing arguments for
packs that are not lexically mentioned in the pattern (but are nonetheless
deducible) when figuring out which packs are covered by a pack deduction scope.
llvm-svn: 295790
template deduction guides for class template argument deduction.
Ensure that we have a local instantiation scope for tracking the instantiated
parameters. Additionally, unusually, we're substituting at depth 1 and leaving
depth 0 alone; make sure that we don't reduce template parameter depth by 2 for
inner parameters in the process. (This is probably also broken for alias
templates in the case where they're expanded within a dependent context, but
this patch doesn't fix that.)
llvm-svn: 295696
This appears to be the only template argument deduction context where we were
missing this check. Surprisingly, other implementations also appear to miss
the check in this case; it may turn out that important code is relying on
the widespread non-conformance here, in which case we'll need to reconsider.
llvm-svn: 295277
that has been explicitly specialized!
We assume in various places that we can tell the template specialization kind
of a class type by looking at the declaration produced by TagType::getDecl.
That was previously not quite true: for an explicit specialization, we could
have first seen a template-id denoting the specialization (with a use that does
not trigger an implicit instantiation of the defintiion) and then seen the
first explicit specialization declaration. TagType::getDecl would previously
return an arbitrary declaration when called on a not-yet-defined class; it
now consistently returns the most recent declaration in that case.
llvm-svn: 295118
This change adds a new type node, DeducedTemplateSpecializationType, to
represent a type template name that has been used as a type. This is modeled
around AutoType, and shares a common base class for representing a deduced
placeholder type.
We allow deduced class template types in a few more places than the standard
does: in conditions and for-range-declarators, and in new-type-ids. This is
consistent with GCC and with discussion on the core reflector. This patch
does not yet support deduced class template types being named in typename
specifiers.
llvm-svn: 293207
Under this defect resolution, the injected-class-name of a class or class
template cannot be used except in very limited circumstances (when declaring a
constructor, in a nested-name-specifier, in a base-specifier, or in an
elaborated-type-specifier). This is apparently done to make parsing easier, but
it's a pain for us since we don't know whether a template-id using the
injected-class-name is valid at the point when we annotate it (we don't yet
know whether the template-id will become part of an elaborated-type-specifier).
As a tentative resolution to a perceived language defect, mem-initializer-ids
are added to the list of exceptions here (they generally follow the same rules
as base-specifiers).
When the reference to the injected-class-name uses the 'typename' or 'template'
keywords, we permit it to be used to name a type or template as an extension;
other compilers also accept some cases in this area. There are also a couple of
corner cases with dependent template names that we do not yet diagnose, but
which will also get this treatment.
llvm-svn: 292518
The rules around typechecking deduced template arguments during partial
ordering are not clear, and while the prior behavior does not seem to be
correct (it doesn't follow the general model of partial ordering where each
template parameter is replaced by a non-dependent but unique value), the new
behavior is also not clearly right and breaks some existing idioms.
The new behavior is retained for dealing with non-type template parameters
with 'auto' types, as without it even the most basic uses of that feature
don't work. We can revisit this once CWG has come to an agreement on how
partial ordering with 'auto' non-type template parameters is supposed to
work.
llvm-svn: 292183
properly even when a non-type template parameter has a dependent type.
Previously, if a non-type template parameter was dependent, but not dependent
on an outer level of template parameter, we would not match the type of the
parameter. Under [temp.arg.template], we are supposed to check that the types
are equivalent, which means checking for syntactic equivalence in the dependent
case.
This also fixes some accepts-invalids when passing templates with auto-typed
non-type template parameters as template template arguments.
llvm-svn: 291512
Check for implicit conversion sequences for non-dependent function
template parameters between deduction and substitution. The idea is to accept
as many cases as possible, on the basis that substitution failure outside the
immediate context is much more common during substitution than during implicit
conversion sequence formation.
This re-commits r290808, reverted in r290811 and r291412, with a couple of
fixes for handling of explicitly-specified non-trailing template argument
packs.
llvm-svn: 291427
This issue clarifies how deduction proceeds past a non-trailing function
parameter pack. Essentially, the pack itself is skipped and consumes no
arguments (except for those implied by an explicitly-specified template
arguments), and nothing is deduced from it. As a small fix to the standard's
rule, we do not allow subsequent deduction to change the length of the function
parameter pack (by preventing extension of the explicitly-specified pack if
present, and otherwise deducing all contained packs to empty packs).
llvm-svn: 291425
Check for implicit conversion sequences for non-dependent function
template parameters between deduction and substitution. The idea is to accept
as many cases as possible, on the basis that substitution failure outside the
immediate context is much more common during substitution than during implicit
conversion sequence formation.
This re-commits r290808, reverted in r290811, with a fix for handling of
explicitly-specified template argument packs.
llvm-svn: 291410
deduction in partial ordering.
This prevents us from crashing due to attempting to instantiate the same class
template specialization definition multiple times. (Debug builds also appear to
sometimes hit the stack limit before hitting the instantiation depth limit in
this case.)
llvm-svn: 291407
This implements something like the current direction of DR1581: we use a narrow
syntactic check to determine the set of places where a constant expression
could be evaluated, and only instantiate a constexpr function or variable if
it's referenced in one of those contexts, or is odr-used.
It's not yet clear whether this is the right set of syntactic locations; we
currently consider all contexts within templates that would result in odr-uses
after instantiation, and contexts within list-initialization (narrowing
conversions take another victim...), as requiring instantiation. We could in
principle restrict the former cases more (only const integral / reference
variable initializers, and contexts in which a constant expression is required,
perhaps). However, this is sufficient to allow us to accept libstdc++ code,
which relies on GCC's behavior (which appears to be somewhat similar to this
approach).
llvm-svn: 291318
We were previously incorrectly using TDK_TooFewArguments to report a template
argument list that's too short, but it actually means that the number of
arguments in a top-level function call was insufficient. When diagnosing the
problem, SemaOverload would (rightly) assert that the failure kind didn't make
any sense.
llvm-svn: 291064
When a parameter pack has multiple corresponding arguments, and some subset of
them are overloaded functions, it's possible that some subset of the parameters
are non-deduced contexts. In such a case, keep deducing from the remainder of
the arguments, and resolve the incomplete pack against whatever other
deductions we've performed for the pack.
GCC, MSVC, and ICC give three different bad behaviors for this case; what we do
now (and what we did before) don't exactly match any of them, sadly :( I'm
getting a core issue opened to specify more precisely how this should be
handled.
llvm-svn: 290923
to be specified for a template template parameter whenever the parameter is at
least as specialized as the argument (when there's an obvious and correct
mapping from uses of the parameter to uses of the argument). For example, a
template with more parameters can be passed to a template template parameter
with fewer, if those trailing parameters have default arguments.
This is disabled by default, despite being a DR resolution, as it's fairly
broken in its current state: there are no partial ordering rules to cope with
template template parameters that have different parameter lists, meaning that
code that attempts to decompose template-ids based on arity can hit unavoidable
ambiguity issues.
The diagnostics produced on a non-matching argument are also pretty bad right
now, but I aim to improve them in a subsequent commit.
llvm-svn: 290792
to make reference to template parameters. This is only a partial
implementation; we retain the restriction that the argument must not be
type-dependent, since it's unclear how that would work given the existence of
other language rules requiring an exact type match in this context, even for
type-dependent cases (a question has been raised on the core reflector).
llvm-svn: 290647
specialized than the primary template. (Put another way, if we imagine there
were a partial specialization matching the primary template, we should never
select it if some other partial specialization also matches.)
llvm-svn: 290593
template parameters of reference type basically doesn't work, because we're
always deducing from an argument expression of non-reference type, so the type
of the deduced expression never matches. Instead, compare the type of an
expression naming the parameter to the type of the argument.
llvm-svn: 290586
dependent contexts when processing the template in C++11 and C++14, just like
we do in C++98 and C++1z. This allows us to diagnose invalid templates earlier.
llvm-svn: 290567
non-type template parameters.
During partial ordering, when checking the substituted deduced template
arguments match the original, check the types of non-type template arguments
match even if they're dependent. The only way we get dependent types here is if
they really represent types of the other template (which are supposed to be
modeled as being substituted for unique, non-dependent types).
In order to make this work for auto-typed non-type template arguments, we need
to be able to perform auto deduction even when the initializer and
(potentially) the auto type are dependent, support for which is the bulk of
this patch. (Note that this requires the ability to deduce only a single level
of a multi-level dependent type.)
llvm-svn: 290511
template arguments as written rather than the canonical template arguments,
so we print more user-friendly names for template parameters.
llvm-svn: 290483
fail the merge if the arguments have different types (except if one of them was
deduced from an array bound, in which case take the type from the other).
This is correct because (except in the array bound case) the type of the
template argument in each deduction must match the type of the parameter, so at
least one of the two deduced arguments must have a mismatched type.
This is necessary because we would otherwise lose the type information for the
discarded template argument in the merge, and fail to diagnose the mismatch.
In order to power this, we now properly retain the type of a deduced non-type
template argument deduced from a declaration, rather than giving it the type of
the template parameter; we'll convert it to the template parameter type when
checking the deduced arguments.
llvm-svn: 290399
argument even if the expression is value-dependent (we need to suppress the
final portion of the narrowing check, but the rest of the checking can still be
done eagerly).
This affects template template argument validity and partial ordering under
p0522r0.
llvm-svn: 290276
This change introduces UsingPackDecl as a marker for the set of UsingDecls
produced by pack expansion of a single (unresolved) using declaration. This is
not strictly necessary (we just need to be able to map from the original using
declaration to its expansions somehow), but it's useful to maintain the
invariant that each declaration reference instantiates to refer to one
declaration.
This is a re-commit of r290080 (reverted in r290092) with a fix for a
use-after-lifetime bug.
llvm-svn: 290203
This change introduces UsingPackDecl as a marker for the set of UsingDecls
produced by pack expansion of a single (unresolved) using declaration. This is
not strictly necessary (we just need to be able to map from the original using
declaration to its expansions somehow), but it's useful to maintain the
invariant that each declaration reference instantiates to refer to one
declaration.
llvm-svn: 290080
expressions in a function or class template.
This patch makes the following changes:
- Create a DependentScopeDeclRefExpr for the default argument instead of
a CXXDependentScopeMemberExpr.
- Pass CombineWithOuterScope=true so that the outer scope in which the
enum is declared is searched for the instantiation of the enum.
This is the first part of https://reviews.llvm.org/D23096. Fixes PR28795
rdar://problem/27535319
llvm-svn: 289914
Other compilers accept invalid code here that we reject, and we need a
better error message to try to convince users that the code is really
incorrect. Consider:
class Foo {
typedef MyIterHelper<Foo> iterator;
friend class iterator;
};
Previously our wording was "elaborated type refers to a typedef".
"elaborated type" isn't widely known terminology, so the new diagnostic
says "typedef 'iterator' cannot be referenced with class specifier".
Reviewers: rsmith
Differential Revision: https://reviews.llvm.org/D25216
llvm-svn: 289259
Output generated by option -ast-print looks like C/C++ code, and it
really is for plain C. For C++ the produced output was not valid C++
code, but the differences were small. With this change the output
is fixed and can be compiled. Tests are changed so that output produced
by -ast-print is compiled again with the same flags and both outputs are
compared.
Option -ast-print is extensively used in clang tests but it itself
was tested poorly, existing tests only checked that compiler did not
crash. There are unit tests in file DeclPrinterTest.cpp, but they test
only terse output mode.
Differential Revision: https://reviews.llvm.org/D26452
llvm-svn: 286439
This commit improves the "must have C++ linkage" error diagnostics that are
emitted for C++ declarations like templates and literal operators by adding an
additional note that points to the appropriate extern "C" linkage specifier.
rdar://19021120
Differential Revision: https://reviews.llvm.org/D26189
llvm-svn: 285823
resolved the -> to a call to a specific operator-> function. The particular
test case added here is actually being mishandled: the implicit member access
should not be type-dependent (because it's accessing a non-type-dependent
member of the current instantiation), but calls to a type-dependent operator->
that is a member of the current instantiation would be liable to hit the same
codepath.
llvm-svn: 284999
corresponding arguments are unexpanded pack expansions, we can compute the
result without substituting them. This significantly improves the memory usage
and performance of make_integer_sequence implementations that do this kind of
thing:
using result = integer_sequence<T, Ns ..., sizeof...(Ns) + Ns ...>;
... but note that such an implementation will still perform O(sizeof...(Ns)^2)
work while building the second pack expansion (we just have a somewhat lower
constant now).
In principle we could get this down to linear time by caching whether the
number of expansions of a pack is constant, or checking whether we're within an
alias template before scanning the pack for pack expansions (since that's the
only case in which we do substitutions within a dependent context at the
moment), but this patch doesn't attempt that.
llvm-svn: 284653
not instantiate exception specifications of functions if they were only used in
unevaluated contexts (other than 'noexcept' expressions).
In C++17 onwards, this becomes essential since the exception specification is
now part of the function's type.
Note that this means that constructs like the following no longer work:
struct A {
static T f() noexcept(...);
decltype(f()) *p;
};
... because the decltype expression now needs the exception specification of
'f', which has not yet been parsed.
llvm-svn: 284549
declaration has a dependent type.
This fixes a bug where clang errors out on a valid code.
rdar://problem/28051467
Differential Revision: https://reviews.llvm.org/D24110
llvm-svn: 280330
explicit specialization to a warning for C++98 mode (this is a defect report
resolution, so per our informal policy it should apply in C++98), and turn
the warning on by default for C++11 and later. In all cases where it fires, the
right thing to do is to remove the pointless explicit instantiation.
llvm-svn: 280308
within the instantiation of that same specialization. This could previously
happen for eagerly-instantiated function templates, variable templates,
exception specifications, default arguments, and a handful of other cases.
We still have an issue here for default template arguments that recursively
make use of themselves and likewise for substitution into the type of a
non-type template parameter, but in those cases we're producing a different
entity each time, so they should instead be caught by the instantiation depth
limit. However, currently we will typically run out of stack before we reach
it. :(
llvm-svn: 280190
per-frame stack usage enough to cause it to hit our stack limit. This is not
ideal; we should find a better way of dealing with this, such as increasing
our stack allocation when built with ASan.
llvm-svn: 279668
they're redeclarations. This is necessary in order for name lookup to correctly
find the most recent declaration of the name (which affects default template
argument lookup and cross-module merging, among other things).
llvm-svn: 275612
classes.
MSVC actively uses unqualified lookup in dependent bases, lookup at the
instantiation point (non-dependent names may be resolved on things
declared later) etc. and all this stuff is the main cause of
incompatibility between clang and MSVC.
Clang tries to emulate MSVC behavior but it may fail in many cases.
clang could store lexed tokens for member functions definitions within
ClassTemplateDecl for later parsing during template instantiation.
It will allow resolving many possible issues with lookup in dependent
base classes and removing many already existing MSVC-specific
hacks/workarounds from the clang code.
llvm-svn: 272774
The code had a typo it was doing:
Param->setUninstantiatedDefaultArg(Param->getUninstantiatedDefaultArg());
This is a no-op but may assert, we wanted to do:
Param->setUninstantiatedDefaultArg(OldParam->getUninstantiatedDefaultArg());
This fixes PR28082.
llvm-svn: 272425
Wilson.
An unqualified lookup for in base classes may cause stack overflow if
the base class is a specialization of current class.
Patch by Will Wilson.
llvm-svn: 271251
Also make explicit instantiation decls not apply to nested classes when
targeting MSVC. That dll attributes are not inherited by inner classes
might be the explanation for MSVC's behaviour here.
llvm-svn: 270897
Summary:
In dependent contexts where we know a type name is required, such as a
new expression, we can recover by forming a DependentNameType.
This generalizes our existing compatibility hack for default arguments
for template type parameters.
Works towards parsing atlctrlw.h, which is PR26748.
Reviewers: avt77, rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D20500
llvm-svn: 270615
This reversal is being done with r267453's author's (i.e. Richard Smith's) permission.
This fixes https://llvm.org/bugs/show_bug.cgi?id=27601
Also, per Richard's request the examples from the bug report have been added to our test suite.
llvm-svn: 270016
With this patch compiler emits warning if it tries to make implicit instantiation
of a template but cannot find the template definition. The warning can be suppressed
by explicit instantiation declaration or by command line options
-Wundefined-var-template and -Wundefined-func-template. The implementation follows
the discussion of http://reviews.llvm.org/D12326.
Differential Revision: http://reviews.llvm.org/D16396
llvm-svn: 266719
This is a fix for https://llvm.org/bugs/show_bug.cgi?id=25561 which was a
crash on invalid. Change the handling of invalid decls to have a catch-all
case to prevent unexpecting decls from triggering an assertion.
llvm-svn: 265467
This feature works outside of templates by forming a DeclRefExpr to a
FieldDecl instead of a MemberExpr, which requires a base object in
addition to the FieldDecl.
Previously, while building up the template AST before instantiation, we
formed a CXXDependentScopeMemberExpr, which always instantiates to a
MemberExpr. Now, in unevaluated contexts we form a
DependentScopeDeclRefExpr, which is a more flexible node that can
instantiate to either a MemberExpr or a DeclRefExpr depending on lookup
results.
Fixes PR26893.
llvm-svn: 263279
In VisitNonTypeTemplateParamDecl, before SubstExpr with the default argument,
we should create a ConstantEvaluated ExpressionEvaluationContext. Without this,
it is possible to use a PotentiallyEvaluated ExpressionEvaluationContext; and
MaybeODRUseExprs will not be cleared when popping the context, causing
assertion failure.
This is similar to how we handle the context before SubstExpr with the
default argument, in SubstDefaultTemplateArgument.
Part of PR13986.
rdar://24480205
Differential Revision: http://reviews.llvm.org/D17576
llvm-svn: 261803
Or, do not set Sema's CurContext to the template declaration's when substituting into default template arguments of said template declaration.
If we do push the template declaration context on to Sema, and the template declaration is at namespace scope, Sema can get confused and try and do odr analysis when substituting into default template arguments, even though the substitution could be occurring within a dependent context.
I'm not sure why this was being done, perhaps there was concern that if a default template argument referred to a previous template parameter, it might not be found during substitution - but all regression tests pass, and I can't craft a test that would cause it to fails (if some one does, please inform me, and i'll craft a different fix for the PR).
This patch removes a single line of code, but unfortunately adds more than it removes, because of the tests. Some day I still hope to commit a patch that removes far more lines than it adds, while leaving clang better for it ;)
Sorry that r253590 ("Change the expression evaluation context from Unevaluated to ConstantEvaluated while substituting into non-type template argument defaults") caused the PR!
llvm-svn: 258110
Covers significantly more code in the template template pack argument
test and fixes the resulting assert problem.
Differential Revision: http://reviews.llvm.org/D15743
llvm-svn: 257326
By storing the instantiated expression back in the ParmVarDecl,
we remove the last need for separately storing the sub-expression
of a CXXDefaultArgExpr. This makes PCH/Modules merging quite
simple: CXXDefaultArgExpr records are serialized as references
to the ParmVarDecl, and we ignore redundant attempts to overwrite
the instantiated expression.
This has some extremely marginal impact on user-facing semantics.
However, the major effect is that it avoids IRGen errors about
conflicting definitions due to lambdas in the argument being
instantiated multiple times while sharing the same mangling.
It should also slightly improve memory usage and module file size.
rdar://23810407
llvm-svn: 256983
This is the 5th Lit test patch.
Expanded expected diagnostics to vary by C++ dialect.
Expanded RUN line to: default, C++98/03 and C++11.
llvm-svn: 255196
This time, I went with the first approach from
http://reviews.llvm.org/D6700, where clang actually attempts to form an
implicit member reference from an UnresolvedLookupExpr. We know that
there are only two possible outcomes at this point, a DeclRefExpr of the
FieldDecl or an error, but its safer to reuse the existing machinery for
this.
llvm-svn: 250856
consider the following:
enum E *p;
enum E { e };
The above snippet is not ANSI C because 'enum E' has not bee defined
when we are processing the declaration of 'p'; however, it is a popular
extension to make the above work. This would fail using the Microsoft
enum semantics because the definition of 'E' would implicitly have a
fixed underlying type of 'int' which would trigger diagnostic messages
about a mismatch between the declaration and the definition.
Instead, treat fixed underlying types as not fixed for the purposes of
the diagnostic.
llvm-svn: 249674
Our self hosting buildbots found a few more tests which weren't updated
to reflect that the enum semantics are part of the Microsoft ABI.
llvm-svn: 249670
that change turns out to not be reasonable: mutating the AST of a parsed
template during instantiation is not a sound thing to do, does not work across
chained PCH / modules builds, and is in any case a special-case workaround to a
more general problem that should be solved centrally.
llvm-svn: 249342
partial specialization can perform conversions on the argument. Be sure we
start again from the original argument when checking each possible template.
llvm-svn: 249114
We get into this bad state when someone defines a new member function
for a class but forgets to add the declaration to the class body.
Calling the new member function from a member function template of the
class will crash during instantiation.
llvm-svn: 248925
This doesn't quite get alias template equivalence right yet, but handles the
egregious cases where we would silently give the wrong answers.
llvm-svn: 248431
Summary:
This change adds support for `__builtin_ms_va_list`, a GCC extension for
variadic `ms_abi` functions. The existing `__builtin_va_list` support is
inadequate for this because `va_list` is defined differently in the Win64
ABI vs. the System V/AMD64 ABI.
Depends on D1622.
Reviewers: rsmith, rnk, rjmccall
CC: cfe-commits
Differential Revision: http://reviews.llvm.org/D1623
llvm-svn: 247941
Summary:
`OpaqueValueExpr`s may not have a source expression (as in the case when
they are created due to a default argument error).
This can cause an assertion failure in `TransformOpaqueValueExpr` during
template instantiation.
This patch fixes the assertion failure.
Reviewers: hfinkel, rsmith
Subscribers: fraggamuffin, cfe-commits
Differential Revision: http://reviews.llvm.org/D11582
Patch by Rachel Craik!
llvm-svn: 246600
If a function declaration is found inside a template function as in:
template<class T> void f() {
void g(int x = T::v) except(T::w);
}
it must be instantiated along with the enclosing template function,
including default arguments and exception specification.
Together with the patch committed in r240974 this implements DR1484.
Differential Revision: http://reviews.llvm.org/D11194
llvm-svn: 245810
If a function containing a local class is instantiated, instantiate
all of local class member, including default arguments and exception
specifications.
This change fixes PR21332 and thus implements DR1484.
Differential Revision: http://reviews.llvm.org/D9990
llvm-svn: 240974
Get rid of code-path that (according to Richard Smith) is not needed but
leads to a crasher bug when assuming a template has been fully
instantiated and thus has a definition.
llvm-svn: 240752
The underlying problem in PR23823 already existed before my recent change
in r239558, but that change made it worse (failing not only for undeclared
symbols, but also failed overload resolution). This makes Clang not try to
delay the lookup in SFINAE context. I assume no current code is relying on
SFINAE working with lookups that need to be delayed, because that never
seems to have worked.
Differential Revision: http://reviews.llvm.org/D10417
llvm-svn: 239639
This patch does two things in order to enable compilation of the problematic code in PR23810:
1. In Sema::buildOverloadedCallSet, it postpones lookup for MS mode when no
viable candidate is found in the overload set. Previously, lookup would only
be postponed here if the overload set was empty.
2. Make BuildRecoveryCallExpr call Sema::DiagnoseEmptyLookup under more circumstances.
There is a comment in DiagnoseTwoPhaseLookup that says "Don't diagnose names we find in
classes; we get much better diagnostics for these from DiagnoseEmptyLookup." The problem
was that DiagnoseEmptyLookup might not get called later, and we failed to recover.
Differential Revision: http://reviews.llvm.org/D10369
llvm-svn: 239558
Starting from r236426 FindInstantiatedDecl may instantiate types that
are referenced before definition. This change limit the set of types
that can be instantiated by this function.
llvm-svn: 237434
This is necessary in order to allow the use of a constexpr member function, or
a member function with deduced return type, of a local class within a
surrounding instantiated function template specialization.
Patch by Michael Park!
This re-commits r236063, which was reverted in r236134, along with a fix for a
delayed template parsing bug that was exposed by this change.
llvm-svn: 237064
If a class is absent from instantiation and is incomplete, instantiate it as
an incomplete class thus avoiding compiler crash.
This change fixes PR18653.
Differential Revision: http://reviews.llvm.org/D8281
llvm-svn: 236426
Richard Smith