[Webkit-unassigned] [Bug 173242] New: New model for aggregate generation of WebIDL bindings

[bugzilla-daemon at webkit.org]

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

            Bug ID: 173242
           Summary: New model for aggregate generation of WebIDL bindings
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Bindings
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: sam at webkit.org
                CC: cdumez at apple.com

The bindings have been getting much better lately, but we are running into a wall, performance wise, due to the need to gather information about interfaces/dictionaries/enums other than the one currently being generated.

I would like to propose a new model, that should allow us to parse each IDL file at most once (or in a simplified form, at most twice). The basic idea is to formalize our current split processing (preprocess-idls.pl and generate-bindings.pl) into two phases, parsing and code generation, with a data structure, the 'type database' being used to bridge the gap between them.

- In the parsing phase, we parse each IDL file and build up a 'type database' (essentially a big map of all the IDL types and their characteristics, parent type, exposure and compatibility aliases, inheritable extended attributes, named/indexed getters/setters, serializers, etc.) by extracting relevent information. Then, we dump the parsed form to a file so it can be reconstructed quickly, without re-parsing, using Storable (this is the optional step, we can always just do a second parse for code generation). 

- In the code generation phase, we take as input, an IDL file (or it's parsed form mapped in from disk) and the 'type database'. As a rule, all code generation should be possible with only those two input. If additional information is needed, it should be extracted during the parsing phase, and added to the 'type database'.

(This leaves out partial interfaces and implements statements. We will probably want to do something like have them participate in the parsing phase just like any other IDL file, and then during code generation, we do a merge before the real generation has begun).

Thoughts?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170611/c1ecf3ae/attachment.html>