Improve our handling of the second step in a user-defined conversion
sequence. Previously, we weren't permitting the second step to call
copy constructors, which left user-defined conversion sequences
surprisingly broken.
Now, we perform overload resolution among all of the constructors, but
only accept the result if it makes the conversion a standard
conversion. Note that this behavior is different from both GCC and EDG
(which don't agree with each other, either); I've submitted a core
issue on the matter.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@63450 91177308-0d34-0410-b5e6-96231b3b80d8
diff --git a/test/SemaCXX/user-defined-conversions.cpp b/test/SemaCXX/user-defined-conversions.cpp
index 8292c7a..e4b12fc 100644
--- a/test/SemaCXX/user-defined-conversions.cpp
+++ b/test/SemaCXX/user-defined-conversions.cpp
@@ -35,3 +35,35 @@
void h_test(C c) {
h(c);
}
+
+// Test conversion followed by copy-construction
+struct FunkyDerived;
+
+struct Base {
+ Base(const FunkyDerived&);
+};
+
+struct Derived : Base { };
+
+struct FunkyDerived : Base { };
+
+struct ConvertibleToBase {
+ operator Base();
+};
+
+struct ConvertibleToDerived {
+ operator Derived();
+};
+
+struct ConvertibleToFunkyDerived {
+ operator FunkyDerived();
+};
+
+void test_conversion(ConvertibleToBase ctb, ConvertibleToDerived ctd,
+ ConvertibleToFunkyDerived ctfd) {
+ Base b1 = ctb;
+ Base b2(ctb);
+ Base b3 = ctd;
+ Base b4(ctd);
+ Base b5 = ctfd; // expected-error{{cannot initialize 'b5' with an lvalue of type 'struct ConvertibleToFunkyDerived'}}
+}