Esp. get rid of PreCompile in tests, as it's going to be removed.
Notes:
- The new compilation API doesn't have a separate precompilation phase, so there
is no separate way to check for errors except checking the compilation
errors. Removed some tests which don't make sense any more.
- test-api/Regress31661 didn't make sense as a regression test even before the
compilation API changes, because Blink doesn't precompile this short scripts. So
detecting this kind of errors (see crbug.com/31661 for more information) cannot rely
on precompilation errors.
- test-parsing/PreParserStrictOctal has nothing to do with PreParser, and the comment
about "forcing preparsing" was just wrong.
- test-api/PreCompile was supposed to test that "pre-compilation (aka
preparsing) can be called without initializing the whole VM"; that's no longer
true, since there's no separate precompilation step in the new compile
API. There are other tests (test-parsing/DontRegressPreParserDataSizes) which
ensure that we produce cached data.
- Updated tests which test preparsing to use PreParser directly (not via the
preparsing API).
- In the new compilation API, the user doesn't need to deal with ScriptData
ever. It's only used internally, and needed in tests that test internal aspects
(e.g., modify the cached data before passing it back).
- Some tests which used to test preparse + parse now test first time parse +
second time parse, and had to be modified to ensure we don't hit the
compilation cache.
BUG=
R=ulan@chromium.org
Review URL: https://codereview.chromium.org/225743002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20511 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- Distinguish between context bound scripts (Script) and context unbound scripts
(UnboundScript).
- Add ScriptCompiler (which will later contain functions for async compilation).
This is a breaking change, in particular, Script::New no longer exists (it is
replaced by ScriptCompiler::CompileUnbound). Script::Compile remains as a
backwards-compatible shorthand for ScriptCompiler::Compile.
Passing CompilerOptions with produce_data_to_cache = true doesn't do anything
yet; the only way to generate the data to cache is the old preparsing API. (To
be fixed in the next version.)
This is a fixed version of https://codereview.chromium.org/186723005/
BUG=
R=dcarney@chromium.org
Review URL: https://codereview.chromium.org/199063003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19925 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- Distinguish between context bound scripts (Script) and context unbound scripts
(UnboundScript).
- Add ScriptCompiler (which will later contain functions for async compilation).
This is a breaking change, in particular, Script::New no longer exists (it is
replaced by ScriptCompiler::CompileUnbound). Script::Compile remains as a
backwards-compatible shorthand for ScriptCompiler::Compile.
Passing CompilerOptions with produce_data_to_cache = true doesn't do anything
yet; the only way to generate the data to cache is the old preparsing API. (To
be fixed in the next version.)
BUG=
R=dcarney@chromium.org
Review URL: https://codereview.chromium.org/186723005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19881 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The tests were using different kind of constructs for achieving the same
thing. This makes refactoring the compilation API more difficult than it should
be.
cctest.h already contained helpers for compiling and running scripts, but they
were not used consistently.
For example, all these were used for running scripts:
v8::Script::Compile(v8_str("foo"))->Run();
v8::Script::Compile(v8::String::NewFromUtf8(isolate, "foo))->Run();
CompileRun(v8_str("foo"));
CompileRun(v8::String::NewFromUtf8(some_way_to_get_isolate(), "foo"));
v8::Local<v8::Script> script = any_of_the_above; script->Run();
Most of the tests just want to run a script (which is in const char*) and don't
care about how the v8::String is constructed or passed to the compiler API. Using
the helpers makes the test more readable and reduces boilerplate code which is
unrelated to what the test is testing.
R=dcarney@chromium.org
BUG=
Review URL: https://codereview.chromium.org/190503002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19753 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The Parser never used the symbol stream produced by the PreParser for anything
useful, due to a bug introduced 3.5 years ago by
https://codereview.chromium.org/3356010/diff/7001/src/parser.cc.
The bug is that calling Initialize on symbol_cache_ doesn't change its
length. So the length remains 0, and the "if" in Parser::LookupSymbol is always
true, and Parser::LookupCachedSymbol is never called and symbol_cache_ never
filled.
This bug also masked a bug that the symbol stream produced by PreParser doesn't
match what Parser wants to consume. The repro case is the following:
var myo = {if: 4}; print(myo.if);
PreParser doesn't log a symbol for the first "if", but in the corresponding
place, Parser consumes one symbol from the symbol stream. Since the consumed
symbols were never really used, this mismatch went unnoticed.
This CL also fixes that bug.
BUG=
R=ulan@chromium.org
Review URL: https://codereview.chromium.org/172753002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19505 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Note that leaving out the Isolate parameter previously had a very special
meaning, namely "use the *default* Isolate", i.e. the one magically created at
program initialization time. All other API entries use the meaning "current
Isolate", which is different in a multi-threaded setting and confusing.
Temporarily disabled deprecations until Chrome is ready.
BUG=v8:2487
Review URL: https://codereview.chromium.org/11970009
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13419 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Thread class was receiving an isolate parameter by default.
This approact violates the assumption that only VM threads
can have an associated isolate, and can lead to troubles,
because accessing the same isolate from different threads
leads to race conditions.
This was found by investigating mysterious failures of the
CPU profiler layout test on Linux Chromium. As almost all
threads were associated with some isolate, the sampler was
trying to sample them.
As a side effect, we have also fixed the DebuggerAgent test.
Thanks to Vitaly for help in fixing isolates handling!
R=vitalyr@chromium.org
BUG=none
TEST=none
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8259 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
