Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[cdt-dev] Fw: Need advice from a binding resolution expert


Forgot to cc the list in my reply to Sergey.

----- Forwarded by Andrew Niefer/Ottawa/IBM on 01/28/2008 11:30 AM -----
Andrew Niefer/Ottawa/IBM

01/28/2008 11:26 AM

To
"Sergey Prigogin" <eclipse.sprigogin@xxxxxxxxx>
cc
Subject
Re: Need advice from a binding resolution expertLink




Sergey,

I forget most of the details around this area of the code, but I would suggest a subclass of CPPUnknownClass, perhaps CPPUnknownClassTemplate.
This class should probably implement both ICPPClassTemplate and ICPPInternalClassTemplate.

I think this class would need to behave in a manner similar to a CPPTemplateTemplateParameter in that instantiating it results in a deferred instance.
The CPPASTTemplateId for "template rebind<_TP>" will have 2 bindings, one for the template-id "rebind<_TP>" and one for the contained template-Name "rebind".
I would expect the contained template name "rebind" to be the CPPUnknownClassTemplate.  When that binding is instantiated to make "rebind<_TP>" I think we want the result to be  a CPPDeferredClassInstance (see CPPTemplates.instantiateTemplate and the call to deferredInstance, this would probably need to happen even if the argument (_TP here) wasn't a template parameter).

I don't remember the details at instantiation time, so I'm not sure what you will need to get the Vec<int> instantiation working, if you are lucky it might just work.  Otherwise, you might needCPPUnknownClassTemplate to override CPPUnknownBinding.resolveUnknown.  Similarily, you might need to do extra work in CPPTemplates.instantiateType (both the ICPPInternalDeferredClassInstance and the ICPPInternalUnknown cases )

The last item is that I'm not sure if CPPUnknownClassTemplate will require a CPPUnknownTemplateScope or if giving it a CPPUnknownScope is sufficient.

hope this helps,
Andrew


"Sergey Prigogin" <eclipse.sprigogin@xxxxxxxxx>

01/28/2008 02:06 AM

To
Andrew Niefer/Ottawa/IBM@IBMCA
cc
"CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Subject
Need advice from a binding resolution expert





I'm looking for a way to fix binding resolution in the following example (see AST2TemplateTests._testRebindPattern_214447):

template<typename _TpAllocator>
class Allocator {
public:
 typedef _TpAllocator& alloc_reference;
 template<typename _TpRebind>
 struct rebind {
   typedef Allocator<_TpRebind> other;
 };
};

template<typename _Tp, typename _Alloc = Allocator<_Tp> >
class Vec {
public:
 typedef typename _Alloc::template rebind<_Tp>::other::alloc_reference reference;
};

void f(Vec<int>::reference r) {}

This example is derived from STL code. Making it to work is necessary for interpretation of most STL collections and basic_string.

Name resolution looses information while trying to resolve "rebind" in the context of _Alloc::template rebind<_Tp>. Since _Alloc is CPPUnknownScope, "rebind" gets resolved to CPPUnknownClass. CPPUnknownClass doesn't implement ICPPInternalTemplateInstantiator, which means that the fact that "template rebind<_Tp>" refers to a template instance gets lost. As a result, "reference" remains CPPUnknownClass and name resolution fails.

I'm thinking of either adding ICPPInternalTemplateInstantiator to CPPUnknownClass or creating a subclass of CPPUnknownClass that implements ICPPInternalTemplateInstantiator. Please tell me your opinion about this approach.  What other ways to handle this problem are possible? Your advice will be highly appreciated.

-sergey


Back to the top