[META] Align JS Built-ins handling between WebCore and JavaScriptCore

• Component: Tools / Tests
• Status: NEW ---

[youenn fablet]

Currently WebCore JS built-ins and JSC built-ins handling are quite different.
We should try to align the models.

[youenn fablet]

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

[youenn fablet]

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.