Still relevant parts of the original commit message:
Unify paren handling in Parser and PreParser.
It is only needed in (Pre)Parser::ParseExpressionOrLabelledStatement for not
recognizing parenthesized identifiers as labels and in
(Pre)Parser::ParseSourceElements for not recognizing a parenthesized string as
directive prologue.
Parser Expressions don't keep track of whether they're parenthesized, so
PreParser Expressions shouldn't either.
BUG=3126
LOG=N
R=ulan@chromium.org
Review URL: https://codereview.chromium.org/148323011
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19153 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
It is only needed in (Pre)Parser::ParseExpressionOrLabelledStatement for not
recognizing parenthesized identifiers as labels and in
(Pre)Parser::ParseSourceElements for not recognizing a parenthesized string as
directive prologue.
Parser Expressions don't keep track of whether they're parenthesized, so
PreParser Expressions shouldn't either.
In addition, add helper funcs for checking if an Expression is identifier or a
given identifier. (PreParser Expressions can do this.)
BUG=3126
LOG=N
R=ulan@chromium.org
Review URL: https://codereview.chromium.org/150103004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19140 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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
We need a way to assert that for a given source code snippet, an error *is*
produced or *is not* produced. Otherwise we might accidentally create new
errors or start accepting code which was previously not accepted. Just checking
that Parser and PreParser produce the same result doesn't cut it.
BUG=3126
LOG=N
R=ulan@chromium.org
Review URL: https://codereview.chromium.org/154243005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19107 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is what I think is a better solution to the "external strings in
old pointer space" problem. Basically, it is an issue because GC scans
all fields of objects in old pointer space and if the cached address
of the backing store is unaligned, it looks like a heap object, boom.
The solution here is to use short external strings when we externalize
a string in old pointer space, and when the address is unaligned.
Short external strings don't cache the address, so GC has no issues.
BUG=268686
LOG=Y
R=dcarney@chromium.org
Review URL: https://codereview.chromium.org/146183006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19093 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
In addition:
- Fix: PreParser used to report an unexpected token one token too late when
ParsePrimaryExpression failed.
- Unified identifier handling (PreParser::GetIdentifier is now like Parser::GetIdentifier).
- Fix: PreParser used to produce "unexpected_token YIELD" errors when Parser
produced "unexpected_token_identifier"; fixed PreParser to match Parser.
BUG=3126
LOG=N
R=ulan@chromium.org
Review URL: https://codereview.chromium.org/151103006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19082 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This contains the following fixes:
- We had strict_reserved_word and unexpected_strict_reserved, which one to use
was totally mixed in Parser and PreParser. Removed strict_reserved_word.
- When we saw a strict future reserved word when expecting something completely
different (such as "(" in "function foo interface"), Parser reports unexpected
identifier, whereas PreParser used to report unexpected strict reserved
word. Fixed PreParser to report unexpected identifier too.
- Unified parser and preparser error locations when the name of a function is a
strict reserved word. Now both point to the name.
BUG=3126
LOG=N
R=ulan@chromium.org
Review URL: https://codereview.chromium.org/149253010
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19067 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
BUG=v8:2943
LOG=Y
TEST=Unit tests for "real life" use cases, edge cases, various types of normalization.
==========================
This is identical to the previous CL
https://codereview.chromium.org/40133004/
with two differences:
* Added a dummy implementation of String.prototype.normalize to be used when v8 is compiled without intl support
* Rebased the the test files for webkit. That was the only reason for the previous failure (and revert).
Thank you,
Mihai
R=svenpanne@chromium.org
Review URL: https://codereview.chromium.org/68133016
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18972 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The webkit/function-apply-aliased.js test fails on simulators (both MIPS
and ARM) as the printed output does not match to the expected. The
failing test forces a stack overflow exception and the ToString()
operation of the exception object fails because of an other stack
overflow and returns an empty string.
The problem is that on hardware a common JS and C stack is used so the
stack overflow can be caught in C functions also while on simulator
separated JS and C stacks are used.
This patch adds a "sim" condition to test .status files to skip tests
only on simulator.
LOG=N
BUG=v8:3124
R=jkummerow@chromium.org, plind44@gmail.com
Review URL: https://codereview.chromium.org/139233005
Patch from Balazs Kilvady <kilvadyb@homejinni.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18959 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
version is passing all the existing test + a bunch of new tests
(packaged in the change list, too).
The patch extends the SlotRef object to describe captured and duplicated
objects. Since the SlotRefs are not independent of each other anymore,
there is a new SlotRefValueBuilder class that stores the SlotRefs and
later materializes the objects from the SlotRefs.
Note that unlike the previous implementation of SlotRefs, we now build
the SlotRef entries for the entire frame, not just the particular
function. This is because duplicate objects might refer to previous
captured objects (that might live inside other inlined function's part
of the frame).
We also need to store the materialized objects between other potential
invocations of the same arguments object so that we materialize each
captured object at most once. The materialized objects of frames live
in the new MaterielizedObjectStore object (contained in Isolate),
indexed by the frame's FP address. Each argument materialization (and
deoptimization) tries to lookup its captured objects in the store before
building new ones. Deoptimization also removes the materialized objects
from the store. We also schedule a lazy deopt to be sure that we always
get rid of the materialized objects and that the optmized function
adopts the materialized objects (instead of happily computing with its
captured representations).
Concerns:
- Is the FP address the right key for a frame? (Note that deoptimizer's
representation of frame is different from the argument object
materializer's one - it is not easy to find common ground.)
- Performance is suboptimal in several places, but a quick local run of
benchmarks does not seem to show a perf hit. Examples of possible
improvements: smarter generation of SlotRefs (build other functions'
SlotRefs only for captured objects and only if necessary), smarter
lookup of stored materialized objects.
- Ideally, we would like to share the code for argument materialization
with deoptimizer's materializer. However, the supporting data structures
(mainly the frame descriptor) are quite different in each case, so it
looks more like a separate project.
Thanks for any feedback.
R=danno@chromium.org, mstarzinger@chromium.org
LOG=N
BUG=
Committed: https://code.google.com/p/v8/source/detail?r=18918
Review URL: https://codereview.chromium.org/103243005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18936 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
mostly to make sure that it is going in the right direction. The current
version is passing all the existing test + a bunch of new tests
(packaged in the change list, too).
The patch extends the SlotRef object to describe captured and duplicated
objects. Since the SlotRefs are not independent of each other anymore,
there is a new SlotRefValueBuilder class that stores the SlotRefs and
later materializes the objects from the SlotRefs.
Note that unlike the previous implementation of SlotRefs, we now build
the SlotRef entries for the entire frame, not just the particular
function. This is because duplicate objects might refer to previous
captured objects (that might live inside other inlined function's part
of the frame).
We also need to store the materialized objects between other potential
invocations of the same arguments object so that we materialize each
captured object at most once. The materialized objects of frames live
in the new MaterielizedObjectStore object (contained in Isolate),
indexed by the frame's FP address. Each argument materialization (and
deoptimization) tries to lookup its captured objects in the store before
building new ones. Deoptimization also removes the materialized objects
from the store. We also schedule a lazy deopt to be sure that we always
get rid of the materialized objects and that the optmized function
adopts the materialized objects (instead of happily computing with its
captured representations).
Concerns:
- Is there a simpler/more correct way to store the already-materialized
objects? (At the moment there is a custom root reference to JSArray
containing frames' FixedArrays with their captured objects.)
- Is the FP address the right key for a frame? (Note that deoptimizer's
representation of frame is different from the argument object
materializer's one - it is not easy to find common ground.)
- Performance is suboptimal in several places, but a quick local run of
benchmarks does not seem to show a perf hit. Examples of possible
improvements: smarter generation of SlotRefs (build other functions'
SlotRefs only for captured objects and only if necessary), smarter
lookup of stored materialized objects.
- Ideally, we would like to share the code for argument materialization
with deoptimizer's materializer. However, the supporting data structures
(mainly the frame descriptor) are quite different in each case, so it
looks more like a separate project.
Thanks for any feedback.
R=mstarzinger@chromium.org, danno@chromium.org
LOG=N
BUG=
Review URL: https://codereview.chromium.org/103243005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18918 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Throwing under FLAG_debug_code confuses the rest of our infrastructure
which expects a safe point at the site of call into the runtime
for throw. We were doing that to make a clusterfuzz test happy, but
the better solution is to assert/abort under debug_code, and prevent
clusterfuzz from fuzzing on internal APIs that crash on incorrect
values.
We'll need to alter the fuzzer to turn off fuzzing for:
string-natives.js
lithium/SeqStringSetChar.js
regress/regress-seqstrsetchar-ex3.js
regress/regress-seqstrsetchar-ex1.js
regress/regress-crbug-320922.js
So as to prevent the fuzzer from running
%_OneByteSeqStringSetChar() and
%_TwoByteSeqStringSetChar().
BUG=
R=hpayer@chromium.org, machenbach@chromium.org
Review URL: https://codereview.chromium.org/139903005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18878 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This reverts:
r18749 "Reland (and fix) "Add hydrogen support for ArrayPop, and remove the handwritten call stubs."",
r18790 "Remove ArrayPush from the custom call generators, and instead call directly to the handler in crankshaft.", and
r18798 "MIPS: Remove ArrayPush from the custom call generators, and instead call directly to the handler in crankshaft."
For causing crashes on Canary.
BUG=chromium:337686
LOG=N
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/146003006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18805 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
We removed an HDiv by hand which was still used by an HChange. The
solution is letting dead code removal do the cleanup.
Removed a fragile "optimization" (looking through an HChange), too,
this obviously never triggered and is hard to get right given all our
global invariants and state/type/... changes.
The repro is a bit tricky, because you need inlining to make our
representations and types disagree in this case.
LOG=y
BUG=334708
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/143903016
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18737 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
