OK, just please add a comment about why we aren't using locate_ctor.
Jason
Hi again,
and sorry about the delay.
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,
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 CLASSTYPE_CONS
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 is
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 delete
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 co
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) =
