Closed Bug 683218 Opened 13 years ago Closed 9 years ago

can we remove __noSuchMethod__, use proxies instead?

Categories

(Core :: JavaScript Engine, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla44
Tracking Status
firefox44 --- fixed
firefox45 --- fixed

People

(Reporter: luke, Assigned: jandem)

References

(Blocks 1 open bug)

Details

(Keywords: addon-compat, dev-doc-complete, site-compat)

Attachments

(2 files)

Proxies cannot 100% replace __noSuchMethod__, but they can come pretty close.  Can we remove this less-general non-standard precursor and replace its uses with being-standardized future goodness?  There are 3 uses in mozilla that need to be fixed.  If there are no immediate objections, I'll also post to the newsgroup.
This is definitely a web-compatibility issue as well. We will break sites with this, so we will need a slow careful approach here. We should start with a warning to the console when the feature is used and public noise about our intent to remove it.
Oh, I didn't realize it was content-visible.  Well, we have a tool for that!  We are already using telemetry to measure __iterator__ and E4X, so I guess a good first step is to add telemetry for __noSuchMethod__.
That would be very useful. Lets do that.
As the original requestor of __noSuchMethod__ [https://bugzilla.mozilla.org/show_bug.cgi?id=196097] (and as a heavy user of such), I'd be curious as to why removal of this is important.

There have been many fellow JSers who, like myself, have been wondering (i.e. struggling) how to use proxies to emulate this behavior with the seamlessness that __noSuchMethod__ provides, although that discussion is beyond the scope of the specific task here.

Cheers,

- Bill
Bill
I would be glad to help you figure out your issues with Proxies, so you don't need to rely  __noSuchMethod__.
(In reply to William J. Edney from comment #4)
> I'd be curious as to why removal of this is important.

Just the general goal of removing non-standard features.  The simpler the engine, the easier it is to maintain, optimize, etc.  No individual piece breaks the bank but they add up to something large so it is important for the long-term health of the codebase to regularly ask this question of all non-standard features.

> There have been many fellow JSers who, like myself, have been wondering
> (i.e. struggling) how to use proxies to emulate this behavior with the
> seamlessness that __noSuchMethod__ provides, although that discussion is
> beyond the scope of the specific task here.

This seems like a perfect place to discuss; please do take Tom up on his offer.
(In reply to Tom Schuster (evilpie) from comment #5)
> Bill
> I would be glad to help you figure out your issues with Proxies, so you
> don't need to rely  __noSuchMethod__.

If interested, you may read this lengthy thread https://mail.mozilla.org/pipermail/es-discuss/2010-October/011912.html where we discussed the issue of simulating __noSuchMethod__ with proxies (and only-call functions vs. first-class functions problem in general).

On of the issues is when simulating with proxies, you either need to restrict property names which are planed to be "virtual (non-existing) functions" or to make _all_ non-existing properties as functions returning the activator of noSuchMehtod handler. So what I was arguing is that proxies' `get` handler needs isCall flag that we could determine whether it's a call or simple reading of a property. Anyway, this discussion is really out of scope here, please read the thread I mentioned above if interested.

And about __noSuchMethod__, I agree that it will be an old-code-breaker (I used it in writing Thunderbird modules; pretty sure it's used also widely in programming for SpiderMonkey).

Dmitry.
Guys -

Thanks for the pointers.

I want to like Proxies - I really do. I'm just struggling to see how I would do the following using a Proxy:

Object.prototype.__noSuchMethod__ = function (...) {... generic handler...}

without having control over object creation. It seems that I'm always seeing 'Proxy.create()' in all of these examples.

In my example above, I can then do:

myArr = [];
myArr.methodArraysDontUnderstand();

and trap it.

Maybe I'm not the sharpest tool in the shed, but I just don't see a way do this with Proxies (and, in fact, it seems to me that that may be by design...).

I, along with a whole bunch of others, would love to have an ECMA standardized way to do the above and, if Proxies are going to provide a way to do that, then hey, I'm all for it :-).

Thoughts?

Cheers,

- Bill
Telemetry is based on sampling. It won't tell you about certain critical clients (e.g., the Bloomberg Terminal, with its 15MLOC of JS). Be careful not to rely only on telemetry.

We need to standardize proxies a bit more, the V8 impl has landed. This bug should not have a question as its summary. Really, we want two bugs, as for sharp variables (see bug 486643): one to deprecate, another that blocks on it to obsolete. We do not fix both bugs in a given "release" -- we need a decent interval between.

The deprecation bug is where the library users will need that uses proxies to approximate __noSuchMethod__ goes, as an attachment.

/be
(In reply to Brendan Eich [:brendan] from comment #9)
> Be careful not to rely only on telemetry.

I was responding to gal's "__noSuchMethod__ in content" comment.

(In reply to Brendan Eich [:brendan] from comment #9)
> This bug should not have a question as its summary.

It was posted as a genuine question (where, like bug 599585, the answer may very well be "no").  In a sense, the bug is "we don't know the answer or have a plan".

> Really, we want two bugs, as for
> sharp variables (see bug 486643): one to deprecate, another that blocks on
> it to obsolete. We do not fix both bugs in a given "release" -- we need a
> decent interval between.

I see the "quotes"; do you mean FF release?  That seems to be what bug 486643 is talking about.  I ask because its clear that many embeddings (I believe Bloomberg included) are pretty far behind tip (pre-fatvals).  Thus, a meaningful deprecation interval would have to be ~2 years, otherwise, we're just warning FF-based web content, which telemetry should detect.
So it's been awhile since I posted my question re: proxies, et. al. I was hopeful that someone had figured out how to do what I'm looking for (Tom, any suggestions?) as detailed in comment 8.

Since this is a use case for us, I could take it over to the ecmascript mailing list as I still have reservations about using a bug report to discuss architectural issues and use cases.

Thoughts anyone?

Cheers,

- Bill
Sorry, but i can't think of a solution for that because Object.prototype is not configurable. But maybe you could solve this problem somewhere else? 

I think it would be a very good idea to describe in depth for what and how you use this feature and post it to es-discuss.
(In reply to William J. Edney from comment #11)
> So it's been awhile since I posted my question re: proxies, et. al. I was
> hopeful that someone had figured out how to do what I'm looking for (Tom,
> any suggestions?) as detailed in comment 8.

Apparently, you would like to replace Object.prototype by a proxy. As you and Tom noted, by design, this is not possible. Proxies can only be new objects. Array.prototype cannot be replaced either.

One idea would be to combine a proxy with the proto operator (http://wiki.ecmascript.org/doku.php?id=harmony:proto_operator) (syntax not definitive): 
-----
var p = Proxy.create(Array.prototype, handler); // define your trapping behavior in the handler

myArr = p <| [];
myArr.methodArraysDontUnderstand(); // methodArraysDontUnderstand trapped at the p level
// p can look up in its own prototype to know whether the 
// method is there or not and behave as you want if not.
-----

The current spec and implementation of proxies do not allow to do that. Long story short, to access the prototype of a proxy, you need to access the proxy within a handler. This issue has been reported and discussed over and over on es-discuss and led to http://wiki.ecmascript.org/doku.php?id=strawman:handler_access_to_proxy
I'm hopeful that an agreement will be reach at the November TC39 meeting.

I think that unless the proxy design is reconsidered to allow turning objects into proxies, this is the best that can be done.
From https://mail.mozilla.org/pipermail/es-discuss/2011-December/018834.html :

Object.prototype.__noSuchMethod__ = function(name, args) {
  throw new TypeError(name + " is not a function");
};
MethodSink = Proxy({}, {
  has: function(target, name) { return true; },
  get: function(target, name, receiver) {
    if (name in Object.prototype) {
      return Object.prototype[name];
    }
    return function() {
      var args = Array.prototype.slice.call(arguments);
      return receiver.__noSuchMethod__(name, args);
    }
  }
});

Cc'ing Tom.

Bill, can you comment on this approach? It's going to be standard in ES6 as far as I know, which means by our usual rules __noSuchMethod__ will be deprecated (fair warning and decent interval), then removed.

/be
Brendan -

I see no problems with this approach - it looks fine to me.

However, in order for this to be a *complete* replacement for how we use __noSuchMethod__ (and, indeed it was the original impetus for asking for the feature), the other part of the work must be done to allow 'Object.prototype' to become or behave like a proxy.

What we're looking for here is a generic backstop for the whole environment - a true replacement for doesNotUnderstand (Smalltalk) / method_missing (Ruby) / etc.

Therefore, unless the problem as described in comments 12 and 13 has been resolved, removal of the current __noSuchMethod__ approach is indeed subtractive for us.

Cheers,

- Bill
My post on the MethodSink made mention of the ability to set Object.prototype.__proto__ to a MethodSink, thus capturing all missing property accesses in the entire environment. The potential issue with this is that you capture all missing property accesses, not just all missing method calls. This may break code that does property-detection, since |obj.missingProp| would no longer return undefined (which is falsy), but a function instead (which is truthy).

I don't know your use case, but if you are OK with trapping all property accesses, this could work out. It would also trap calls to missing accessor properties, which you can't trap with __noSuchMethod__.
Tom -

If indeed the ability to set Object.prototype.__proto__ to a MethodSink makes it into ES6, then this would be a complete replacement for us.

We are OK with trapping all property accesses.

Thanks guys!

Cheers,

- Bill
TC39 came to an agreement to standardize __proto__ at their last meeting: https://mail.mozilla.org/pipermail/es-discuss/2012-May/022834.html (the whole discussion is about how to do it).
Proposal on the wiki: http://wiki.ecmascript.org/doku.php?id=strawman:magic_proto_property
Assignee: general → nobody
We should start by warning whenever this feature is used.
And by adding a telemetry probe for it. CCing cpeterson.
I think if I were implementing a Smalltalk VM in JS today and really had to support doesNotUnderstand:, I wouldn't use proxies either. I would make Smalltalk objects (that is, all objects that need to cope with doesNotUnderstand:) all inherit from a single shared prototype, and when compiling Smalltalk to JS, I would decorate that shared prototype with a stub for every message name ever sent.

That is, on encountering `x ifTrue: [ y ]`, I would set
  SmalltalkObject.prototype["ifTrue:"] = doesNotUnderstandHandler("ifTrue:");

This way, a method call from compiled code could not possibly miss, unless the target was not a Smalltalk object in the first place.

Pros: This would be fast, it's fairly simple, it uses no special magic, and it would work portably across all JS implementations.

Cons: It slightly complicates the implementation of perform: and respondsTo:. It could not support defining a doesNotUnderstand: method on Smalltalk objects that are represented as JS builtins or primitives.
Blocks: 1103158
Depends on: 1130123
Depends on: 1139794
Depends on: 1140324
Depends on: 1140334
Depends on: 1140342
Depends on: 1140361
Chris added telemetry for this in bug 1130123, and I've posted patches to convert all in-tree uses.

Once these are in we can deprecate __noSuchMethod__ and start warning whenever it's used.
Assignee: nobody → jdemooij
Status: NEW → ASSIGNED
Jorge, the sooner addons stop using __noSuchMethod__ the better. Can we start showing a deprecation warning or something?

__noSuchMethod__ is non-standard, likely buggy, and we want to remove support for it from SpiderMonkey.
Flags: needinfo?(jorge)
Keywords: addon-compat
Depends on: 1140428
Yes, I think showing a deprecation warning in the console is the way to go. I also see some SDK code in add-ons using it, so I'm ccing Erik Vold.
Flags: needinfo?(jorge)
Depends on: 1142337
So at this point there's not much we can do: I added a console warning, posted to dev-platform and the docs say it's deprecated.

Unfortunately the Telemetry results for 39 aren't reliable atm due to bug 1069869 :( Hopefully that'll be fixed soon and we can keep an eye on it then.
According to Telemetry data, __noSuchMethod__ is still popular. I suspect most of this is from add-ons like NoScript that use __noSuchMethod__ in their surrogate scripts.

I hope we can disable __noSuchMethod__ support in Nightly 43 next month, that's 4 releases and 5 months after the deprecation warning. If this breaks any major websites or add-ons we can pref it back on if needed, but it'd at least tell us who depends on this.
I'm trying to get rid of __noSuchMethod__ wherever possible, especially in NoScript's surrogates, by replacing it with a Proxy-based approach.

However, is there any way to "patch" a living DOM object which foreign code already references (such as, in my use case, a plugin content <embed> or <object> element) in order to intercept calls to its expando or plugin-provided methods?
(In reply to Giorgio Maone from comment #27)
> However, is there any way to "patch" a living DOM object which foreign code
> already references (such as, in my use case, a plugin content <embed> or
> <object> element) in order to intercept calls to its expando or
> plugin-provided methods?

Nope.  Objects' behavior is intrinsic to them, and you can't change it after the object's been created, not without the object itself cooperating with you in some way.
(In reply to Jeff Walden [:Waldo] (remove +bmo to email) from comment #28)
> (In reply to Giorgio Maone from comment #27)
> > However, is there any way to "patch" a living DOM object which foreign code
> > already references (such as, in my use case, a plugin content <embed> or
> > <object> element) in order to intercept calls to its expando or
> > plugin-provided methods?
> 
> Nope.  Objects' behavior is intrinsic to them, and you can't change it after
> the object's been created, not without the object itself cooperating with
> you in some way.

So we've got a case against the removal of __noSuchMethod__, which would imply a net loss of functionality, or for providing a decent replacement first for privileged code at least.
(In reply to Giorgio Maone from comment #29)
> So we've got a case against the removal of __noSuchMethod__, which would
> imply a net loss of functionality, or for providing a decent replacement
> first for privileged code at least.

Some ideas are just bad ideas, unfortunately.  We *do* remove bad ideas without full replacements: __count__, __parent__, sharp variables, and E4X, just off the top of my head.

__noSuchMethod__ is also a bad idea.  Given how JS works, I don't see how a replacement for privileged code -- "first" or even "only" -- could ever work.  Either it's there all the time, and imposes costs on everything, or it's never there.  No other engine supports it, and I'll argue strongly with any engine that considers implementing it in anything close to its current form.
(In reply to Jeff Walden [:Waldo] (remove +bmo to email) from comment #30)

> __noSuchMethod__ is also a bad idea.  Given how JS works, I don't see how a
> replacement for privileged code -- "first" or even "only" -- could ever
> work.

Understood. 
Now, I'm not familiar enough with the JS engine(s) internals to say whether the following is an even more stupid idea, but would it be possible providing privileged code with an API to permanently reassign all the references to a certain object (or better its "internal pointer", if such a term makes any sense) so that they point to a different object (in my use case, a Proxy wrapping the original object)? This way I could emulate my __noSuchMethod__ compelling usage without any runtime penalty, I guess.
(In reply to Giorgio Maone from comment #31)
> Now, I'm not familiar enough with the JS engine(s) internals to say whether
> the following is an even more stupid idea, but would it be possible
> providing privileged code with an API to permanently reassign all the
> references to a certain object (or better its "internal pointer", if such a
> term makes any sense) so that they point to a different object (in my use
> case, a Proxy wrapping the original object)?

Not really.  There's no such internal concept -- practically all (possibly even all) components of an object, at the bit level in C++, can be shared among multiple objects.  Object address is the last line of "defense" in distinguishing objects, and we'd have to check such a mapping ubiquitously to get any sort of thing correct (and even then I'm sure we wouldn't).
(In reply to Giorgio Maone from comment #31)
> Now, I'm not familiar enough with the JS engine(s) internals to say whether
> the following is an even more stupid idea, but would it be possible
> providing privileged code with an API to permanently reassign all the
> references to a certain object (or better its "internal pointer", if such a
> term makes any sense) so that they point to a different object (in my use
> case, a Proxy wrapping the original object)? This way I could emulate my
> __noSuchMethod__ compelling usage without any runtime penalty, I guess.

Giorgio, such a primitive was discussed at one point in TC39. See <http://wiki.ecmascript.org/doku.php?id=strawman:direct_proxies#proxy.starttrapping_a.k.a._proxy.attach>. It died for a number of reasons. As Jeff said: you don't want to mess with object identities and addresses. Security patterns and compiler optimizations often depend on object identity being constant.

That said, there is one way to start intercepting method calls on a non-proxy object: insert a proxy in its inheritance chain, by updating __proto__. If an object o inherits from a proxy, then a property access o.foo, where o does not implement "foo", will delegate to the proxy and trigger its traps.
(In reply to Tom Van Cutsem from comment #33)
> That said, there is one way to start intercepting method calls on a
> non-proxy object: insert a proxy in its inheritance chain, by updating
> __proto__. If an object o inherits from a proxy, then a property access
> o.foo, where o does not implement "foo", will delegate to the proxy and
> trigger its traps.

About which, you should know that I'm currently working on making the entire prototype chain of global objects immutable, for security reasons, so I'm hoping this awful hack won't work longer run.  Not to mention, if you do this, you will essentially poison performance for everything in the world, not just your own code.  Frankly, the costs are bad enough I'd consider making it a conformance requirement for AMO approval (so long as we have such a thing) that you *don't* do this, because of it slowing everything else down so much.
As the original requestor for this feature in Spidermonkey I now feel the need to jump in.

Back in 2003, when I asked brendan@mozilla.org (thanks Brendan!) to add this feature (https://bugzilla.mozilla.org/show_bug.cgi?id=196097), I was looking for a way to emulate a generic, catch-all trap feature that the following dynamic languages have all implemented:

Smalltalk - #doesNotUnderstand:
Objective-C - forward / forwardInvocation
Ruby - method_missing

To me, for JavaScript to be a modern, dynamic language, there needed to be a way to give an object a 'second chance' at handling an unknown property or method. And it had to be able to be dynamically installed onto objects that I had no control over the creation of (and, in fact, might already be created by the time I wanted to install the trap).

__noSuchMethod__ worked very well for the problems I was trying to solve and the design patterns I was trying to implement. Obviously, I wasn't the only one:

http://yehudakatz.com/2008/08/18/method_missing-in-javascript/

In fact, one could argue that frameworks like Rails would almost be impossible to implement without a facility like 'method_missing'.

__noSuchMethod__ worked so well, that my business partner and I wrote up an email to the ECMA committee 5 years later, proposing __noSuchMethod__ be formalized into the ECMA5 standard.

https://mail.mozilla.org/pipermail/es-discuss/2008-August/006901.html

It was decided not to do that in favor of a 'future solution' - a solution which became known as Proxies (thanks Tom!)

This was all fine, but the early work on Proxies concerned me that I wouldn't be able to fully emulate __noSuchMethod__ - namely, the ability to dynamically install a Proxy into a prototype chain that either another JS library had constructed or that the host system had constructed (we install __noSuchMethod__ on Object.prototype).

At an ECMA committee meeting back in April of 2014, there was a discussion about assigning  prototypes to Proxies. According to the meeting notes, the discussion ended with this:


Mark Miller: Too late to draw the line about what prototypes can be assigned a Proxy.


The full link is here (search for the words "Setting Object.prototype to a Proxy?")

https://esdiscuss.org/notes/2014-04-08

Therefore, based on that, I came away assured that, indeed, __noSuchMethod__ would be able to be fully emulated with Proxies.

Given that I was not present at that meeting, I don't presume to speak for others. I've presumptively added Mark Miller to this bug (I apologize in advance Mark, but considering your comment above, you seem to be intimately familiar with the issues here).

Are those of us who want this feature aware of the performance implications? Of course - I would expect that all sorts of JavaScript engine optimizations will break when messing with prototype chains. We're willing to make a trade off here in order to get the functionality we desire.

It would be helpful if folks like brendan@mozilla.org, tomvc.be@gmail.com, erights@gmail.com or any others could chime in here. I am not a engine guy.

Thanks for listening.

Cheers,

- Bill
The issue here is about whether to limit prototype chains through proxies in order to preserve the es5 invariant that prototype chains are never cyclic at any one moment. The difficulty is that this constraint was clearly meaningful for es <= 5 because user code could never interleave with the prototype chain lookup.

With proxies, user computation can happen at every step, so it can form an effective cycle even if momentary cycles are prevented. Given that, IIRC, we decided to stop prohibiting cyclic prototype chains. It just enables another way of writing an infinite loop.
(In reply to Jeff Walden [:Waldo] (remove +bmo to email) from comment #34)
> About which, you should know that I'm currently working on making the entire
> prototype chain of global objects immutable, for security reasons, so I'm
> hoping this awful hack won't work longer run.  Not to mention, if you do
> this, you will essentially poison performance for everything in the world,
> not just your own code.  Frankly, the costs are bad enough I'd consider
> making it a conformance requirement for AMO approval (so long as we have
> such a thing) that you *don't* do this, because of it slowing everything
> else down so much.

Jeff, I think your comment only applies if one would want to emulate `__noSuchMethod__` *globally*, on every object, by inserting a proxy above the global object. I completely agree about the insane performance costs (not to mention the fact that it will completely break virtually all existing JS code as no property access would ever resolve to `undefined` anymore). My proposal was instead to mutate the prototype chain only for those objects that actually need the hook. For example, if only a single instance must be monitored, mutate its prototype. If all instances of a class need to be monitored, mutate the shared prototype of its instances. I would never recommend to mutate the prototype of the global object.

In reply to Bill: given that both proxies and prototype mutation are part of ES6, my recommended solution should still work. Jeff's comment does remind us that it's important to think carefully about how "high" up the proto chain you'd want to insert a proxy.

Another caveat is that objects that have been marked non-extensible, sealed or frozen can't have their prototype mutated, so you wouldn't be able to install an emulated noSuchMethod hook on such objects. The majority of JS objects remain, of course, fully extensible, so I suspect the insert-proxy-as-proto trick will be sufficient in most cases.
The Telemetry data looks much better now. NoSuchMethod used to be the most popular deprecated JS feature by far, but now it's about the same number as samples as expression closures. Still quite a lot, but way less than before.

This is probably from NoScript fixing their __noSuchMethod__ uses (thanks Giorgio, version 2.6.9.32 was released at the end of July and there's a clear drop in the number of noSuchMethod Telemetry samples around that time).

I want to disable NoSuchMethod on Nightly and see what happens. Next release cycle is two weeks away so we should probably wait for that though.
Attached patch PatchSplinter Review
This patch disables __noSuchMethod__ but adds a shell function to enable it, for the few tests that depend on it. Just to make sure we can turn this back on if really necessary.

I want to land this after the next merge.
Attachment #8660210 - Flags: review?(jorendorff)
(In reply to Jan de Mooij [:jandem] from comment #39)
> This patch disables __noSuchMethod__ but adds a shell function to enable it,
> for the few tests that depend on it. Just to make sure we can turn this back
> on if really necessary.
> 
> I want to land this after the next merge.

Any chance ES6 classes will be available outside nightlies after the next merge too? Our __noSuchMethod__ replacement uses them...
At this point I'm pretty sure let/const will not be ready to ship FF43, and that means we can't ship classes. (Changing let/const to ES6 standard behavior breaks too much code. We can't rush it.)
Attachment #8660210 - Flags: review?(jorendorff) → review+
Out of context, I saw:

> Changing let/const to ES6 standard behavior breaks too much code.

Curious: Is that strict code or only sloppy code? If the latter, is there any reason to delay std let/const in strict code?
It's all code.  Turns out lots of the JS code in the browser UI is a festering pile of^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^Hnot really ready for the standardized semantics in a bunch of ways.  And that code is a solid mix of strict/non-strict, perhaps with one predominating, but overwhelmingly so.
s/but over/but not over/
I am surprised there is a significant amount of strict code that uses let/const that is not compat with ES6 strict let/const behavior. What is the incompat prior strict let/const behavior that this code does rely on? Where does this prior behavior come from --- what implements it?  Can you point at some examples of code that relies on it?
Keywords: leave-open
The site compatibility doc: https://www.fxsitecompat.com/en-US/docs/2015/nosuchmethod-is-no-longer-supported/
Target Milestone: --- → mozilla44
Disabled __noSuchMethod__ has been on Nightly for almost 3 weeks now and I'm not aware of it breaking any add-ons or websites, so next cycle we can probably remove this \o/ This way we can pref it back on for 44 if really needed.
Attached patch Kill with fireSplinter Review
We disabled __noSuchMethod__ in Firefox 44, I think it's safe to remove it in 45.

 29 files changed, 49 insertions(+), 883 deletions(-)
Attachment #8680747 - Flags: review?(efaustbmo)
Comment on attachment 8680747 [details] [diff] [review]
Kill with fire

Review of attachment 8680747 [details] [diff] [review]:
-----------------------------------------------------------------

This makes me like giddy. You have no idea.

::: js/src/jit/BaselineIC.cpp
@@ +2240,5 @@
>  
>          AccType acctype = getterIsScripted ? ICGetElemNativeStub::ScriptedGetter
>                                             : ICGetElemNativeStub::NativeGetter;
>          ICGetElemNativeCompiler<T> compiler(cx, kind, monitorStub, obj, holder, key, acctype,
> +                                         needsAtomize, getter, script->pcToOffset(pc));

this indenture is preexisting but strange. Is there a reason it wasn't aligned with the cx above?
Attachment #8680747 - Flags: review?(efaustbmo) → review+
Keywords: leave-open
\o/
https://hg.mozilla.org/mozilla-central/rev/134b9a7003b3
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
No longer depends on: 1264612
You need to log in before you can comment on or make changes to this bug.