... according to the spec ES#sec-%throwtypeerror%
Bug: v8:4034
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: Ia4f2d228397edf55447fe3e71402c8fc4589369a
Reviewed-on: https://chromium-review.googlesource.com/563214
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46498}
When an octal escape sequence is in a string in strict mode:
- Octal literals are not allowed in strict mode.
+ Octal escape sequences are not allowed in strict mode.
When an octal escape sequence is in a template string:
- Octal literals are not allowed in template strings.
+ Octal escape sequences are not allowed in template strings.
BUG=v8:4973
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel
Review-Url: https://codereview.chromium.org/2551633002
Cr-Commit-Position: refs/heads/master@{#41560}
See discussion in https://codereview.chromium.org/2156303002/#msg8
With the new --harmony-function-tostring behavior, these tests would
fail without this change. This change makes the tests pass regardless
of whether or not --harmony-function-tostring is used.
All of these changes are simply inserting a space after the "function"
keyword to match the current function toString behavior. When
--harmony-function-tostring is enabled, the toString behavior matches
the spacing used in the function declaration. With the declaration
matching the current formatting, the toString behavior becomes
unaffected by --harmony-function-tostring.
BUG=v8:4958
LOG=n
Review-Url: https://codereview.chromium.org/2161413002
Cr-Commit-Position: refs/heads/master@{#37959}
Duplicate parameters are banned both overall in strict mode and also
in arrow functions. Our error message for both cases blamed strict
mode, which is confusing. This patch fixes the message to point to
arrow functions as a possible source as well.
R=wingo, adamk
LOG=N
Review URL: https://codereview.chromium.org/1236863008
Cr-Commit-Position: refs/heads/master@{#29662}
Per TC39 Nov 2014 decision.
This patch also changes behavior for "legacy const": assignments to sloppy const in strict mode is now also a type error. This fixes v8:2243 and also brings us in compliance with other engines re assignment to function names (see updated webkit test), but might have bigger implications.
That change can easily be reverted by changing Variable::IsSignallingAssignmentToConst.
BUG=v8:3713,v8:2243
LOG=N
Review URL: https://codereview.chromium.org/749633002
Cr-Commit-Position: refs/heads/master@{#25516}
We used to have error messages which provide context, like "Variable name may
not be eval or arguments in strict mode", but for other illegal words we only
have non-context specific error messages like "Unexpected reserved word".
Providing the context makes the code unnecessarily complex, since every
individual place must remember to check for eval or arguments. This CL produces
a unified error message ("Unexpected eval or arguments in strict mode"), and puts
the error reporting to (Pre)Parser::ParseIdentifier.
Notes:
- The module feature is so experimental, that I decided to not allow "eval" or
"arguments" as module-related identifiers in the strict mode (even though this
check wasn't there before).
- Unfortunately, there were some inconsistencies, since it was the
responsibility of the caller of ParseIdentifier to check "eval" and "arguments"
and some places didn't have the check for no good reason. This CL is supposed to
keep backward compatibility and *not* introduce any new errors.
- ECMA allows "eval" and "arguments" as labels even in strict mode. (Syntax:
"LabelledStatement: Identifier : Statement", and no strict mode restrictions on
Identifier are listed.)
- Tests which compare error message strings will fail, and need to be updated.
BUG=3126
LOG=N
R=ulan@chromium.org
Review URL: https://codereview.chromium.org/152813005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19112 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The stand-alone test driver is changed a bit:
- Don't use the errorMessage list. It is used differently in the embedded driver. There it collects parser errors - instead of failure messages.
- Remove html links in description texts. Some test descriptions print a web reference.
The migrated tests fall into 3 categories:
1. Tests outside fast/js
2. Tests that print FAIL messages (and also expect those) - these tests should be examined later if they make sense at all
3. Tests with html links in the test description
R=jkummerow@chromium.org
Review URL: https://codereview.chromium.org/20280003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15889 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
