RFR: 8302124: HotSpot Style Guide should permit noreturn attribute

[Kim Barrett]

On Mon, 13 Feb 2023 02:16:02 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> doc/hotspot-style.md line 1072:
>> 
>>> 1070: * An attribute that appertains to a function is placed at the beginning of the
>>> 1071: function's declaration, rather than between the function name and the parameter
>>> 1072: list.
>> 
>> Sorry to be pedantic but what exactly constitutes the "function declaration"? Does it include keywords like `virtual`? What about placement wrt.  compiler-specific attributes?
>
> As for the function declaration, it's pretty much the entire function, keywords and all, as the C++ Standard always has the attribute specifier sequence appear before everything else (alignas is also an attribute specifier, to that extent), and never between keywords. I'm in favour of adding an extra line also forbidding having the attributes placed behind the function's parameter list brackets though, since HotSpot currently has a ton of attributes that are listed behind the whole function
> 
> I think Kim has stated before that compiler specific attributes don't give much benefit and isn't really interested in having them, that said it would be nice to have them in the future with perhaps the compiler's namespace required in the attribute (msvc::noinline in C++20 guarantees no inlining of a function as compared to our current __declspec(noinline) for instance).

Standard attributes are syntactically permitted in a plethora of places.  But
specific attributes are only allowed in places related to their semantics.
For function declarations (including definitions), this is either first,
before anything else related to the declaration, or after the name of the
function but before the parameter list.

What I've proposed is that HotSpot code prefers putting function attributes
first, rather than immediately after the function name (so before the
parameter list).

Standard attributes can also appear after the parameter list, but those apply
to the function *type* rather than the function.  That differs from gcc
`__attribute__`.

(Standard attributes can also appear after the return type but before the
function name.  Those attributes apply to the return type.  Hoping we don't
need any of those, other than perhaps for alignment.)

I've no idea how standard attributes and gcc `__attribute__` or msvc `__declspec`
interact syntactically.  My hope would be that they can interleave, but I have
no idea whether that's true or not.  I guess some research is needed, though I
think it doesn't matter for the current set.  (I doubt anyone is going to
declare a function both noreturn and always-inline, for example.)

My objection to the earlier proposal to (for example) change ATTRIBUTE_PRINTF
to use `[[gnu::format(printf...)]]` instead of the `__attribute__` form was
that it required moving a lot of the macro uses from the end of a declaration
to its front (because of the above-mentioned difference), so lots of code
changes for not much gain.

Unrecognized attributes cause problems.  C++17 changes that, requiring that
unrecognized attributes be ignored.  That might make some uses of
compiler-specific attributes more palatable, as they can be used directly
rather than behind a macro that is conditionally defined.

OTOH, we might still end up putting some attributes behind conditionally
defined macros because multiple platforms provide the same feature but with
different spellings.

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

PR: https://git.openjdk.org/jdk/pull/12507