// Error message difference between fullcode and ignition_staging. Repro:

__v_0 = Symbol();
__v_2 = {};
__v_3 = new Proxy({}, __v_2);
__v_2.get = function() {};
(function () {
  if ( __v_0 < __v_3) ;
})();

// Output:
# Compared x64,fullcode with x64,ignition_staging
#
# Flags of x64,fullcode:
--abort_on_stack_overflow --expose-gc --allow-natives-syntax --invoke-weak-callbacks --omit-quit --es-staging --random-seed 1234 --nocrankshaft --turbo-filter=~ --validate-asm
# Flags of x64,ignition_staging:
--abort_on_stack_overflow --expose-gc --allow-natives-syntax --invoke-weak-callbacks --omit-quit --es-staging --random-seed 1234 --ignition-staging --validate-asm
#
# Difference:
- /usr/local/google/home/machenbach/v8/v8/repro.js:6: TypeError: Cannot convert object to primitive value
+ /usr/local/google/home/machenbach/v8/v8/repro.js:6: TypeError: Cannot convert a Symbol value to a number
#
### Start of configuration x64,fullcode:
/usr/local/google/home/machenbach/v8/v8/repro.js:6: TypeError: Cannot convert object to primitive value
  if ( __v_0 < __v_3) ;
             ^



### End of configuration x64,fullcode
#
### Start of configuration x64,ignition_staging:
/usr/local/google/home/machenbach/v8/v8/repro.js:6: TypeError: Cannot convert a Symbol value to a number
  if ( __v_0 < __v_3) ;
             ^



### End of configuration x64,ignition_staging

This is actually not just about the error message, but there is an observable difference in the evaluation of a relational comparison. In Ignition we perform an immediate ToNumber on the LHS before even performing a ToPrimitive on the RHS. This is different to the description in "7.2.12 Abstract Relational Comparison" in the spec and can be observed with the following snippet where Ignition does not trigger the proxy trap:

var lhs = Symbol();
var rhs = new Proxy({}, { get: function(a,b) { print("RHS proxy:", b) } });
(function () {
  if (lhs < rhs);
})();

ClusterFuzz has detected this issue as fixed in range 43348:43349.

Detailed report: https://cluster-fuzz.appspot.com/testcase?key=5476500758593536

Fuzzer: foozzie_js_mutation
Job Type: foozzie_ignition_staging
Platform Id: linux

Crash Type: V8 correctness failure
Crash Address: 
Crash State:
  configs: x64,fullcode:x64,ignition_staging
  sources: 9df
  
Sanitizer: address (ASAN)

Regressed: V8: 42370:42371
Fixed: V8: 43348:43349

Reproducer Testcase: https://cluster-fuzz.appspot.com/download/AMIfv96FwdT9tNETxfjF1Mg6m7ewXxiuoMpi10oik9L7UFWoetvwXXOtc_kpVvIZNbzVpjTcb5e3xuSIMMWCwjop1i0ZINCln9RITO9qB00alWpoeITpLK4H2VzUvH1qPMo26XwMV_pqG7moYzvqWdtJFFTFT9t9pyaTV5Cp8cmSHW6nzIFA47IV6JFpqufM4NqMfInsDcC0NDPf3pyZhmOWCdHtB0Gd5q5AtzvtQ3_FVupvP-GXPhZCLwVRa3VDDyIPvtcWjE3IIIHStH_vAlykEQCsfbtRCHxQOrRQzLLs0iLAKTGQCOqcYActvaKwvR8cUozBSmvnlfpSJnCXD0cCUH20yHUoILjTURoO2Dgl90i4Q6spkkQ?testcase_id=5476500758593536


See https://dev.chromium.org/Home/chromium-security/bugs/reproducing-clusterfuzz-bugs for more information.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.

ClusterFuzz testcase 5476500758593536 is verified as fixed, so closing issue.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.

Nah, pretty sure this is still a thing. The repro in comment #2 still works. Reopening!

Yea, sorry, the change of harness default values might wrongly close a bunch of the old fullcode vs. ignition bugs.

We have made a bunch of changes on ClusterFuzz side, so resetting ClusterFuzz-Wrong label.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

@Ignition folks: Could you retriage/repro this issue according to comments 2 and 6?

Sorry this one slipped my radar. 

Based on comment #2, this requires us to perform a ToPrimitive on the rhs before doing ToNumber on the lhs. This is implemented in CodeStubAssembler::RelationalComparison() which has the following comment:

// Convert the {rhs} to a Number; we don't need to perform
// dedicated ToPrimitive(rhs, hint Number) operation, as the
// ToNumber(rhs) will by itself already invoke ToPrimitive with
// a Number hint.

Assigning to Tobias who originally wrote CodeStubAssembler::RelationalComparison and the above comment, PTAL thanks.

I just moved it to this file.
It was written in: https://codereview.chromium.org/1759133002

Yes, that's wrong order. Should be trivial to fix.

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/08aec7d721dc461e4f46803298f8efed38534c17

commit 08aec7d721dc461e4f46803298f8efed38534c17
Author: Benedikt Meurer <bmeurer@chromium.org>
Date: Fri Sep 21 10:53:06 2018

[es2015] Fix ToPrimitive conversions in relational comparisons.

The order in which ToNumber(left) and ToPrimitive(right,hint Number)
is called when performing an abstract relational comparison is
observable, and we need to make sure to trigger the conversions in
the correct order.

Bug:  chromium:687063 
Change-Id: Idc9edb99643c4cf1774b89dcdc319ed5dc7cdc8a
Reviewed-on: https://chromium-review.googlesource.com/1236557
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56125}
[modify] https://crrev.com/08aec7d721dc461e4f46803298f8efed38534c17/src/code-stub-assembler.cc
[add] https://crrev.com/08aec7d721dc461e4f46803298f8efed38534c17/test/mjsunit/regress/regress-crbug-687063.js

Woot! Thanks for fixing this!

Yea, yet another long standing issue gone! Does this need backmerging?

Nah, this has been around for more than a year, I don't think there is an urgent need to merge this back.