This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c++/17729] [4.4/4.5/4.6/4.7 Regression] Duplicate __attribute__((deprecated)) warning


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17729

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #26539|0                           |1
        is obsolete|                            |

--- Comment #25 from Iain Sandoe <iains at gcc dot gnu.org> 2012-02-02 10:51:32 UTC ---
Created attachment 26550
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26550
fix that covers pr50308 as well.

The problem I perceive is that we have a set of tests for deprecation sprinkled
over the code.  This means that each time we uncover a new pathway - e.g.
pr50308 there is (potentially) some amendment required.

What I can't see (because I don't know the c++ FE well enough) is whether there
is a single place that a [possibly more sophisticated] test could be made.

For example, since the deprecation state of items does not alter the outcome of
parsing, but only the presence of warning/error, perhaps when one logically
reaches the ";" that would be a place to check the preceding statement for
deprecated items?

Anyway, the attached patch deals with the fact that we can't check a function
ID for deprecation because it might be later overloaded - but also, that we
can't delegate all of the checking to the call processing - because function
ids might be used without a call.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]