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
such guides below explicit ones, and ensure that references to the class's
template parameters are not treated as forwarding references.
We make a few tweaks to the wording in the current standard:
1) The constructor parameter list is copied faithfully to the deduction guide,
without losing default arguments or a varargs ellipsis (which the standard
wording loses by omission).
2) If the class template declares no constructors, we add a T() -> T<...> guide
(which will only ever work if T has default arguments for all non-pack
template parameters).
3) If the class template declares nothing that looks like a copy or move
constructor, we add a T(T<...>) -> T<...> guide.
#2 and #3 follow from the "pretend we had a class type with these constructors"
philosophy for deduction guides.
llvm-svn: 295007
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
This rule permits the injected-class-name of a class template to be used as
both a template type argument and a template template argument, with no extra
syntax required to disambiguate.
llvm-svn: 292426
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
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
Previously, if an overloaded function in a braced-init-list was encountered in
template argument deduction, and the overload set couldn't be resolved to a
particular function, we'd immediately produce a deduction failure. That's not
correct; this situation is supposed to result in that particular P/A pair being
treated as a non-deduced context, and deduction can still succeed if the type
can be deduced from elsewhere.
llvm-svn: 291014
Previously, if the arguments for a parameter pack contained a braced-init-list,
we would abort deduction (keeping the pack deductions from prior arguments) at
the point when we reached the braced-init-list, resulting in wrong deductions
and rejects-valids. We now just leave a "hole" in the pack for such an argument,
which needs to be filled by another deduction of the same pack.
llvm-svn: 290933
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
This reverts commit r290808, as it broken all ARM and AArch64 test-suite
test: MultiSource/UnitTests/C++11/frame_layout
Also, please, next time, try to write a commit message in according to
our guidelines:
http://llvm.org/docs/DeveloperPolicy.html#commit-messages
llvm-svn: 290811
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 does not implement the partial ordering portion of DR1391, which so
far appears to be misguided.
llvm-svn: 290808
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
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
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
twice, in finalization of template argument deduction.
This is a re-commit of r290310 (reverted in r290329); the bug found by the
buildbots was fixed in r290399 (we would sometimes build a deduced template
argument with a bogus type).
llvm-svn: 290403
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
Print the fully qualified names for the overload candidates. This makes
it easier to tell what the ambiguity is. Especially if a template
is instantiated after a using namespace, it will not inherit the
namespace where it was declared. The specialization will give a message
about a partial order being ambiguous for the same (unqualified) name,
which does not help identify the failure.
Addresses PR31450!
llvm-svn: 290315
function. (This change would also allow us to handle default template arguments
in partial specializations if the standard ever permits them.)
llvm-svn: 290225
arguments from a declaration; despite what the standard says, this form of
deduction should not be considering exception specifications.
llvm-svn: 288301
specification to resolve the exception specification as part of the type check,
in C++1z onwards. This is not actually part of P0012 / CWG1330 rules for when
an exception specification is "needed", but is necessary for sanity.
llvm-svn: 285663
mismatched dynamic exception specifications in expressions from an error to a
warning, since this is no longer ill-formed in C++1z.
Allow reference binding of a reference-to-non-noexcept function to a noexcept
function lvalue. As defect resolutions, also allow a conditional between
noexcept and non-noexcept function lvalues to produce a non-noexcept function
lvalue (rather than decaying to a function pointer), and allow function
template argument deduction to deduce a reference to non-noexcept function when
binding to a noexcept function type.
llvm-svn: 284905
