Bug 347462 - Copy constructor not resolved as implicit name
Summary: Copy constructor not resolved as implicit name
Status: RESOLVED FIXED
Alias: None
Product: CDT
Classification: Tools
Component: cdt-parser (show other bugs)
Version: 8.0   Edit
Hardware: PC Windows 7
: P3 minor (vote)
Target Milestone: 8.0.1   Edit
Assignee: Markus Schorn CLA
QA Contact: Doug Schaefer CLA
URL:
Whiteboard:
Keywords: contributed
Depends on:
Blocks:
 
Reported: 2011-05-27 10:23 EDT by Thomas Corbat CLA
Modified: 2011-07-04 05:42 EDT (History)
2 users (show)

See Also:


Attachments
Patch: Workaround for identical types (1.34 KB, patch)
2011-05-27 10:23 EDT, Thomas Corbat CLA
no flags Details | Diff
Improved workaround capable of dealing with inheritance (1.38 KB, patch)
2011-05-27 10:40 EDT, Thomas Corbat CLA
mschorn.eclipse: iplog+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Corbat CLA 2011-05-27 10:23:17 EDT
Build Identifier: I20110512-2000

In the simple code below I would expect to have the copy constructor (of X) attached as an implicit name in the declarator node of "x2". This did not occur in version 7.0 but is observable on 8.0.

-----------------
struct X {
  X(){}
  ~X(){}
  X(X const & x){}
};

int main() {
  X x;
  X x2 = x;
  return 0;
}
-----------------

Conversion constructor works fine. I expect the problem in the following area:
In CPPSemantics.findImplicitlyCalledConstructor() the call Conversions.checkImplicitConversionSequence(type, sourceType, isLValue, UDCMode.ALLOWED, Context.ORDINARY) for identical "type" and "sourceType" returns a "Cost" which returns "true" for "converts()" but does not provide "c.getUserDefinedConversion()". I'm not sure though whether it is generally correct to change the bevhavior there.

I've attached an attempt for an easy workaround which prevents checking the conversion sequence by directly creating a "Cost" through "Conversions.copyInitializationOfClass()". While this satisfies the core unit tests, it does not work for copy construction of a derived class.

-----------------
struct X {
  X(){}
  ~X(){}
  X(X const & x){}
};

struct Y : X {
};

int main() {
  Y y;
  X x = y;
  return 0;
}
-----------------

Probably Markus can find a better solution. :)

Reproducible: Always
Comment 1 Thomas Corbat CLA 2011-05-27 10:23:58 EDT
Created attachment 196764 [details]
Patch: Workaround for identical types
Comment 2 Thomas Corbat CLA 2011-05-27 10:40:38 EDT
Created attachment 196767 [details]
Improved workaround capable of dealing with inheritance

While the first patch was of quite limited use and had a probably incorrect equal-comparison, the second attempt works for inheritance structures as well.
Comment 3 Markus Schorn CLA 2011-05-30 03:00:45 EDT
(In reply to comment #2)
> Created attachment 196767 [details]
> Improved workaround capable of dealing with inheritance
> While the first patch was of quite limited use and had a probably incorrect
> equal-comparison, the second attempt works for inheritance structures as well.

Thomas, thanks for reporting the issue. Your patch is a good fix for the problem.
Comment 4 Markus Schorn CLA 2011-07-04 05:42:15 EDT
Applied patch and added a test-case.