OK, just please add a comment about why we aren't using locate_ctor.
Jason
On 12/01/2011 07:13 AM, Jason Merrill wrote:
Ah, I see. I guess what we want here is the GCC 4.5 version of
locate_ctor instead of the new one; once we've checked that we have a
default ctor and no user-provided default ctor, there must be a unique
defaulted ctor so just walking
Hi,
the below fixes an ICE on invalid which didn't occur in 4.6 (because we
didn't produce the notes). The issue is that for this kind of test:
struct A
{
A(int);
};
struct B : A {};
constexpr int foo(B) { return 0; }
add_implicitly_declared_members sets TYPE_HAS_DEFAULT_CONSTRUCTOR (t)
On 11/30/2011 04:42 PM, Paolo Carlini wrote:
add_implicitly_declared_members sets TYPE_HAS_DEFAULT_CONSTRUCTOR (t) =
1 for B, but then, in explain_non_literal_class, the true value doesn't
imply that locate_ctor actually finds the constructor, due to the nature
of A.
It should find a deleted
Hi,
On 11/30/2011 04:42 PM, Paolo Carlini wrote:
add_implicitly_declared_members sets TYPE_HAS_DEFAULT_CONSTRUCTOR (t) =
1 for B, but then, in explain_non_literal_class, the true value doesn't
imply that locate_ctor actually finds the constructor, due to the nature
of A.
It should find a
On 11/30/2011 06:41 PM, Paolo Carlini wrote:
Ok. The point is, locate_ctor turns an error_mark_node returned by
locate_fn_flags - meaning indeed not callable - into NULL_TREE. In fact,
uses elsewhere of locate_ctor / get_default_ctor always check for it.
Ah, I see. I guess what we want here
