Bug 1265271 - Mark JSClass as a MOZ_STATIC_CLASS r=jandem

Turns out it's legal to have these at the end as well:

> Type Attributes
>
> An attribute specifier list may appear as part of a struct, union or enum
> specifier. It may go either immediately after the struct, union or enum
> keyword, or after the closing brace. The former syntax is preferred. Where
> attribute specifiers follow the closing brace, they are considered to relate
> to the structure, union or enumerated type defined, not to any enclosing
> declaration the type specifier appears in, and the type defined is not
> complete until after the attribute specifiers.

from https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html

Differential Revision: https://phabricator.services.mozilla.com/D208519
This commit is contained in:
Matthew Gaudet 2024-04-25 14:41:59 +00:00
parent 62462c3646
commit 2f44950a55

View file

@ -606,6 +606,10 @@ struct MOZ_STATIC_CLASS JSClassOps {
static constexpr const JSClassOps* JS_NULL_CLASS_OPS = nullptr;
// Note: This is a MOZ_STATIC_CLASS, as having a non-static JSClass
// can lead to bizarre behaviour, however the annotation
// is at the bottom to handle some incompatibility with GCC
// annotation processing.
struct alignas(js::gc::JSClassAlignBytes) JSClass {
const char* name;
uint32_t flags;
@ -763,7 +767,7 @@ struct alignas(js::gc::JSClassAlignBytes) JSClass {
JSFunToStringOp getOpsFunToString() const {
return oOps ? oOps->funToString : nullptr;
}
};
} MOZ_STATIC_CLASS;
static constexpr uint32_t JSCLASS_RESERVED_SLOTS(const JSClass* clasp) {
return (clasp->flags >> JSCLASS_RESERVED_SLOTS_SHIFT) &