[C++ RFC / Patch] PR 54080, PR 52875 and more (aka SFINAE vs template recursion depth)

[Paolo Carlini <paolo dot carlini at oracle dot com>]

Hi,

this is, IMHO, a rather interesting issue. I was working on PR 54080, 
where currently with ICE pretty badly for Error reporting routines 
re-entered without producing any sensible error message. Figured out 
that the core of the issue are the error messages in push_tinst_level 
about template instantiation depth exceeded. Drafted the attached, the 
error message is great with no ICE:

54080.C: In instantiation of ‘decltype (foo<template<class T> class 
vector>(foo(input, func1), funcrest)) foo(const vector<int>&, const 
Func1&, FuncRest) [with OutType = vector; Func1 = int; FuncRest = int; 
decltype (foo<vector>(foo(input, func1), funcrest)) = vector<int>]’:
54080.C:25:22: required from here
54080.C:19:2: error: return-statement with no value, in function 
returning ‘vector<int>’ [-fpermissive]
return;

when I ran the testsuite, I found something (tidied):

FAIL: g++.dg/cpp0x/decltype26.C (test for errors, line 6)
FAIL: g++.dg/cpp0x/decltype26.C (test for excess errors)
FAIL: g++.dg/cpp0x/decltype28.C (test for errors, line 11)
FAIL: g++.dg/cpp0x/decltype28.C (test for warnings, line 15)
FAIL: g++.dg/cpp0x/decltype29.C (test for errors, line 12)
FAIL: g++.dg/cpp0x/decltype29.C (test for excess errors)

the really interesting one is decltype28.C, which we don't reject 
anymore, we simply accept it. What is happening is that the overload 
which leads to excessive template instantiation depth is SFINAE-ed away 
and the other one "wins"! Thus, this is the core of my message: it seems 
that we behave wrt this issue - SFINAE vs template instantiation depth - 
in a different way vs current clang++ and icc: we produce hard error 
messages in SFINAE contexts. Is that intended? I find the issue 
interesting, arguably a template instantiation depth exceeded isn't just 
like any other error.

With the attached draft we handle quite a few other testcases I have 
seen around in a different way, for example c++/52875 is automatically 
fixed (assuming we want to behave like clang++ and icc).

Thanks!
Paolo.

Attachment: p
Description: Text document