On 04/12/2012 05:08 PM, Jason Merrill wrote:
The fixup stuff is a solution to the problem of typedefs with incompatible
template parameters leading to crashes, but it seems to me that this is just a
symptom of the problem of replacing one typedef with another, and we should
attack that underly
Sorry for the delay in getting back to you on this; I just keep thinking
there has to be a better way to deal with this issue than this
increasingly complex fixup machinery.
The basic problem we're dealing with is that two typedefs from different
contexts are considered identical for the purpo
On 01/26/2012 05:15 PM, Dodji Seketeli wrote:
Jason Merrill writes:
Hmm...what if rather than trying to ignore levels when comparing, we
make it so the sibling list always has level 1?
I am not sure to understand how you'd do that. You mean that instead of
pointing to the actual vector of i
Jason Merrill writes:
> Hmm...what if rather than trying to ignore levels when comparing, we
> make it so the sibling list always has level 1?
I am not sure to understand how you'd do that. You mean that instead of
pointing to the actual vector of innermost template parms,
TEMPLATE_PARM_SIBLING
Hmm...what if rather than trying to ignore levels when comparing, we
make it so the sibling list always has level 1?
BTW, let's avoid calling a function named *_real directly from client code.
Jason
> How about if we just store a pointer to the template parameter list
> and do comp_template_parms?
I tried a variation of this approach below. My understanding is that
comp_template_parms wouldn't work as is, at least because it can lead to
an endless recursion:
Suppose we start comparing the f
On 11/17/2011 04:21 PM, Dodji Seketeli wrote:
+ parm = TREE_VALUE (parm_desc);
+ if (TREE_CODE (parm) == TYPE_DECL)
+ val = iterative_hash_template_parm_index_no_level
+ (TEMPLATE_TYPE_PARM_INDEX (TREE_TYPE (parm)), val);
+ else if (TREE_CODE (parm) == TEMPLATE_DECL)
