Simplifying the poisoning mechanism used in HotSpot

[Julian Waters]

Argh, there's no one good way to poison in C++ after all. I guess the
language wasn't really designed for that. I explored other ways, such
as symbol checking the compiled code for forbidden symbols like we do
with operator new, but that couldn't work as there's no way to attach
metadata to a method to permit using it where needed. Templates aren't
even seen by the compiler, and a C++ static analyzer I tried to write
specifically for HotSpot was scrapped after I realized I would have to
pass the exact defines in the command line passed to the compiler to
the static analyzer, as well as match each and every compiler's
intrinsic defines as well, an impossible task.

I did notice googletest makes heavy use of namespaces however. I'm not
sure if there are any other 3rd party libraries in use (The previous
mail seems to imply other libraries are used for HotSpot besides
googletest) or if we will add any more, but injecting a using
declaration into the googletest namespace (Done without editing the
third party code) does bypass the inline namespace and compiles
without issue. Under the assumption that googletest will be the only
third party code HotSpot will ever use, this might be a viable way to
solve the permitting problem, but the old issue of the error being an
ambiguity one instead of a proper "This method is forbidden" warning
unfortunately still applies.

best regards,
Julian

On Mon, Aug 18, 2025 at 9:55 AM Kim Barrett <kim.barrett at oracle.com> wrote:
>
> On 8/17/25 2:43 PM, Julian Waters wrote:
> > [...] you couldn't control it, meaning there was no way to
> > permit forbidden methods.
>
> My recollection is that the problem is not that there's no way to permit
> forbidden functions where needed in our code, it's that there's no way to turn
> off the forbidding for third party code (such as the gtest framework).
>
> If all HotSpot code were in a namespace, we could easily poison via non-usable
> declarations within that namespace, without affecting third party code in
> other namespaces (including the global namespace). (And also without affecting
> our ability to escape out where needed.) But that's not a thing.
>