Bug 54310 - Order of operations during overload resolution
Summary: Order of operations during overload resolution
Status: RESOLVED WORKSFORME
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.8.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-08-18 08:03 UTC by Nathan Ridge
Modified: 2014-05-13 16:15 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nathan Ridge 2012-08-18 08:03:54 UTC
GCC accepts the following code:


template <typename T>
struct meta
{
    typedef typename T::type type;
};

struct S{};

template <typename T>
typename meta<T>::type foo(T, S);

int foo(int, int);      

int main()
{
    foo(0, 0);
}


Clang rejects this code with the following error:

test.cpp:4:22: error: type 'int' cannot be used prior to '::' because it has no members
    typedef typename T::type type;
                     ^
test.cpp:10:10: note: in instantiation of template class 'meta<int>' requested here
typename meta<T>::type foo(T, S);
         ^
test.cpp:10:24: note: while substituting deduced template arguments into function template 'foo' [with T = int]
typename meta<T>::type foo(T, S);
                       ^

I believe the code is invalid (and clang's error is correct), for the following reasons:

1. Template argument deduction should be performed on the template candidate *before* to discarding it due to a type mismatch for the second parameter (expected S, got int). Section 13.3.1/7 of the standard says (emphasis mine): "In each case where a candidate is a function template, candidate function template specializations are generated using template argument deduction. Those candidates are *then* handled as candidate functions in the usual way. A given name can refer to one or more function templates and also to a set of overloaded non-template functions. In such a case, the candidate functions generated from each function template are combined with the set of non-template candidate functions."

2. Template argument deduction on the template candidate should fail with a hard error (not SFINAE), because the error that occurs (T::type not being valid for T = int) is not in the immediate context of the function type. (Section 14.8.2/8, emphasis mine: "If a substitution results in an invalid type or expression, type deduction fails. [...] Only invalid types and expressions *in the immediate context* of the function type and its template parameter types can result in a deduction failure. [...]").


GCC does reject the following example:


template <typename T>
struct meta
{
    typedef typename T::type type;
};

template <typename T>
typename meta<T>::type foo(T);

int foo(int);      

int main()
{
    foo(0);
}


With the following error:

test.cpp: In instantiation of 'struct meta<int>':
test.cpp:8:24:   required by substitution of 'template<class T> typename meta::type foo(T) [with T = int]'
test.cpp:14:10:   required from here
test.cpp:4:30: error: 'int' is not a class, struct, or union type
     typedef typename T::type type;
                              ^

suggesting that GCC already obeys point (2) above, and therefore the problem is likely to be with point (1).
Comment 1 Nathan Ridge 2013-07-07 17:35:51 UTC
Richard Smith has suggested that GCC is actually allowed not to instantiate 'meta<int>' as per [temp.inst]/p6:

"If the overload resolution process can determine the correct function to call without instantiating a class template definition, it is unspecified whether that instantiation actually takes place."

If this is really what's happening - GCC is not instantiating 'meta<int>' because it can determine without doing so that the first overload of 'foo' will not be chosen - then I guess we can close this PR as INVALID.
Comment 2 Paolo Carlini 2013-08-21 10:25:31 UTC
Current ICC also accepts this.
Comment 3 Paolo Carlini 2014-05-13 15:44:34 UTC
Current SolarisStudio also accepts it. I guess I'm going to add the testcase and close the bug.
Comment 4 paolo@gcc.gnu.org 2014-05-13 16:14:52 UTC
Author: paolo
Date: Tue May 13 16:14:19 2014
New Revision: 210385

URL: http://gcc.gnu.org/viewcvs?rev=210385&root=gcc&view=rev
Log:
2014-05-13  Paolo Carlini  <paolo.carlini@oracle.com>

	PR c++/54310
	* g++.dg/template/pr54310.C: New.

Added:
    trunk/gcc/testsuite/g++.dg/template/pr54310.C
Modified:
    trunk/gcc/testsuite/ChangeLog
Comment 5 Paolo Carlini 2014-05-13 16:15:22 UTC
Done.