Re: [C++ PATCH] [PR2204] Check for parameters of abstract types (partial fix) - Take 2

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

"Giovanni Bajo" <giovannibajo@libero.it> writes:

| Gabriel Dos Reis wrote:
| 
| > What I don't understand is the use of '%J' in lieu of xxx_at.
| 
| This is a revised patch, which uses the form suggested by you. It also now
| emits the first note line ("because the following virtual..." / "since it has
| pure...") on the declaration of the type which is found to be abstract, which
| can be a good reference for the user: in fact, the pure virtual function
| declarations could be in a differnt point, many files away from the type which
| the user is trying to instantiate.

I totally agree (at least, that has been my case these last days).

| I can happily revert back to %J if it turns out to be better for some reason.
| Actually, everybody can in a few seconds, and I reckon the discussion about it
| is orthogonal to my patch.
| 
| Retested on i686-pc-linux-gnu with no new regressions. OK for mainline?

The diagnostic part is OK with me (I think that the rest also makes
sense).  However, you'll need Jason or Mark's approval for the rest.

| ---------- quote -----------
| Alas, this solution is partial, mainly because it doesn't get into account
| array types. In fact, parameters with array type are decayed into pointer types
| within grokdeclarator (even before a PARM_DECL is built), so they never get
| registered into the incomplete_vars list. A solution for this might be
| extracting the standard decays out of grokdeclarator, and having grokparms call
| it. There is also another user of grokdeclarator(PARM) (in pt.c, to build
| template parameters), which should be updated as well. Comments on this plan
| are highly appreciated.
| 
| Another case we don't handle yet is when the type of the parameter is
| dependent. In that case, we probably need to check for abstractness upon
| instantiation, while tsubsting. I'll investigate.
| ---------- end quote -----------
| Any comments on this?

I think I would have gone with Jason's suggestion -- putting those
parameter types in a separate list -- but your  partial solution does
no harm I suppose. 

-- Gaby