Closed Bug 1265271 Opened 9 years ago Closed 1 years ago

Mark JSClass as a MOZ_STATIC_CLASS

Categories

(Core :: JavaScript Engine, task, P3)

task

Tracking

()

RESOLVED FIXED
127 Branch
Tracking Status
firefox48 --- wontfix
firefox127 --- fixed

People

(Reporter: n.nethercote, Assigned: mgaudet)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Whiteboard: btpp-fixlater)

Attachments

(1 file)

Currently all js::Class instances are static with the exception of XPCNativeScriptableShared, which contain heap-allocated js::Class instances. Having non-eternal js::Class instances can lead to subtle problems like bug 1132502, because it's very natural to assume that js::Class pointers belong to objects/shape/base-shapes are always safe to follow. bholley tells me that XPCNativeScriptableShared is headed for the chopping block anyway. Once it's removed, we should annotate js::Class so that only static instances are allowed. We have MOZ_NONHEAP_CLASS which disallows heap allocation but not stack allocation. Perhaps we should add a new annotation MOZ_STATIC_CLASS which disallows both heap and stack allocation.
Depends on: 1207321
Whiteboard: btpp-fixlater
See Also: → 1321374

XPCNativeScriptableShared is no more, and I think we have only static instances of js::Class now, so we might be able to do this now. Although I think this belongs in the JS engine component, as that's where the annotation will need to be added.

Component: XPConnect → JavaScript Engine

This seems to be mostly done. Compiling with JSClass marked MOZ_STATIC_CLASS works, so the annotation just needs to be added.

Summary: Remove all non-static js::Class instances → Mark JSClass as a MOZ_STATIC_CLASS
Severity: normal → S3
Blocks: sm-runtime
Severity: S3 → N/A
Type: defect → enhancement
Priority: -- → P3

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

Assignee: nobody → mgaudet
Status: NEW → ASSIGNED
Pushed by mgaudet@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/123aa66a2c6d Mark JSClass as a MOZ_STATIC_CLASS r=jandem
Status: ASSIGNED → RESOLVED
Closed: 1 years ago
Resolution: --- → FIXED
Target Milestone: --- → 127 Branch
Type: enhancement → task
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: