Commit 45a2d9c5 authored by Jakob Kummerow's avatar Jakob Kummerow Committed by Commit Bot

Fix "x is not iterable" error message consistency

Since 94ce16b7, when loading an iterator from null or undefined, we
generate the error message "x is not iterable" instead of the unwieldy
"Cannot read property 'Symbol(Symbol.iterator)' of undefined". However
Runtime::GetObjectProperty, which is used as slow path by LoadICs, did
not check for this case, leading to different messages being generated
depending on IC state.

Bug: chromium:823130
Change-Id: Ie98500b97efef401aac9880b9af47d58c3c2825d
Reviewed-on: https://chromium-review.googlesource.com/1042951Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52974}
parent 2489567d
......@@ -21,6 +21,9 @@ MaybeHandle<Object> Runtime::GetObjectProperty(Isolate* isolate,
Handle<Object> key,
bool* is_found_out) {
if (object->IsNullOrUndefined(isolate)) {
if (*key == isolate->heap()->iterator_symbol()) {
return Runtime::ThrowIteratorError(isolate, object);
}
THROW_NEW_ERROR(
isolate,
NewTypeError(MessageTemplate::kNonObjectPropertyLoad, key, object),
......
// Copyright 2018 the V8 project authors. All rights reserved.
// Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file.
// Flags: --expose-gc
var __v_1 = new Array();
var __v_2 = 0x30;
var __v_4 = "abc";
var __v_3 = "def";
function __f_2(b) {
[...b];
}
__f_2([1]);
__f_2([3.3]);
__f_2([{}]);
var vars = [__v_1, __v_2, __v_3, __v_4];
for (var j = 0; j < vars.length && j < 7; j++) {
for (var k = j; k < vars.length && k < 7 + j; k++) {
var v1 = vars[j];
var e1, e2;
try {
__f_2(v1);
__f_2();
} catch (e) {
e1 = "" + e;
}
gc();
try {
__f_2(v1);
__f_2();
} catch (e) {
e2 = "" + e;
}
assertEquals(e1, e2);
}
}
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment