799785 - IonMonkey: emitInstanceOf() does not error with non-object prototypes.

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Sean Stangl [:sstangl]]

Branching off Bug 798668 Comment 3, emitInstanceOf() does not contain the same path as fun_hasInstance() in which a primitive .prototype triggers an error.

> x = y = String.slice
> try {
>     print(((function () {
>         (x instanceof y)
>     }))())
> } catch (e) {}
> 
> Here's another testcase that when tested on 32-bit js shell on m-c changeset
> 70337fa2fe62, without --ion-eager shows no output (presumably a newline),
> but with --ion-eager shows:
> 
> undefined

Comment 1

[David Anderson [:dvander] - inactive, e-mail if emergency]

This reminds me of bug 787050 - I'd be happy to see this whole path get reimplemented. It's not really sound in IonMonkey to combine opcodes like this. I think Crankshaft generates a specialized IC, and JSC splits INSTANCEOF into multiple opcodes.

Comment 2

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

autoBisect shows this is probably related to the following changeset:

The first good revision is:
changeset:   114177:d3ed5864b6eb
user:        Nicolas B. Pierron
date:        Mon Nov 26 19:08:37 2012 -0800
summary:     Bug 814177 - Use a callVM for generic InstanceOf cases. r=dvander

Nicolas, is this a possible fix?

Comment 3

[Nicolas B. Pierron [:nbp]]

(In reply to Gary Kwong [:gkw] from comment #2)
> The first good revision is:
> changeset:   114177:d3ed5864b6eb
> user:        Nicolas B. Pierron
> date:        Mon Nov 26 19:08:37 2012 -0800
> summary:     Bug 814177 - Use a callVM for generic InstanceOf cases.
> r=dvander
> 
> Nicolas, is this a possible fix?

Yes, it is.  Even if this is not a duplicate, the fact that the impl was not identical has been fixed in this Bug as well as in Bug 814861.