Re-enable Parser::symbol_cache_ (after a long time!)

Re-enable Parser::symbol_cache_ (after a long time!)

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

Committed: https://code.google.com/p/v8/source/detail?r=19505

[marja, 2014-02-19 18:41:26]

ulan, ptal.

I'm still pretty o.O about this finding. How come nobody ever noticed?

[marja, 2014-02-19 18:48:08]

Oops wait, there is more. Apparently set_pre_parse_data tries to initialize the
symbol cache, but maybe this is not called in all relevant code paths or sth...
I need to debug more, pls don't review yet.

[marja, 2014-02-19 19:00:06]

Gotcha; set_pre_parse data does symbol_cache_.Initialize(data ?
data->symbol_count() : 0, zone()); but that doesn't help at all, since length()
will remain 0!

IOW, my analysis still holds, this just adds another layer to it.

[marja, 2014-02-20 09:17:05]

(this is ready for review now)

[ulan, 2014-02-20 11:03:41]

wow, lgtm!

[marja, 2014-02-20 11:35:44]

Committed patchset #2 manually as r19505 (presubmit successful).