Closed Bug 1146979 Opened 10 years ago Closed 10 years ago

Cloning of variables in self-hosted code loses property attributes

Categories

(Core :: JavaScript Engine, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla39
Tracking Status
firefox39 --- fixed

People

(Reporter: bzbarsky, Assigned: bzbarsky)

References

Details

Attachments

(1 file)

Comment on attachment 8582492 [details] [diff] [review] When cloning objects in self-hosting preserve the property attributes of the properties (or at least the readonly/configurable attributes) Review of attachment 8582492 [details] [diff] [review]: ----------------------------------------------------------------- Thank you for fixing this. r=me with the comments addressed. ::: js/src/vm/SelfHosting.cpp @@ +1245,5 @@ > > + // Since all atoms used by self hosting are marked as permanent, any attempt > + // to look up a non-permanent atom will fail. We should only see such atoms > + // when code is looking for properties on the self hosted global which > + // aren't present. SpiderMonkey uses 80 cols for comments, so please revert the reformatting here. @@ +1294,5 @@ > + if (!ids.append(shapes[i]->propid())) > + return false; > + // XXXbz if this is an accessor, we're going to turn it into a > + // value; is that ok? If we can't assert that it's not an accessor, > + // then we can't just use shape->attributes(). This TODO should go. And I think shape->isAccessorShape() should be usable to assert against cloning accessors. (Which we might want to eventually do, but not right now.)
Attachment #8582492 - Flags: review?(till) → review+
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: