Bug 313713

Comment 1 Markus Schorn 2010-05-20 10:31:34 EDT

Introducing a separate binding for the TemplateClass<TYPEINT> would cause other issues:

Different to a typedef you'd have no way to get the expanded version of the type (for a typedef you use 'ITypedef.getType()') . This especially important when you have an explicit specialization
   template<> class TemplateClass<int> {};
How could you figure out that 'TemplateClass<TYPEINT>' denotes the explicit specialziation 'TemplateClass<int>'?

Also consider the reverse of having an explicit specialization 'TemplateClass<TYPEINT>'. How would you see that 'TemplateClass<int>' denotes 'TemplateClass<TYPEINT>'?

Comment 2 Pavan V 2010-05-21 05:32:02 EDT

Markus, not sure I understand your comment fully.

Am not asking for a separate binding for TemplateClass<TYPEINT>, am only saying that the template argument inside the template instance here should hold ITypedef (instead of the IBasicType it holds here). From the ITypedef I can always do a getType() and retrieve the IBasicType - but the other way round is not possible

Guess, CDT should be setting an ITypedef object on the template argument instead of the resolved type, as is the case with the setting of the type of a variable.

Comment 3 Markus Schorn 2010-05-21 08:24:01 EDT

(In reply to comment #2)
> Markus, not sure I understand your comment fully.
> 
> Am not asking for a separate binding for TemplateClass<TYPEINT>, am only saying
> that the template argument inside the template instance here should hold
> ITypedef (instead of the IBasicType it holds here). From the ITypedef I can
> always do a getType() and retrieve the IBasicType - but the other way round is
> not possible
> 
> Guess, CDT should be setting an ITypedef object on the template argument
> instead of the resolved type, as is the case with the setting of the type of a
> variable.

As soon as you request that the binding for the template instance (ICPPTemplateInstance) returns the typedef as the template argument (ICPPTemplateInstance.getTemplateArguments()) you do ask for two different bindings to represent 'TemplateClass<int>' and 'TemplateClass<TYPEINT>'.

This would lead to the issues outlined above because there would be no link between the two bindings although they denote the same type.

Comment 4 Pavan V 2010-05-24 03:37:58 EDT

That would be the case in all places where a typedef can be used (as variable types, method parameter types, etc). When the typedef is represented as ITypedef in the binding in all these cases, why make an exception for a template argument ?

What I mean is, consider a method -

RETURN_TYPE testMethod(){
}

where RETURN_TYPE is a typedef denoting int.

If you notice the binding object for testMethod(), it can be seen that the return type of the method is a CPPTypedef object and not IBasicType. How does CDT link this to the method binding of -

int testMethod(){
}

I'm sure in all cases involving typedefs, there is internal logic to resolve to the final type from the typedef (using the call getType() on the typedef i suppose?) - the same should hold good for template arguments as well.

Comment 5 Markus Schorn 2010-05-25 07:01:48 EDT

(In reply to comment #4)
> That would be the case in all places where a typedef can be used (as variable
> types, method parameter types, etc). When the typedef is represented as
> ITypedef in the binding in all these cases, why make an exception for a
> template argument ?

I see your point. Note, that providing the typedef in the variable/function binding is and cannot be consistent. As soon as you use different notations for a type in a variable/function declaration the type returned by the binding will randomly be one of the versions. --> The type as specified by the user is not really a property of the binding, rather than that it is a property of a specific declaration. For variables and functions it is quite likely that the types are equally denoted in all declarations. Therefore, in general there will
be no surprises.

Given the complexity of template instantiation I am reluctant introduce a model that includes this random behavior. Therefore I argued that I'd need separate bindings for different versions of the same instantiation. 

I guess there is room for an implementation that randomly returns one of the notations for the template argument. However, this is not a small change and has some risk. Despite such a change, you would likely run into a situation where an unexpected version of argument is returned, because there are many instantiations (compared to the number of declarations for a function/variable).

--> A risky change that yields a potentially unsatisfactory situation.

Comment 6 Pavan V 2010-05-27 02:23:21 EDT

I get your point. 
Perhaps, we could use the information in the AST to know if the argument is a typedef or not. As to implementing the tricky change, you can take a call on it. All I feel is that there should be some consistency in the design.

Comment 7 Markus Schorn 2010-05-27 03:38:36 EDT

(In reply to comment #6)
> I get your point. 
> Perhaps, we could use the information in the AST to know if the argument is a
> typedef or not. As to implementing the tricky change, you can take a call on
> it. All I feel is that there should be some consistency in the design.

I try to look into this for the next release.