706795 - TI: Setter on Object.prototype is not called

Status: RESOLVED DUPLICATE of bug 706808

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following test produces different output with options "-m -a" vs. "-m -a -n" on mozilla-central revision ca140190529a:


var gTestcases = new Array();
function TestCase() {
  this.name = "foo";
  gTestcases[0] = this;
}
var cnName = 'name';
var cnNameSetter = function(newValue) {};
Object.prototype.__defineSetter__(cnName, cnNameSetter);
new TestCase();
print(uneval(gTestcases));


Output:
$ $JS -m -a min.js
[{}]
$JS -m -a -n min.js
[{name:"foo"}]

Comment 1

[Christian Holler (:decoder)]

Smaller testcase with standard ES5:

Object.defineProperty(Object.prototype, 'x', { set: function() { print("Hello world"); } });
function A() {
    this.x = 12;
}
new A();


With TI, the setter defined here is never called, without TI it is. Bug 706808 could be the same issue as it's also using defineProperty on Object.prototype.

Comment 3

[Brian Hackett [Laid off!]]

Attachment: patch

Two related problems when generating constraints to make sure these prototype setters actually get called.

- Types for the prototype's property were not necessarily being propagated from the prototype's own prototype, so if the setter was not on the direct prototype then it may not have been noticed while analyzing the 'new' properties of the script.

- Things were being done in the wrong order, so that even if the prototype setter was detected the property would still be marked as definitely held by the 'new' script objects (though further analysis would then stop).

Comment 4

[Brian Hackett [Laid off!]]

Comment on attachment 579118 [details] [diff] [review]
patch

Cancelling, bug 706808 exposed more semantic problems with this code so going to put a rolled up patch there.