Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(47)

Issue 3538005: Cleanup of the parser. (Closed)

Created:
10 years, 2 months ago by Kevin Millikin (Chromium)
Modified:
9 years, 7 months ago
Reviewers:
Lasse Reichstein
CC:
v8-dev
Visibility:
Public.

Description

Cleanup of the parser. The lazy parsing functions took a host of arguments that can all be derived from the SharedFunctionInfo, and the SharedFunctionInfo is always available when parsing lazily. Change the interface to take a single CompilationInfo or SharedFunctionInfo argument. Also remove a flag in the parser that was always false when it was read. Committed: http://code.google.com/p/v8/source/detail?r=5561

Patch Set 1 #

Total comments: 3
Unified diffs Side-by-side diffs Delta from patch set Stats (+25 lines, -68 lines) Patch
M src/compiler.cc View 2 chunks +5 lines, -13 lines 2 comments Download
M src/parser.h View 1 chunk +2 lines, -14 lines 1 comment Download
M src/parser.cc View 9 chunks +18 lines, -41 lines 0 comments Download

Messages

Total messages: 3 (0 generated)
Kevin Millikin (Chromium)
10 years, 2 months ago (2010-09-30 08:53:46 UTC) #1
Lasse Reichstein
LGTM http://codereview.chromium.org/3538005/diff/1/2 File src/compiler.cc (right): http://codereview.chromium.org/3538005/diff/1/2#newcode409 src/compiler.cc:409: Handle<String>(String::cast(shared->name())), Not your code, but how do we ...
10 years, 2 months ago (2010-09-30 09:11:41 UTC) #2
Kevin Millikin (Chromium)
10 years, 2 months ago (2010-09-30 09:39:48 UTC) #3
http://codereview.chromium.org/3538005/diff/1/2
File src/compiler.cc (right):

http://codereview.chromium.org/3538005/diff/1/2#newcode409
src/compiler.cc:409: Handle<String>(String::cast(shared->name())),
On 2010/09/30 09:11:41, Lasse Reichstein wrote:
> Not your code, but how do we know that shared->name() isn't undefined?
> Could there be another function to call than shared->name() for the case where
> the result might be a non-string, so that ->name() always returns a String?

I actually think name should *be* a string so that name() always returns a
string.

JS is untyped, but there's no reason that our internal data structures
(SharedFunctionInfo, FunctionTemplateInfo, etc) should be.

As far as I know, name is either a non-empty string or undefined.  That seems
like too much cuteness.  It ought to work to represent the absence of a name by
an empty string.

Powered by Google App Engine
This is Rietveld 408576698