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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@293207 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@292426 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291427 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291425 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291410 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291064 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291014 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290933 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290923 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290808 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290792 91177308-0d34-0410-b5e6-96231b3b80d8
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.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290593 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290586 91177308-0d34-0410-b5e6-96231b3b80d8
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.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290511 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290403 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290399 91177308-0d34-0410-b5e6-96231b3b80d8
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!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290315 91177308-0d34-0410-b5e6-96231b3b80d8
function. (This change would also allow us to handle default template arguments
in partial specializations if the standard ever permits them.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290225 91177308-0d34-0410-b5e6-96231b3b80d8
arguments from a declaration; despite what the standard says, this form of
deduction should not be considering exception specifications.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@288301 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@285663 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@284905 91177308-0d34-0410-b5e6-96231b3b80d8
implements the bulk of the change (modifying the type system to include
exception specifications), but not all the details just yet.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@284337 91177308-0d34-0410-b5e6-96231b3b80d8
as a template argument in a template-id, from a null non-type template
argument, failed.
Extracted from a patch by James Touton!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@282641 91177308-0d34-0410-b5e6-96231b3b80d8
decomposition declaration for arrays, aggregate-like structs, tuple-like
types, and (as an extension) for complex and vector types.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@278435 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Space for storing the //constraint-expression// of the
//requires-clause// associated with a `TemplateParameterList` is
arranged by taking a bit out of the `NumParams` field for the purpose
of determining whether there is a //requires-clause// or not, and by
adding to the trailing objects tied to the `TemplateParameterList`. An
accessor is provided.
An appropriate argument is supplied to `TemplateParameterList::Create`
at the various call sites.
Serialization changes will addressed as the Concepts implementation
becomes more solid.
Drive-by fix:
This change also replaces the custom
`FixedSizeTemplateParameterListStorage` implementation with one that
follows the interface provided by `llvm::TrailingObjects`.
Reviewers: aaron.ballman, faisalv, rsmith
Subscribers: cfe-commits, nwilson
Differential Revision: https://reviews.llvm.org/D19322
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@276069 91177308-0d34-0410-b5e6-96231b3b80d8
ArrayRef is a little better than passing around a pointer/length
pair.
No functional change is intended.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@274732 91177308-0d34-0410-b5e6-96231b3b80d8
ArrayRef is a little better than passing around a pointer/length pair.
No functional change is intended.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@274475 91177308-0d34-0410-b5e6-96231b3b80d8
Richard Smith