[PATCH] PR c++/26693

Jason Merrill jason@redhat.com
Tue Dec 2 17:06:00 GMT 2008


Dodji Seketeli wrote:
> Jason Merrill a écrit :

>> A non-dependent typedef doesn't have the same template args as its 
>> containing class?  Why isn't the call to push_template_decl from 
>> grokfield setting that up properly?
> 
> I think it's because the chain of calls was triggered by a 
> fold_non_dependent_expr that calls tsubst_copy_and_build with a NULL 
> args argument.

Oh I see, the typedef has the right args, we just don't have anything to 
substitute into them.

> I am not sure but I'd say that given that we are calling 
> tsubst_copy_and_build with a NULL args, all the tsubst_* routines should 
> be able to handle the case of args == NULL somewhat gracefully. 
> Shouldn't we ?

Yes, I guess if we call tsubst with NULL args, we should just return t 
since we can't do any substitution.  For the case where we're calling it 
from fold_non_dependent_expr, that's the result we're looking for anyway.

However, it sounds like something's broken if we encounter a 
TEMPLATE_PARM_INDEX in something that we're trying to fold as 
non-dependent.  What's the testcase?

> clone_underlying_type

I still find the use of this for builtins confusing, since we aren't 
doing any cloning in that case.  Maybe change the name to 
set_underlying_type?

Also, better to put this and is_typedef_type in c-common.c rather than 
tree.c; they don't apply to other languages.

> 	* tree.h: Added a new member member_types_needing_access_check to
> 	struct tree_decl_non_common.

No; we shouldn't make most decls larger for the sake of something that's 
local to the C++ front end.  I think you can use a TEMPLATE_DECL's 
DECL_LANG_SPECIFIC(decl).u2.access for this list.

> 	* parser.c (cp_parser_nonclass_name): When a typedef that is a member
> 	of a class appears in a template, add it to the template.

Does this handle typedefs of class type?  The standard says that a 
typedef that names a type is a class-name.

I would expect it to be simpler to handle this as another case in 
perform_or_defer_access_check; i.e. if we're in a template defer by 
adding it to the list of access checks for this template.

> +append_type_to_template_for_access_check (tree type,
> +                                          tree type_decl,
> +					  tree scope)
> +{
> +  tree node, templ;
> +
> +  gcc_assert (type
> +	      && get_template_info (type)
> +	      && TI_TEMPLATE (get_template_info (type))
> +	      && type_decl
> +	      && (TREE_CODE (type_decl) == TYPE_DECL));

Don't we need to do the same thing in function templates?

Jason



More information about the Gcc-patches mailing list