Re: -Wmissing-pure/-Wmissing-const/-Wmissing-nothrow

[Jan Hubicka <hubicka at ucw dot cz>]

> > I think in earlier discussion we concluded that all cases you get the
> > warning, throw() won't cause any problems.
> 
> I do not think we reached that conclusion.  Here is what I meant.
> 
> Assume you have
> 
>      struct A {
>         virtual int f() const { return 1; }
>      };
> 
>      struct B : A {
>         virtual int f() const { return 42; }
>      }
> 
> If someone adds 'throw()' to A::f, then B gets into trouble.
> That is what I meant.  I do not have a recollection that we
> reached the conclusion that that is not a problem.

OK, but how you would like this to change behaviour of the warning (or
note?).  From backend POV the way to detect __attribute__ ((nothrow)) as
well as throw() markers is equivalent, so I don't see much way how
compiler can make difference here.
> >
> > Concerning -Wmissing-* stuff, I just copied what we do for
> > -Wmissing-noreturn warning. ?Do we want to change that one too?
> 
> I think that case is different from what you're proposing.

This is all about autodetecting decorations user can put into source to
help compiler.  In all these cases functions are reported as candidates
for consideration by user. -Wmissing-noreturn documentation is bit more
cureful about that fact:

Care should be taken to manually verify functions actually do not ever
return before adding the @code{noreturn} attribute, otherwise subtle
code generation bugs could be introduced.  You will not get a warning
for @code{main} in hosted C environments.

"missing" word in the flag name might be giving bit too strong hint for
user to follow the warning/note without verification, but
-Wattribute=nothrow don't seem to be significandly cleander to me given
the fact that one can base throw() markers on it as well given the
situation.

In general both cases seems somewhat inexact to me, I don't have any
strong reservation to -Wattribute=<list> switch either, so if it is
preferred, I will update patch.

Honza
> 
> >
> > Honza
> >