Re: [3.4 PATCH] PR c++/20995: Type-unsafe trees for templates

[Mark Mitchell <mark at codesourcery dot com>]

Roger Sayle wrote:
> The following patch is my proposed solution for PR c++/20995.  Looking
> through the code in the C++ front-end, I'll admit that I'm a bit shocked
> and in one of those how could C++ templates have ever worked dazes.

That reflects a fundamental on your part to understand how, or perhaps 
why, the C++ front end works the way it does.  That's not meant as an 
insult; I'm not claiming it's obvious.

The bodies of C++ templates are not valid GENERIC, nor are they meant to 
be.  It is not until template instantiation that these bodies look like 
normal code.  In general, there's no way that these bodies could be 
valid code because they involve operations of unknown type; that's what 
the template parameters are.  The language requires that in certain 
circumstances we figure out what the types of "non-dependent" 
expressions are -- but it still doesn't make sense to actually build 
real trees for those expressions until instantiation time.  (There are 
other steps that we have to take at instantiation time that need to be 
repeated in each instantiation, for example.)

Most leaks of uninstantiated templates outside of the front end are 
bugs.  There are exceptions, like calling simple DECL_P-style 
predicates, etc., but certainly calling fold is a bug.   But, as I've 
explained several times, calling fold from the C++ front end proper is a 
bug anyhow.  The only time we should be calling fold is during 
conversion to GENERIC, as we're about to present the middle end with 
code it needs to understand.

I'm actually not sure why the issues around fold remain so troubling to 
you.  I understand why you think that fold is valuable, but I'm not sure 
why you think it's something that ought to be called as expressions are 
parsed, rather than at a later point when they are to be presented to 
the middle end.

> For gcc 4.x, this issue has been resolved by Mark's patch for bugzilla
> PR c++/17642, that introduces a new function fold_if_not_in_template,
> that avoids ever calling "fold" whilst processing template declarations.
> That PR was also just another symptom of the fact that g++ doesn't
> create valid trees for templates until they are instantiated.

The word "symptom" isn't appropriate because there's no "disease" here. 
 The behavior you note is by design and identical to the analagous 
behavior in other C++ front ends.  The bug is just that for historical 
reasons we're calling fold at what is clearly the wrong time.

I agree that backporting fold_if_not_in_template along with all of its 
uses would be too risky.  But how about just backporting the function 
and using it from the two places you identified?  I expect that would 
work, and would be slightly preferable in that it would reduce 
divergence.  That change is preapproved, assuming it works OK.

Thanks,

--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304