Re: [C++ PATCH] [PR2204] Check for parameters of abstract types - Take 3

["Giovanni Bajo" <giovannibajo at libero dot it>]

Mark Mitchell wrote:

>> I will have to create a different incomplete_vars list which stores
>> couples of IDENTIFIER_NODE and TREE_TYPE instead of declarations,
>> for the purpose of delayed evaluation of abstractness.
>
> I'm sure I'm being dense, but can you back up and explain why we need
> to save away information at all?

Yes. See also comment #3 in Bugzilla, which I quote:

------------------------
The problem is that we currently check for abstractness of parameter types in
gorkparms, which is way too early for the current class. Putting it into
start_function is a stop-gap, but 10.4/3 says that *declarations* are ill-
formed, there is no need for a definition.
------------------------

[class.abstract]/3:
------------------------
An abstract class shall not be used as a parameter type, as a function return
type, or as the type of an
explicit conversion. Pointers and references to an abstract class can be
declared. [Example:

shape x; // error: object of abstract class
shape* p; // OK
shape f(); // error
void g(shape); // error
shape& h(shape&); // OK

--- end example]
------------------------

It is not actually as explicit as I recalled, but I guess that the meaning is
obvious: the declarations are ill-formed, there is no need for definition.
Also, EDG agrees and diagnose such declarations.

> Are we trying to detect cases like
>
>    struct S;
>
>    void f(S s);
>
>    struct S {
>      virtual void g() = 0;
>    };
>
> where "f" has a parameter with an abstract type?

Exactly. If you look in the testcase of my patch, it checks for some slightly
different situations which require delayed evaluation of abstract types. The
testcase was carefully constructed thinking of different situations.

> Does the standard actually require us to diagnose this case?

This is my understanding.

> Presumably, we would already diagnose it if someone tried to call or
> define "f"?

Yes, we do that at the definition point. Calling f() is impossible: if use *s
with a S*, we get an error because we cannot allocate the temporary.

Giovanni Bajo