Poisoning in HotSpot

[Kim Barrett]

On 12/4/24 7:42 AM, Kim Barrett wrote:
> On 12/1/24 7:09 PM, David Holmes wrote:
>>
>> Somewhat crude but couldn't gtests #define USING_GTEST before 
>> including our headers and then we could make the forbidden stuff 
>> conditional on ifndef USING_GTEST. ?? 
>
> Things are more complicated than that, unfortunately.
>
> I think I might have a way forward, in part using that kind of thing.  
> But it might interfere with other future work.
>
>
I have something very sketchy that "works", using the namespace 
manipulation.
That's in the sense that I can build with all three of gcc, clang, and 
VS, and
get build failures if the permission mechanism isn't used where needed.
However, I think it's very fragile, and I'm not happy with it.

The fundamental problem is that there isn't a way to turn it off over some
non-local region. This leads to problems when header that isn't ours but is
included by us uses any of the names we want to poison. It means such 
headers
must be included before the poisoning. We haven't run into this problem much
because glibc takes great pains to not be affected by outside 
definitions, via
all the leading underscores in that code. Other libraries, not so much. For
example, several names that we poison are referenced by the <new> header 
from
clang/Xcode.

This could be worked around to some extent by putting wrappers around 3rd
party headers that provide names we poison, and including those wrappers
instead of directly including the 3rd party headers.  Those wrappers could
contain the poisoning of names from the wrapped header, and before that
include any other using 3rd party headers.  But this is pretty clumsy, with
lots of overinclusions where not needed if not for the poisoning. It also
seems very fragile.

I might still consider that route if there wasn't another alternative.
Fortunately, I think there is.

I think I've figured out how to get the "add deprecation attributes" 
approach
to work with all three compilers.  In particular, I've figured out how to
augment declarations in MSVC++, which had previously eluded me.

This also runs into problems with our inclusion of 3rd party headers 
that use
names we want to poison. But unlike the namespace manipulation approach, 
this
approach has a way to suppress the poisoning over a non-local region, e.g.
using appropriate pragmas in a pragma-push/pop range. So to solve a problem
like clang's <new>, we add a wrapper that disables deprecation warnings 
around
inclusion of that header, and we include the wrapper rather than <new>
directly.

I've done a bit of prototyping in this direction, and I think I've come up
with a pretty good approach.  It's not completely bullet-proof, but 
neither is
the current mechanism, nor the namespace manipulation mechanism. But I think
this 3rd approach has better usage features and is easier to maintain.  I'll
describe it in more detail once I've got something more fully worked out.