This is the mail archive of the
mailing list for the GCC project.
Re: [C++ RFC / Patch] PR 54080, PR 52875 and more (aka SFINAE vs template recursion depth)
- From: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- To: Paolo Carlini <paolo dot carlini at oracle dot com>
- Cc: Jason Merrill <jason at redhat dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 9 Aug 2013 03:46:58 -0500
- Subject: Re: [C++ RFC / Patch] PR 54080, PR 52875 and more (aka SFINAE vs template recursion depth)
- References: <5203F75A dot 9080206 at oracle dot com> <52042C5C dot 7060702 at redhat dot com> <520496A1 dot 6030700 at oracle dot com>
On Fri, Aug 9, 2013 at 2:13 AM, Paolo Carlini <firstname.lastname@example.org> wrote:
> .. another thought I had, less esoteric ;) is the following: we use tf_none
> for two rather different reasons: for SFINAE and to avoid recursive Error
> routines calls, when we call tsubst (... tf_none, ...) from
> I understand, given your reply, that in general in the first case, thus
> SFINAE, we should avoid all hard errors *but* the one about too deep
> recursions (barring some sort of powerful infinite recursion detector). What
> about the second case, however? Should it be different? An error message is
> being produced in any case, for a reason or another, it shouldn't be
> prevented or made more difficult only because there is deep recursion
> somewhere. I think that in that second case we should suppress the error
> message about too deep recursion too. But how to tell it apart? Looks like
> we want some sort of separate tf_*, a tf_in_diagnostic, or something, very
> similar to tf_none, but truly with no exceptions. Actually this vague idea
> occured to me a number of times, I think having that would help in a number
> of situations.
> What do you think?
> (*) Maybe there is third one, like in some recent tweaks Jakub did, but
> let's leave it alone here.
I think we should find ways to have the pretty printer in the
diagnostic framework stop trying to redo most of the work
done by the type checker. In its current form, that is fragile.