| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
deduction.
(cherry picked from commit 34bd51f4b1d9f489e61becb662bdc72bb56dd277)
|
|
|
|
|
|
|
|
|
|
| |
expanded by the deduced pack.
We recently started also deducing the arity of separately-expanded packs
that are merely mentioned within the pack in question, which is
incorrect.
(cherry picked from commit e8f198dd9e9dabed8d50276465906e7c8827cada)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pack expansion.
Previously, if all parameter / argument pairs for a pack expansion
deduction were non-deduced contexts, we would not deduce the arity of
the pack, and could end up deducing a different arity (leading to
failures during substitution) or defaulting to an arity of 0 (leading to
bad diagnostics about passing the wrong number of arguments to a
variadic function). Instead, we now always deduce the arity for all
involved packs any time we deduce a pack expansion.
This will result in less substitution happening in some cases, which
could avoid non-SFINAEable errors, and should generally improve the
quality of diagnostics when passing initializer lists to variadic
functions.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
This fixes missing lambda-captures for variables referenced only inside a
static_assert (!), among other things.
llvm-svn: 304760
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
assume the bound has a non-dependent integral type.
llvm-svn: 295698
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 295281
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
there is no object argument, when early checking of implicit conversion
sequences for a function template fails.
llvm-svn: 291597
|
|
|
|
|
|
| |
resolution failure.
llvm-svn: 291596
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
deduction, don't forget to check the argument is valid.
llvm-svn: 291170
|
|
|
|
|
|
| |
initializer list.
llvm-svn: 291075
|
|
|
|
|
|
|
|
|
|
|
|
| |
argument list.
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
|
|
|
|
| |
llvm-svn: 290926
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
non-deduced context.
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
|
|
|
|
| |
llvm-svn: 290843
|
|
|
|
|
|
| |
partial specialization arguments.
llvm-svn: 290484
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
as a template argument in a template-id, from a null non-type template
argument, failed.
Extracted from a patch by James Touton!
llvm-svn: 282641
|
|
|
|
|
|
|
|
|
|
|
|
| |
deduction of template parameters from base
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
|
|
|
|
|
|
| |
dependent, the type is a non-deduced context.
llvm-svn: 256651
|
|
|
|
|
|
| |
Discussed with Richard Smith.
llvm-svn: 245162
|
|
|
|
|
|
| |
Correct logic concerning 'T &&' deduction against lvalues.
llvm-svn: 226278
|
|
|
|
| |
llvm-svn: 225684
|
|
|
|
| |
llvm-svn: 225587
|
|
|
|
|
|
| |
after a pack expansion.
llvm-svn: 221838
|
|
|
|
| |
llvm-svn: 221833
|
|
|
|
|
|
|
|
| |
expansion into a parameter pack; we know that we're still filling in that
parameter's arguments. Previously, if we hit this case for an alias template,
we'd try to substitute using non-canonical template arguments.
llvm-svn: 221832
|
|
|
|
|
|
|
| |
penultimate parameter of a template parameter list, where the last parameter is
itself a pack, and build a bogus empty final pack argument.
llvm-svn: 221748
|
|
|
|
| |
llvm-svn: 216221
|
|
|
|
|
|
|
|
| |
which is required given the current setup for template
argument deduction substitution validation, and add a test
case to make sure we don't break it in the future.
llvm-svn: 135262
|
|
|
|
|
|
|
|
|
|
| |
parameter type to see what's behind it, so that we don't end up
printing silly things like "float const *" when "const float *" would
make more sense. Also, replace the pile of "isa" tests with a simple
switch enumerating all of the cases, making a few more obvious cases
use prefix qualifiers.
llvm-svn: 125729
|
|
|
|
|
|
|
| |
deduction and the final substitution, but not while substituting the
explicit template arguments. Fixes rdar://problem/8537391
llvm-svn: 116332
|
|
|
|
|
|
|
| |
properly account for the possibility that certain opaque types
might be more qualified than they appear. Fixes PR7708.
llvm-svn: 112390
|
|
|
|
|
|
| |
the context allows us to ignore qualifiers on the array type itself.
llvm-svn: 111486
|
|
|
|
|
|
|
| |
Rename it to TDK_Underqualified to avoid this sort of confusion and give it
its own diagnostic.
llvm-svn: 110318
|
|
|
|
|
|
|
|
|
| |
This flag and warning match GCC semantics. Also, move it to -Wextra as this is
a largely cosmetic issue and doesn't seem to mask problems. Subsequent fixes to
the tests which no longer by default emit the warning. Added explicit test
cases for both C and C++ behavior with the warning turned on.
llvm-svn: 108325
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
strip cv-qualifiers from the expression's type when the language calls
for it: in C, that's all the time, while C++ only does it for
non-class types.
Centralized the computation of the call expression type in
QualType::getCallResultType() and some helper functions in other nodes
(FunctionDecl, ObjCMethodDecl, FunctionType), and updated all relevant
callers of getResultType() to getCallResultType().
Fixes PR7598 and PR7463, along with a bunch of getResultType() call
sites that weren't stripping references off the result type (nothing
stripped cv-qualifiers properly before this change).
llvm-svn: 108234
|
|
|
|
|
|
|
|
|
|
| |
deduction. This requires refactoring the deduction to have access to the Sema
object instead of merely the ASTContext. Still leaves something to be desired
due to poor source location.
Fixes PR6257 and half of PR6259.
llvm-svn: 95528
|
|
|
|
|
|
|
|
|
|
|
|
| |
QualType to get CVR-qualifiers through array types, and switches the primary
comparison methods to use it. This may allow simplifying some of the callers of
getUnqualifiedArrayType.
Also fix the normalizing of CV-qualification during template deduction to
normalize through arrays and allow a more qualified deduced array type. This
fixes PR5911.
llvm-svn: 92289
|
|
|
|
|
|
|
|
|
| |
- This is designed to make it obvious that %clang_cc1 is a "test variable"
which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it
can be useful to redefine what gets run as 'clang -cc1' (for example, to set
a default target).
llvm-svn: 91446
|
|
permits, among other things, ripping apart and reconstructing
templates via partial specialization:
template<typename T>
struct DeepRemoveConst { typedef T type; };
template<typename T>
struct DeepRemoveConst<const T> {
typedef typename DeepRemoveConst<T>::type type;
};
template<template<typename> class TT, typename T>
struct DeepRemoveConst<TT<T> > {
typedef TT<typename DeepRemoveConst<T>::type> type;
};
Also, fix a longstanding thinko in the code handling partial ordering
of class template partial specializations. We were performing the
second deduction without clearing out the results of the first
deduction. It's amazing we got through so much code with such a
horrendous error :(
llvm-svn: 86893
|