| Summary: | Ctor name gets resolved to CPPClassType instead of CPPConstructor | ||
|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Sergey Prigogin <eclipse.sprigogin> |
| Component: | cdt-parser | Assignee: | 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: | |||
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'. 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.
(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. |
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.