RFR: 8314488: Compiling the JDK with C++17

[Kim Barrett]

On Mon, 18 Aug 2025 07:17:09 GMT, Johan Sjölen <jsjolen at openjdk.org> wrote:

>> doc/cpp17-features.md line 128:
>> 
>>> 126: [n4147](http://wg21.link/n4147)
>>> 127: [n4424](http://wg21.link/n4424)
>>> 128: [p0386r2](http://wg21.link/p0386r2)
>> 
>> After looking at inline variables more carefully as part of writing it up for
>> the style guide, I'm inclined to move inline variables to the undecided or
>> forbidden category. They seem to be a solution to a problem I think we don't
>> really have.
>> 
>> Basically, they let you provide the full definition for a non-local variable
>> in a header file, rather than declaring it in the header and defining it in
>> an associated .cpp file. The motivating use-case is a component or library
>> that is header only, to simplify client use by avoiding build issues. But
>> that's just not a thing we care about for HotSpot code.
>> 
>> So what WE get from an inline variable is having a complete declaration and
>> definition in one place, rather than separating the declaration from the
>> definition (so probably saving a little bit of code), at the cost of putting
>> the initialization expression in the header (which might require pulling other
>> stuff into the header), and maybe making the compiler work a little harder.
>> 
>> The benefit of that seems minimal at best.
>> 
>> The one part of it that seems slightly useful is that a constexpr variable is
>> implicitly inline, so doesn't need a definition without an initializer in a
>> .cpp file if the variable is ODR-used. Indeed, that's now treated as a
>> duplicate defintion and deprecated usage. But we haven't had any warnings, so
>> guessing we don't actually have any of those. We can take advantage of this
>> for future usage.
>> 
>> Any other opinions?
>
> It's a bit of ceremony to do the header + source file edits for static variables, but maybe it's one worth living with to not have to explain to people what an inline variable is. I think that they'll be accepting of `static constexpr` variables being defined inline, as there's no inline keyword involved and constexpr is already special anyway.

OK, @jdksjolen and @theRealAph have convinced me. I would have needed to say
something about them anyway, because of the constexpr => implicit inline =>
deprecation of separate definition. Note that the constexpr => implicit inline
is only for static data members, not for ordinary variables; no idea why, but
that's what it says. Also, will be forbidding `inline thread_local`; we
heavily restrict `thread_local` anyway. No idea how `inline` interacts with
the compiler-specific `thread_local` replacements we use, and don't think it's
worth the trouble to explore that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25992#discussion_r2286195483