[cfe-dev] Diagnosing initialization of deprecated data member?

[Richard Smith via cfe-dev]

On Thu, 7 May 2020 at 01:52, Stephan Bergmann via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> For
>
> > $ cat test.cc
> > struct S {
> >     int x;
> >     [[deprecated]] int y;
> > };
> > int main() {
> >     S s{0, 0};
> > }
>
> Clang emits a diagnostic
>
> > $ clang++ test.cc
> > test.cc:6:12: warning: 'y' is deprecated [-Wdeprecated-declarations]
> >     S s{0, 0};
> >            ^
> > test.cc:3:7: note: 'y' has been explicitly marked deprecated here
> >     [[deprecated]] int y;
> >       ^
> > 1 warning generated.
>
> while e.g. GCC and MSVC do not (as checked with godbolt.org).
>
> Is this deliberate behavior on Clang's part, or just a consequence of
> how the code happens to work?  Are there opinions on whether or not the
> behavior is useful?
>

I think it's probably a bug. The C++11 attribute is documented as
deprecating the name, not the existence of the entity, so diagnosing a use
that doesn't use the name seems somewhat questionable. (It's not obviously
a bad choice, though, since the intent is very likely to catch cases that
would break if the field is removed, not only if it's renamed.)

There are a few other warnings channeled through the same path
(`DiagnoseUseOfDecl`), such as "availability" warnings, and it's quite
likely that some of those *should* still be issued for such cases.


> (I came across this issue when seeing a commit in LibreOffice where some
>
> > #pragma GCC diagnostic ignored "-Wdeprecated-declarations"
>
> were added apparently to silence exactly the above situation in code
> initializing a PyTypeObject struct from
> /usr/include/python3.8/cpython/object.h, not even realizing that that
> pragma would only be needed by Clang and not by GCC.
>
> FWIW, the standard's recommended practice is "to produce a diagnostic
> message in case the program refers to a name or entity other than to
> declare it", [dcl.attr.deprecated]/4.)
>

What was the intent in the LibreOffice case? Would they want a warning on
"S s{.x = 0, .y = 0};" but not on "S s{0, 0};"?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200510/7cc6dc9b/attachment.html>