Bug 150496 - [META] Align JS Built-ins handling between WebCore and JavaScriptCore
Summary: [META] Align JS Built-ins handling between WebCore and JavaScriptCore
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on: 150482 150333 150539
Blocks:
  Show dependency treegraph
 
Reported: 2015-10-23 02:19 PDT by youenn fablet
Modified: 2015-10-24 16:52 PDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description youenn fablet 2015-10-23 02:19:16 PDT
Currently WebCore JS built-ins and JSC built-ins handling are quite different.
We should try to align the models.
Comment 1 youenn fablet 2015-10-23 02:29:00 PDT
In addition to 150491, here is a list of features that might be nice to have:

1. Move code from XXBuiltinsWrapper.h into XXBuiltins.h
WebCore-specific at first.
The wrapper classes would be useful to remove boilerplate code in JSGlobalObject.

2. Add support for @optional (JSC and WebCore)
Add conditional compilation support.
This is already useful for WebCore.
It might be as well for JSC in the future.

3. Add support for @internals
Add a way to distinguish between files containing JS built-ins used as internal functions from JS built-ins and files containing files directly tied to JS constructor or prototypes.

Useful for WebCore.
Might also be for JSC.
Maybe move from @internals to @interface if clearer

4. Add auto-generation of WebCoreJSBuiltins.h
This is a more or less a replacement to JSC BuiltinExecutables.
It handles conditional compilation.

   - Could be used as a replacement of JSC BuiltinExecutables
5. Add auto-generation of WebCoreJSBuiltinsInternals.h
Would also be useful for JSC to simplify JSGlobalObject code

6. Add auto-generation of WebCoreJSBuiltins.cpp
This is not really need for CMake-based builds once conditional compilation is integrated directly into each .h/.cpp file.
This might still be useful for make-based builds
Comment 2 youenn fablet 2015-10-23 02:39:22 PDT
Ah, I hit the button too quickly, here is a slighly improved description.

In addition to bug 150491 (moving from single file JSCBuiltins to separate files) and bug 150333 (adding @assert JS built-ins support in debug builds), here is a potential list of features/tasks that might be nice to have:

1. Move code from XXBuiltinsWrapper.h into XXBuiltins.h
WebCore-specific at first.
The wrapper classes would be useful to remove boilerplate code in JSGlobalObject.

2. Add support for @optional (JSC and WebCore)
Add conditional compilation support.
This is already useful for WebCore.
It might be as well for JSC in the future.

3. Add support for @internals
Add a way to distinguish between files containing JS built-ins used as internal functions from JS built-ins and files containing files directly tied to JS constructor or prototypes.

Generate wrapper classes accordingly.

This is definitely useful for WebCore.
It might also be for JSC.
Not sure whether @internals is a good name.

4. Add auto-generation of WebCoreJSBuiltins.h
This is a more or less a replacement to JSC BuiltinExecutables, with the additional benefit to handle conditional compilation.

5. Add auto-generation of WebCoreJSBuiltinsInternals.h
This is more or less a replacement of boiler-plate code in JSGlobalObject

6. Add auto-generation of WebCoreJSBuiltins.cpp
This is not really need for CMake-based builds once conditional compilation is integrated directly into each .h/.cpp file.
This might still be useful for make-based builds though.