Oh, bother, the sysmacros deprecation doesn't work in enough places

[Zack Weinberg]

I just landed the sysmacros deprecation patches in master, and while
annotating https://sourceware.org/bugzilla/show_bug.cgi?id=19239 it
occurred to me to retry Shafik's original test case with these
patches.

It appears that libstdc++ from g++ 5/6 is much less eager to include
<cstdlib> from unrelated headers.  This means the scope of the problem
is considerably reduced.  However, you can still trip it with e.g.

#include <random>

struct A {
  unsigned major;
  unsigned minor;

  A(int major, int minor) :
    major(major), minor(minor){ }
};

And if you test this against glibc master's headers, you *don't* get
the deprecation warnings!

test.cc: In constructor ‘A::A(int, int)’:
test.cc:8:5: error: class ‘A’ does not have any field named
‘__major_from_sys_types’
test.cc:8:19: error: class ‘A’ does not have any field named
‘__minor_from_sys_types’

I think this is because the deprecation message uses
__attribute__((deprecated)), so it triggers on the *function call*,
not the macro expansion.

I'd like to solicit suggestions (hopefully in the form of patches ;-)
for fixing this.  The obvious approach is _Pragma("GCC warning
\"...\"") but I was not able to figure out how to get the nice verbose
here's-how-you-fix-this message from the current approach to work with
this; the problem is that you can't do string constant concatenation
inside _Pragma().  Theoretically the entire thing could be assembled
as bare tokens and then stringified but that seems like a recipe for
having unrelated macros interfere...

zw