Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 393084

Summary: Ctor name gets resolved to CPPClassType instead of CPPConstructor
Product: [Tools] CDT Reporter: Sergey Prigogin <eclipse.sprigogin>
Component: cdt-parserAssignee: Project Inbox <cdt-parser-inbox>
Status: RESOLVED INVALID QA Contact: Markus Schorn <mschorn.eclipse>
Severity: normal    
Priority: P3 CC: cdtdoug, yevshif, zeratul976
Version: 8.1.1   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard:

Description Sergey Prigogin CLA 2012-10-29 14:06:12 EDT
Ctor name in a ctor call expression gets resolved to CPPClassType instead of CPPConstructor. In the following code select "A" in "A(1)". Notice that "A" gets highlighted in the first and the fourth lines, but not in the second line.

struct A {
  A(int x);
};

A a = A(1);

This may seem like a minor annoyance, but it causes bug 393068.
Comment 1 Markus Schorn CLA 2012-12-17 03:11:02 EST
Note, that 'A(1)' is not a constructor call (there is no such notion), it is a type cast in functional notation, which is semantically the same as the cast expression '(A) 1'.
Comment 2 Sergey Prigogin CLA 2012-12-17 13:18:06 EST
Resolution to CPPClassType as opposed to CPPConstructor makes a lot of sense. Among other things it helps preserve the typedef in a situation like:

struct A {
  A(int x);
};

typedef A B;

auto a = B(1);

Implicit ctor call should be attached to an implicit name, not to the type id.
Comment 3 Nathan Ridge CLA 2013-01-19 22:54:35 EST
(In reply to comment #2)
> Resolution to CPPClassType as opposed to CPPConstructor makes a lot of
> sense. Among other things it helps preserve the typedef in a situation like:
> 
> struct A {
>   A(int x);
> };
> 
> typedef A B;
> 
> auto a = B(1);
> 
> Implicit ctor call should be attached to an implicit name, not to the type
> id.

Should we apply this to "new B(1)" as well?

Right now, two different pieces of code compute the constructor being called in a new expression: the bit after the call to convertClassToConstructor() in CPPSemantics.postResolution(), which gets the explicit binding, and the bit in CPPSemantics.findImplicitlyCalledConstructor() (called from CPPASTNewExpression.getImplicitNames()), which gets the binding attached to the implicit name. This seems like an unnecessary duplication of work.