// If the parameter type somehow involves auto, deduce the type now.
if (getLangOpts().CPlusPlus1z && ParamType->isUndeducedType()) {
+ // During template argument deduction, we allow 'decltype(auto)' to
+ // match an arbitrary dependent argument.
+ // FIXME: The language rules don't say what happens in this case.
+ // FIXME: We get an opaque dependent type out of decltype(auto) if the
+ // expression is merely instantiation-dependent; is this enough?
+ if (CTAK == CTAK_Deduced && Arg->isTypeDependent()) {
+ auto *AT = dyn_cast<AutoType>(ParamType);
+ if (AT && AT->isDecltypeAuto()) {
+ Converted = TemplateArgument(Arg);
+ return Arg;
+ }
+ }
+
// When checking a deduced template argument, deduce from its type even if
// the type is dependent, in order to check the types of non-type template
// arguments line up properly in partial ordering.
TDecltypeAuto<Int> dai; // expected-error {{different template parameters}}
TDecltypeAuto<IntPtr> daip; // expected-error {{different template parameters}}
- // FIXME: It's completely unclear what should happen here. A case can be made
- // that 'auto' is more specialized, because it's always a prvalue, whereas
- // 'decltype(auto)' could have any value category. Under that interpretation,
- // we get the following results entirely backwards:
- TAuto<DecltypeAuto> ada; // expected-error {{different template parameters}}
- TAutoPtr<DecltypeAuto> apda; // expected-error {{different template parameters}}
+ // FIXME: It's completely unclear what should happen here, but these results
+ // seem at least plausible:
+ TAuto<DecltypeAuto> ada;
+ TAutoPtr<DecltypeAuto> apda;
+ // Perhaps this case should be invalid, as there are valid 'decltype(auto)'
+ // parameters (such as 'user-defined-type &') that are not valid 'auto'
+ // parameters.
TDecltypeAuto<Auto> daa;
TDecltypeAuto<AutoPtr> daa; // expected-error {{different template parameters}}