Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] purpose of "IASTNode point" arguments?

> Hi Nate,
> Dependent names need to be resolved at the point of instantiation, that is what the IASTNode argument refers to.
> In your example 'x' is not a dependent name and it needs to be resolved within the class template.

The name 'x' *is* resolved within the class template (it resolves to a CPPField).

What's not resolved until instantiation is the operator++ in '++x' (and it can't be, 
since the type of 'x' is dependent).

The question is where should the operator++ be looked up?

  1) only at the point of definition
  2) only at the point of instantiation
  3) at both points

CDT seems to currently be doing (2). Some quick tests with gcc suggest that it 
does (1). I will have to look at the standard to be sure.

Regards,
Nate

> ==> There is a bug in creating the evaluation object for the id-expression 'x'.
> Markus.
>
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Nathan Ridge
> Sent: Mon, 04. 02. 2013 03:47
> To: CDT Mailing List
> Subject: [cdt-dev] purpose of "IASTNode point" arguments?
>
>
> Hi,
>
> A number of functions in the C++ semantics code have an argument "IASTNode point"
> which seems to be passed around everywhere. Some examples are:
>
> CPPTemplates.instantiateXXX
> ICPPEvaluation.instantiate
> ICPPEvaluation.getTypeOrFunctionSet
> ICPPEvaluation.getValue
> CPPTemplates.findOverloadedXXX
> ClassTypeHelper.getXXX
> TypeTraits.isXXX
>
> I am wondering, what is the purpose of these "IASTNode point" arguments?
>
> This question came up for me in investigating the behaviour of the following code (from bug 399829):
>
>
> struct S
> {
>     void kind();
> };
> struct T {};
>
> namespace N
> {
>     S operator++(T);
>
>     template <class T>
>     struct impl
>     {
>         static T x;
>         typedef decltype(++x) type;
>     };
> }
>
> void test()
> {
>     N::impl<T>::type operand;
>     operand.kind();  // ERROR HERE: Method 'kind' could not be resolved }
>
>
> The problem here arises because the name lookup for the operator++ in the decltype is performed in the context of the block scope of the 'test'
> function, because the scope for the name lookup is obtained by calling
> CPPVisitor.getContainingScope() on this "point" argument, which gets here all the way from the site of the original name lookup (for N::impl<T>::type) that gave rise to instantiating "impl" and resolving the operator++.
>
> Clearly, something went wrong here, but I can't pinpoint what until I understand what the purpose of this "point" argument is.
>
> Thanks,
> Nate
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
 		 	   		  

Back to the top