Automatically generate __sig properties for JS symbols (part 1)
#18985
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
sbc100
force-pushed
the
gen_sig_info
branch
2 times, most recently
from
9cc746f to
0e7635b
Compare
sbc100
changed the title
__sig properties for JS library symbols__sig properties for JS library symbols
sbc100
added a commit
that referenced
this pull request
Mar 17, 2023
The emscripten_request_animation_frame sig was just wrong since that Web API returns WebIDL `long` defined as i32. For emscripten_webgl_get_parameter_i64v use GLint64 rather than `long long` to me more explicit. For `emscripten_websocket_get_buffered_amount` using `size_t` since we already include `stdint.h` in this header anyway. I found all of these while working on #18985 which detectes the use of `long`, `size_t` or pointers and marks tham a `p` in their `__sig` attribute.
sbc100
added a commit
that referenced
this pull request
Mar 20, 2023
…root. NFC I noticed while working `gen_sig_info.py` in #18985 that is was simpler to just keep a copy of the generated file checked into source control. We can use a unit test check that its up-to-date on each commit. In fact we already had a unit test that was doing this and keeping a copy of the expected output in the test directory. This simplifies the emcc linker code since we can always assume the presence of the struct info file.
sbc100
added a commit
that referenced
this pull request
Mar 20, 2023
…root. NFC I noticed while working `gen_sig_info.py` in #18985 that is was simpler to just keep a copy of the generated file checked into source control. We can use a unit test check that its up-to-date on each commit. In fact we already had a unit test that was doing this and keeping a copy of the expected output in the test directory. This simplifies the emcc linker code since we can always assume the presence of the struct info file. Also allows us to remove the `varies=False` special case in cache logic.
sbc100
added a commit
that referenced
this pull request
Mar 20, 2023
…root. NFC I noticed while working `gen_sig_info.py` in #18985 that is was simpler to just keep a copy of the generated file checked into source control. We can use a unit test check that its up-to-date on each commit. In fact we already had a unit test that was doing this and keeping a copy of the expected output in the test directory. This simplifies the emcc linker code since we can always assume the presence of the struct info file. Also allows us to remove the `varies=False` special case in cache logic.
sbc100
added a commit
that referenced
this pull request
Mar 20, 2023
The emscripten_request_animation_frame sig was just wrong since that Web API returns WebIDL `long` defined as i32. For emscripten_webgl_get_parameter_i64v use GLint64 rather than `long long` to me more explicit. For `emscripten_websocket_get_buffered_amount` using `size_t` since we already include `stdint.h` in this header anyway. I found all of these while working on #18985 which detectes the use of `long`, `size_t` or pointers and marks tham a `p` in their `__sig` attribute.
sbc100
added a commit
that referenced
this pull request
Mar 20, 2023
The emscripten_request_animation_frame sig was just wrong since that Web API returns WebIDL `long` defined as i32. For emscripten_webgl_get_parameter_i64v use GLint64 rather than `long long` to me more explicit. For `emscripten_websocket_get_buffered_amount` using `size_t` since we already include `stdint.h` in this header anyway. I found all of these while working on #18985 which detectes the use of `long`, `size_t` or pointers and marks tham a `p` in their `__sig` attribute.
sbc100
added a commit
that referenced
this pull request
Mar 20, 2023
…root. NFC I noticed while working `gen_sig_info.py` in #18985 that is was simpler to just keep a copy of the generated file checked into source control. We can use a unit test check that its up-to-date on each commit. In fact we already had a unit test that was doing this and keeping a copy of the expected output in the test directory. This simplifies the emcc linker code since we can always assume the presence of the struct info file. Also allows us to remove the `varies=False` special case in cache logic.
sbc100
added a commit
that referenced
this pull request
Mar 20, 2023
…root. NFC I noticed while working `gen_sig_info.py` in #18985 that is was simpler to just keep a copy of the generated file checked into source control. We can use a unit test check that its up-to-date on each commit. In fact we already had a unit test that was doing this and keeping a copy of the expected output in the test directory. This simplifies the emcc linker code since we can always assume the presence of the struct info file. Also allows us to remove the `varies=False` special case in cache logic.
sbc100
added a commit
that referenced
this pull request
Mar 20, 2023
…root. NFC I noticed while working `gen_sig_info.py` in #18985 that is was simpler to just keep a copy of the generated file checked into source control. We can use a unit test check that its up-to-date on each commit. In fact we already had a unit test that was doing this and keeping a copy of the expected output in the test directory. This simplifies the emcc linker code since we can always assume the presence of the struct info file. Also allows us to remove the `varies=False` special case in cache logic.
sbc100
added a commit
that referenced
this pull request
Mar 20, 2023
…root. NFC I noticed while working `gen_sig_info.py` in #18985 that is was simpler to just keep a copy of the generated file checked into source control. We can use a unit test check that its up-to-date on each commit. In fact we already had a unit test that was doing this and keeping a copy of the expected output in the test directory. This simplifies the emcc linker code since we can always assume the presence of the struct info file. Also allows us to remove the `varies=False` special case in cache logic.
sbc100
added a commit
that referenced
this pull request
Mar 20, 2023
…root. NFC I noticed while working `gen_sig_info.py` in #18985 that is was simpler to just keep a copy of the generated file checked into source control. We can use a unit test check that its up-to-date on each commit. In fact we already had a unit test that was doing this and keeping a copy of the expected output in the test directory. This simplifies the emcc linker code since we can always assume the presence of the struct info file. Also allows us to remove the `varies=False` special case in cache logic.
sbc100
added a commit
that referenced
this pull request
Mar 20, 2023
…root. NFC I noticed while working `gen_sig_info.py` in #18985 that is was simpler to just keep a copy of the generated file checked into source control. We can use a unit test check that its up-to-date on each commit. In fact we already had a unit test that was doing this and keeping a copy of the expected output in the test directory. This simplifies the emcc linker code since we can always assume the presence of the struct info file. Also allows us to remove the `varies=False` special case in cache logic.
sbc100
added a commit
that referenced
this pull request
Mar 21, 2023
…root. NFC (#19013) I noticed while working `gen_sig_info.py` in #18985 that is was simpler to just keep a copy of the generated file checked into source control. We can use a unit test check that its up-to-date on each commit. In fact we already had a unit test that was doing this and keeping a copy of the expected output in the test directory. This simplifies the emcc linker code since we can always assume the presence of the struct info file. Also allows us to remove the `varies=False` special case in cache logic.
sbc100
force-pushed
the
gen_sig_info
branch
3 times, most recently
from
c658883 to
6d7ea2f
Compare
sbc100
force-pushed
the
gen_sig_info
branch
3 times, most recently
from
ddaefc5 to
ceb74e7
Compare
sbc100
changed the title
__sig properties for JS library symbols__sig properties for JS symbols (part 1)
Collaborator
Author
|
Gentle ping, if either of you get time today I'd love to land this so I can upload the followups. |
Collaborator
Author
|
Followup is here BTW: #19028 |
kripken
reviewed
Mar 21, 2023
kripken
reviewed
Mar 21, 2023
kripken
approved these changes
Mar 22, 2023
Member
kripken
left a comment
kripken
left a comment
There was a problem hiding this comment.
Looks good enough to land and iterate to me.
This primary change here is the creation of `emscripten_internal.h` which is an internal-only header that contains that declaration of internal JS function that are not already declared in other files. The reason for this is to ensure that all JS library functions that are callable form native code have a valid declaration, at least internally, so that gen_sig_info.py can extract that signature from a compiled wasm file. This change add the scripte for generating `library_sigs.js` but doesn't actually start using it, or erase the correpsonding hand-created `__sig` entries. That is will be part of a followup
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This primary change here is the creation of
emscripten_internal.hwhich is an internal-only header that contains that declaration of
internal JS function that are not already declared in other files.
The reason for this is to ensure that all JS library functions that are
callable form native code have a valid declaration, at least internally,
so that gen_sig_info.py can extract that signature from a compiled wasm
file.
This change add the scripte for generating
library_sigs.jsbut doesn'tactually start using it, or erase the correpsonding hand-created
__sigentries. That is will be part of a followup