Revision: 19532
Author: [email protected]
Date: Mon Feb 24 17:48:09 2014 UTC
Log: Lazy preparsing vs. lazy parsing fix.
Preparsing is always maximally lazy (every function that can be lazy is
preparsed
lazily), but Parser has more complicated laziness logic.
If we're going to parse eagerly, and we have preparse data from lazy
preparsing,
we're gonna have a bad time. The symbol stream won't contain symbols inside
lazy
functions, and when the Parser parses them eagerly, it will consume symbols
from
the symbol stream, and everything will go wrong.
This bug was hidden because the symbol cache was not used for real (see
https://codereview.chromium.org/172753002/ ).
[email protected]
BUG=346207
LOG=Y
Review URL: https://codereview.chromium.org/177973002
http://code.google.com/p/v8/source/detail?r=19532
Modified:
/branches/bleeding_edge/src/compiler.cc
/branches/bleeding_edge/test/cctest/test-debug.cc
=======================================
--- /branches/bleeding_edge/src/compiler.cc Fri Feb 14 15:15:08 2014 UTC
+++ /branches/bleeding_edge/src/compiler.cc Mon Feb 24 17:48:09 2014 UTC
@@ -789,6 +789,13 @@
String::cast(script->source())->length() >
FLAG_min_preparse_length) &&
!DebuggerWantsEagerCompilation(info);
+ if (!parse_allow_lazy && info->pre_parse_data() != NULL) {
+ // We are going to parse eagerly, but we have preparse data produced
by lazy
+ // preparsing. We cannot use it, since it won't contain all the
symbols we
+ // need for eager parsing.
+ info->SetPreParseData(NULL);
+ }
+
Handle<SharedFunctionInfo> result;
{ VMState<COMPILER> state(info->isolate());
=======================================
--- /branches/bleeding_edge/test/cctest/test-debug.cc Fri Jan 31 16:52:17
2014 UTC
+++ /branches/bleeding_edge/test/cctest/test-debug.cc Mon Feb 24 17:48:09
2014 UTC
@@ -7698,6 +7698,41 @@
v8::Debug::SetLiveEditEnabled(false, env->GetIsolate());
CompileRun("%LiveEditCompareStrings('', '')");
}
+
+
+TEST(PrecompiledFunction) {
+ // Regression test for crbug.com/346207. If we have preparse data,
parsing the
+ // function in the presence of the debugger (and breakpoints) should
still
+ // succeed. The bug was that preparsing was done lazily and parsing was
done
+ // eagerly, so, the symbol streams didn't match.
+ DebugLocalContext env;
+ v8::HandleScope scope(env->GetIsolate());
+ env.ExposeDebug();
+ v8::Debug::SetDebugEventListener2(DebugBreakInlineListener);
+
+ v8::Local<v8::Function> break_here =
+ CompileFunction(&env, "function break_here(){}", "break_here");
+ SetBreakPoint(break_here, 0);
+
+ const char* source =
+ "var a = b = c = 1; \n"
+ "function this_is_lazy() { \n"
+ // This symbol won't appear in the preparse data.
+ " var a; \n"
+ "} \n"
+ "function bar() { \n"
+ " return \"bar\"; \n"
+ "}; \n"
+ "a = b = c = 2; \n"
+ "bar(); \n";
+ v8::Local<v8::Value> result = PreCompileCompileRun(source);
+ CHECK(result->IsString());
+ v8::String::Utf8Value utf8(result);
+ CHECK_EQ("bar", *utf8);
+
+ v8::Debug::SetDebugEventListener2(NULL);
+ CheckDebuggerUnloaded();
+}
#endif // ENABLE_DEBUGGER_SUPPORT
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
