JSCLASS_CACHED_PROTO_WIDTH is in the js namespace

RESOLVED FIXED in Firefox 45

Status

()

Core
JavaScript Engine
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: leper, Assigned: leper)

Tracking

unspecified
mozilla46
Points:
---

Firefox Tracking Flags

(firefox45 fixed, firefox46 fixed, firefox-esr38 fixed)

Details

Attachments

(1 attachment)

(Assignee)

Description

2 years ago
Since b0eda4f5c21e users of JSCLASS_CACHED_PROTO_KEY (via JSCLASS_CACHED_PROTO_MASK) outside of the js namespace are broken.
(Assignee)

Comment 1

2 years ago
Created attachment 8703455 [details] [diff] [review]
Add the namespace to the macro usage

It would be nice to have this in a release of SpiderMonkey 38, not sure if I should add anything for that.
Attachment #8703455 - Flags: review?(jwalden+bmo)
Attachment #8703455 - Flags: review?(jwalden+bmo) → review+

Comment 2

2 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/7ecb29ab42b7
Comment on attachment 8703455 [details] [diff] [review]
Add the namespace to the macro usage

Approval Request Comment
[Feature/regressing bug #]: N/A

[User impact if declined]: Slightly more work for embedders to use the 38/45 branches.  (We expect to spin a fresh SpiderMonkey release from 45, hence the request there.  No releasing is planned for 39-44, hence no requests for beta or any other branches.)

[Describe test coverage new/current, TreeHerder]: N/A

[Risks and why]: Entirely risk-free.  A very, very obviously correct C++ change accounting for C++ scoping rules.  (Gecko doesn't need this because it's not a very *good* JSAPI user and cheats like crazy.)

[String/UUID change made/needed]: N/A
Attachment #8703455 - Flags: approval-mozilla-esr38?
Attachment #8703455 - Flags: approval-mozilla-aurora?

Comment 4

2 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/7ecb29ab42b7
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 years ago
status-firefox46: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla46
status-firefox45: --- → affected
status-firefox-esr38: --- → affected
Assignee: nobody → leper
Comment on attachment 8703455 [details] [diff] [review]
Add the namespace to the macro usage

Jeff, Why do you think we should take it in ESR? Thanks
Taking it in aurora.
Flags: needinfo?(jwalden+bmo)
Attachment #8703455 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+

Comment 6

2 years ago
bugherderuplift
https://hg.mozilla.org/releases/mozilla-aurora/rev/bfcf642c55e4
status-firefox45: affected → fixed
Sorry -- "We expect to spin a fresh SpiderMonkey release from 45, hence the request there" also applies to 38, the current stable version we support in advance of 45 going to release.  That is, right now people embedding stable SpiderMonkey should be embedding 38 -- so we want this fixed there for their sakes.
Flags: needinfo?(jwalden+bmo)
Just looking to see how we usually handle SpiderMonkey. From https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey, is the standalone SpiderMonkey something we build separately from 38esr?
Flags: needinfo?(jwalden+bmo)
Comment on attachment 8703455 [details] [diff] [review]
Add the namespace to the macro usage

If this makes your life easier, why not
Attachment #8703455 - Flags: approval-mozilla-esr38? → approval-mozilla-esr38+
https://hg.mozilla.org/releases/mozilla-esr38/rev/762d015e1854
status-firefox-esr38: affected → fixed
Standalone SpiderMonkey has a separate release process, yes.  But I believe it does use the ESR branch directly.
Flags: needinfo?(jwalden+bmo)
You need to log in before you can comment on or make changes to this bug.