[Webkit-unassigned] [Bug 34019] New: custom-written parser

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=34019

           Summary: custom-written parser
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: All
        OS/Version: All
            Status: UNCONFIRMED
          Severity: Enhancement
          Priority: P2
         Component: JavaScriptCore
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: zherczeg at webkit.org


A bug entry for a custom written JavaScript parser.
FAQ:
  - Why?
    I felt I could write a faster, specialized parser than bison
  - When the work has started?
    Start of January 2010 (3 weeks ago)
  - Main components?
    - grammar : parsing and generating nodes
    - syntax checker : just parsing (used for checking function bodies to find
the terminator '}')
  - Can grammar and syntax checker be merged? It would help maintaining the
code.
    Possible. I was thinking about that when actually started to separate the
grammar from the syntax checker. However, there are some key
    differences between them (like syntax checker should check nested function
bodies). And syntax checker has a much simpler (and faster)
    code. When you open a simple page (like www.google.com), you also get a
huge JS with many functions. Most of them are never executed
    (browser specific for a different browser), but parsed (syntax checked). I
would not like to give up the speed advantage, and the
    code of the grammar is ugly anyway :(
  - Advantages compared to bison?
    Speed. According to my measurement the grammar is 3 and the syntax checker
is 4 times faster than bison.
  - Disadvantages?
    Readability. Although the code in grammar.y is ugly, it is repetative, and
easy to understand.
  - Focus of the work?
    Compatibility with the existing bison parser (and the standard as well).
Especially to detect parser errors in the same way.
  - But you skip possible optimizations in this way...
    I know. But it is only a first step on a long road. When this parser is
tested and goes mainline, we could think about improving it.
    Actually there is a lot of room for such improvements. But not for now.
  - Testing?
    See dump-AST.patch . You can dump the AST, and compare the old and new
ones. Now 127 fail on javascriptcore tests.
    Missing features: object literal, switch, arguments feature (no idea)
  - Supported build systems?
    Qt now. But easy for others, since you only have to add
JavaScriptCore/parser/Grammar.cpp, .h, SyntaxChecker.cpp, .h, GrammarConsts.h
  - Any help?
    See the comments in GrammarConsts.h
  - Anything else?
    See LEGACY comments in the code. They could be improved soon, but break the
AST compatibility. Anyway, we should do something
    with the divot points, since every node use them in a different way. For
now, the compatibility is the first priority, but later
    we should define general rules for them, and all node should follow these
rules.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.