forked from mirrors/gecko-dev
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:
parent
62462c3646
commit
2f44950a55
1 changed files with 5 additions and 1 deletions
|
|
@ -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) &
|
||||
|
|
|
|||
Loading…
Reference in a new issue