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
classes of an argument to use CXXRecordDecl::forallBases. Fix forallBases to
only visit each base class once.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@267453 91177308-0d34-0410-b5e6-96231b3b80d8
preserve any deduced types from a failed deduction to a subsequent attempt at
deduction. Patch by Erik Pilkington!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@267444 91177308-0d34-0410-b5e6-96231b3b80d8
Some functions can't have their address taken. If we encounter an
overload set where only one of the candidates can have its address
taken, we should automatically select that candidate's type in type
deduction.
Differential Revision: http://reviews.llvm.org/D15591
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@263888 91177308-0d34-0410-b5e6-96231b3b80d8
(that is not a pack expansion) during template argument deduction, even if we
deduced that the pack would be empty.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259688 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Support for OpenCL 2.0 pipe type.
This is a bug-fix version for bader's patch reviews.llvm.org/D14441
Reviewers: pekka.jaaskelainen, Anastasia
Subscribers: bader, Anastasia, cfe-commits
Differential Revision: http://reviews.llvm.org/D15603
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@257254 91177308-0d34-0410-b5e6-96231b3b80d8
by overload resolution because deduction succeeds, but the substituted
parameter type for some parameter (with deduced type) doesn't exactly match the
corresponding adjusted argument type.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@256657 91177308-0d34-0410-b5e6-96231b3b80d8
Doing so required separating them so that the former doesn't inherit
from the latter anymore. Investigating that, it became clear that the
inheritance wasn't actually providing real value in any case.
So also:
- Remove a bunch of redundant functions (getExplicitTemplateArgs,
getOptionalExplicitTemplateArgs) on various Expr subclasses which
depended on the inheritance relationship.
- Switched external callers to use pre-existing accessors that return the
data they're actually interested in (getTemplateArgs,
getNumTemplateArgs, etc).
- Switched internal callers to use pre-existing getTemplateKWAndArgsInfo.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@256359 91177308-0d34-0410-b5e6-96231b3b80d8
is complete (with an error produced if not) and a function that merely queries
whether the type is complete. Either way we'll trigger instantiation if
necessary, but only the former will diagnose and recover from missing module
imports.
The intent of this change is to prevent a class of bugs where code would call
RequireCompleteType(..., 0) and then ignore the result. With modules, we must
check the return value and use it to determine whether the definition of the
type is visible.
This also fixes a debug info quality issue: calls to isCompleteType do not
trigger the emission of debug information for a type in limited-debug-info
mode. This allows us to avoid emitting debug information for type definitions
in more cases where we believe it is safe to do so.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@256049 91177308-0d34-0410-b5e6-96231b3b80d8
for the derived class into it. This is mostly just a cleanup, but could in
principle be a bugfix if there is some codepath that reaches here and didn't
previously require a complete type (I couldn't find any such codepath, though).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@256037 91177308-0d34-0410-b5e6-96231b3b80d8
https://llvm.org/bugs/show_bug.cgi?id=24694http://wg21.link/cwg1591
Teach DeduceFromInitializerList in SemaTemplateDeduction.cpp to deduce against array (constant and dependent sized) parameters (really, reference to arrays since they don't decay to pointers), by checking if the template parameter is either one of those kinds of arrays, and if so, deducing each initializer list element against the element type, and then deducing the array bound if needed.
In brief, this patch enables the following code:
template<class T, int N> int *f(T (&&)[N]);
int *ip = f({1, 2, 3});
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@255221 91177308-0d34-0410-b5e6-96231b3b80d8
Function types can be extracted from member pointer types.
However, the type is not appropriate without first adjusting the calling
convention.
This fixes PR25661.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@254323 91177308-0d34-0410-b5e6-96231b3b80d8
https://gcc.gnu.org/onlinedocs/gcc/Typeof.html
Differences from the GCC extension:
* __auto_type is also permitted in C++ (but only in places where
it could appear in C), allowing its use in headers that might
be shared across C and C++, or used from C++98
* __auto_type can be combined with a declarator, as with C++ auto
(for instance, "__auto_type *p")
* multiple variables can be declared in a single __auto_type
declaration, with the C++ semantics (the deduced type must be
the same in each case)
This patch also adds a missing restriction on applying typeof to
a bit-field, which GCC has historically rejected in C (due to
lack of clarity as to whether the operand should be promoted).
The same restriction also applies to __auto_type in C (in both
GCC and Clang).
This also fixes PR25449.
Patch by Nicholas Allegra!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252690 91177308-0d34-0410-b5e6-96231b3b80d8
We didn't check the return result of BuildDecltypeType, resulting in us
crashing when we tried to grab the canonical version of the type.
This fixes PR23995.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241131 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch reduces duplication in the template argument deduction code
for handling deduction from initializer lists in a function call. This
extends the fix for PR12119 to also apply to the case where the
corresponding parameter is a trailing parameter pack.
Test Plan:
A test for deduction from nested initializer lists where the
corresponding parameter is a trailing parameter pack is added in
`clang/test/SemaCXX/cxx0x-initializer-stdinitializerlist.cpp`.
Reviewers: fraggamuffin, rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D10681
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240612 91177308-0d34-0410-b5e6-96231b3b80d8
The patch is generated using this command:
$ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
work/llvm/tools/clang
To reduce churn, not touching namespaces spanning less than 10 lines.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240270 91177308-0d34-0410-b5e6-96231b3b80d8
Sadly, LLVM_ATTRIBUTE_UNUSED does nothing with Visual C++ which means
we'll have to workaround such cases again and again.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@237267 91177308-0d34-0410-b5e6-96231b3b80d8
template partial ordering rules. This rule applies per pair of types being
compared, not per pair of function templates being compared.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@229965 91177308-0d34-0410-b5e6-96231b3b80d8
The improved completion in call context now works with:
- Functions.
- Member functions.
- Constructors.
- New expressions.
- Function call expressions.
- Template variants of the previous.
There are still rough edges to be fixed:
- Provide support for optional parameters. (fix known)
- Provide support for member initializers. (fix known)
- Provide support for variadic template functions. (fix unknown)
- Others?
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@226670 91177308-0d34-0410-b5e6-96231b3b80d8
we're instantiating, if there's a ParmVarDecl within a FunctionDecl context
that is not a parameter of that function. Add some asserts to catch this kind
of issue more generally, and fix another bug exposed by those asserts where we
were missing a local instantiation scope around substitution of
explicitly-specified template arguments.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@225490 91177308-0d34-0410-b5e6-96231b3b80d8
Plumb through the full QualType of the TemplateArgument::Declaration, as
it's insufficient to only know whether the type is a reference or
pointer (that was necessary for mangling, but insufficient for debug
info). This shouldn't increase the size of TemplateArgument as
TemplateArgument::Integer is still longer by another 32 bits.
Several bits of code were testing that the reference-ness of the
parameters matched, but this seemed to be insufficient (various other
features of the type could've mismatched and wouldn't've been caught)
and unnecessary, at least insofar as removing those tests didn't cause
anything to fail.
(Richard - perchaps you can hypothesize why any of these checks might
need to test reference-ness of the parameters (& explain why
reference-ness is part of the mangling - I would've figured that for the
reference-ness to be different, a prior template argument would have to
be different). I'd be happy to add them in/beef them up and add test
cases if there's a reason for them)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@219900 91177308-0d34-0410-b5e6-96231b3b80d8
Changes diagnostic options, language standard options, diagnostic identifiers, diagnostic wording to use c++14 instead of c++1y. It also modifies related test cases to use the updated diagnostic wording.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@215982 91177308-0d34-0410-b5e6-96231b3b80d8
http://llvm.org/bugs/show_bug.cgi?id=18498
This code was resulting in a crash:
auto L = [](auto ... v) { };
L.operator()<int>(3);
The reason is that the partially-substituted-pack is incorrectly retained within the current-instantiation-scope during template-argument-finalization, and because lambda's are local, there parent instantiation scopes are merged, which leads to the expansion-pattern being retained in the finalized specialization.
This patch ensures that once we have finalized deduction of a parameter-pack, we remove the partially-substituted-pack so that it doesn't cause CheckParameterPacksForExpansion to incorrectly inform the caller that it needs to retain the expansion pattern.
Thanks to Richard Smith for the review!
http://reviews.llvm.org/D2135
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@209992 91177308-0d34-0410-b5e6-96231b3b80d8
A return type is the declared or deduced part of the function type specified in
the declaration.
A result type is the (potentially adjusted) type of the value of an expression
that calls the function.
Rule of thumb:
* Declarations have return types and parameters.
* Expressions have result types and arguments.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@200082 91177308-0d34-0410-b5e6-96231b3b80d8
Fix a perennial source of confusion in the clang type system: Declarations and
function prototypes have parameters to which arguments are supplied, so calling
these 'arguments' was a stretch even in C mode, let alone C++ where default
arguments, templates and overloading make the distinction important to get
right.
Readability win across the board, especially in the casting, ADL and
overloading implementations which make a lot more sense at a glance now.
Will keep an eye on the builders and update dependent projects shortly.
No functional change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199686 91177308-0d34-0410-b5e6-96231b3b80d8
The previous patches tried to deduce the correct function type. I now realize
this is not possible in general. Consider
class foo {
template <typename T> static void bar(T v);
};
extern template void foo::bar(const void *);
We will only know that bar is static after a lookup, so we have to handle this
in the template instantiation code.
This patch reverts my previous two changes (but not the tests) and instead
handles the issue in DeduceTemplateArguments.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@195154 91177308-0d34-0410-b5e6-96231b3b80d8
Under ARC++, a reference to a const Objective-C pointer is implicitly
treated as __unsafe_unretained, and can be initialized with (e.g.) a
__strong lvalue. Make sure this behavior does not break template
argument deduction and (related) that partial ordering still prefers a
'T* const&' template over a 'T const&' template when this case kicks
in. Fixes <rdar://problem/14467941>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@194239 91177308-0d34-0410-b5e6-96231b3b80d8
Richard Smith