On Sun, Jun 16, 2019 at 12:36:58PM -0400, Marek Polacek wrote:
> On Sun, Jun 16, 2019 at 06:18:56PM +0200, Jakub Jelinek wrote:
> > On Sun, Jun 16, 2019 at 12:10:37PM -0400, Marek Polacek wrote:
> > > > Guess I will really have to make the changes to treat [[noreturn]]
> > > > similarly
> > > > to e.g. [[nodiscard]], so that cxx11_attribute_p works.
> > >
> > > Thus. Changes I've made:
> > > * don't treat [[noreturn]] as an equivalent to __attribute__((noreturn));
> > > * for that I had to adjust decl_attributes, it wasn't preserving the
> > > C++11 form (a list in another list); fix shadowing while at it;
> > > * the above turned up two spots that were wrongly accessing TREE_PURPOSE
> > > directly instead of using get_attribute_name;
> > > * give error only for [[noreturn]] but not for __attribute__((noreturn))
> > > or [[gnu::noreturn]].
> > >
> > > Bootstrapped/regtested on x86_64-linux, ok for trunk?
> >
> > I'd prefer to defer review of this to Jason, just want to note that I don't
> > see any testsuite coverage on mixing declarations with different forms of
> > attributes ([[noreturn]] on one decl and __attribute__((noreturn)) or
> > [[gnu::noreturn]] on another one or vice versa.
>
> Added now. I suppose it should compile fine, which it does.
I meant also the tests of the new diagnostics, say if you have
a decl without any of those attributes, then gnu:: one (or __attribute__
one; that merge decls should be ok) and on third decl [[noreturn]] (shall
that diagnose anything or not? As there is no way to differentiate it from
the gnu:: attribute on the very first one, I'd say it shouldn't, with the
use of the gnu:: or __attribute__ we are already outside of the standard.
Jakub
