[Bug c++/61754] New: [C++1y] [[deprecated]] attribute warns annoyingly compared to __attribute__((deprecated))

[Bug c++/61754] New: [C++1y] [[deprecated]] attribute warns annoyingly compared to __attribute__((deprecated))

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61754

            Bug ID: 61754
           Summary: [C++1y] [[deprecated]] attribute warns annoyingly
                    compared to __attribute__((deprecated))
           Product: gcc
           Version: 4.10.0
            Status: UNCONFIRMED
          Severity: minor
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: daniel.kruegler at googlemail dot com

The following code, compiled with 4.10.0 20140707 (experimental) using the
compiler settings:

-Wall -Wextra -std=c++1y -pedantic

//-----------------
struct __attribute__((deprecated)) Old1 {};

Old1 old1 __attribute__((deprecated));

struct [[deprecated]] Old2 {};

Old2 old2 [[deprecated]]; // ##

int main() {}
//-----------------

produces a warning on the line marked with ##:

"warning: 'Old2' is deprecated (declared at prog.cc:5)
[-Wdeprecated-declarations] 
 Old2 old2 [[deprecated]]; 
                        ^"

Note that the corresponding example using type Old1 does not so. Is the
difference in behaviour intended? I'm pretty sure that either variant is
conforming, but this has the effect that it makes [[deprecated]] much less
attractive in real-world code bases.

Please let me know whether the difference is due to your reading of the
standard, in this case I would like to submit a core language issue to make the
wording clearer for such situations.

[Bug c++/61754] [C++1y] [[deprecated]] attribute warns annoyingly compared to __attribute__((deprecated))

[emsr at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61754

emsr at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |emsr at gcc dot gnu.org
           Assignee|unassigned at gcc dot gnu.org      |emsr at gcc dot gnu.org

--- Comment #1 from emsr at gcc dot gnu.org ---
This is not my reading of the standard- which isn't really clear on when a
message is to be written.  This issue is known.

[Bug c++/61754] [C++1y] [[deprecated]] attribute warns annoyingly compared to __attribute__((deprecated))

[ville.voutilainen at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61754

Ville Voutilainen <ville.voutilainen at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-12-08
                 CC|                            |ville.voutilainen at gmail dot com
     Ever confirmed|0                           |1
      Known to fail|4.10.0                      |5.0

[Bug c++/61754] [C++1y] [[deprecated]] attribute warns annoyingly compared to __attribute__((deprecated))

[herring at lanl dot gov]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61754

S. Davis Herring <herring at lanl dot gov> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |herring at lanl dot gov

--- Comment #8 from S. Davis Herring <herring at lanl dot gov> ---
This also strikes in cases like

  struct [[deprecated]] S {};
  struct T {[[deprecated]] S *backwards() const;};
  [[deprecated]] inline bool f(T t) {return t.backwards();}

where the whole interface is deprecated.  Even given the assumption that T's
author controls f, T can't provide a non-deprecated alternative to T::backwards
because its declaration would already provoke a warning.

Clang and ICC don't warn here, although MSVC issues two.