Add int64_t support to embind using bigint support#13889
Merged
kripken merged 10 commits intoemscripten-core:mainfrom May 5, 2021
Merged
Add int64_t support to embind using bigint support#13889kripken merged 10 commits intoemscripten-core:mainfrom
kripken merged 10 commits intoemscripten-core:mainfrom
Conversation
|
Thank you for submitting a pull request! If this is your first PR, make sure to add yourself to AUTHORS. |
kripken
reviewed
Apr 14, 2021
Member
kripken
left a comment
There was a problem hiding this comment.
Nice work, thanks @cuberoot ! I think this is correct.
Please add testing for this, I think otherwise it looks good.
@RReverser maybe you want to take a look too?
RReverser
approved these changes
Apr 14, 2021
Collaborator
RReverser
left a comment
There was a problem hiding this comment.
Looks good to me, thanks!
* add range check and numeric conversions to toWireType implementation for int64_t and uint64_t * add basic test for emscripten::val and 64-bit bigints * fix indentation issue
…mscripten into cuberoot/embind-int64
cuberoot
commented
Apr 15, 2021
|
|
||
| var isUnsignedType = (name.indexOf('u') != -1); | ||
|
|
||
| // maxRange comes through as -1 for uint64_t (see issue 13902). Work around that temporarily |
cuberoot
commented
Apr 15, 2021
Contributor
Author
|
I added more intelligence to the I will add more tests for binding function calls tomorrow. |
kripken
reviewed
Apr 19, 2021
- Fix issue with `val::as<int64_t>()` not working - Add more tests for `val` and embind with `int64_t` and `uint64_t` - Fix failing tests using suggestion from Kripken
cuberoot
commented
Apr 20, 2021
kripken
reviewed
Apr 28, 2021
| } w[2]; | ||
| double d; | ||
| int64_t i; | ||
| uint64_t u; |
Member
There was a problem hiding this comment.
do we need both signed and unsigned? i'd hope only unsigned is enough, as with unsigned u above for 32-bit values.
Contributor
Author
There was a problem hiding this comment.
@kripken You are correct, the int64_t member was redundant.
As per suggestion by @kripken in PR
RReverser
added a commit
to RReverser/emscripten
that referenced
this pull request
Jun 16, 2025
This is the next step in refactorings I started back in emscripten-core#20383 to merge all Embind generic method callers into a single mechanism. I never got around to landing this PR because I kept trying to split it into even smaller changes / steps, never found a good way to do so due to how entangled they were, got frustrated and left it alone. However, aside from being a nice-to-have optimisation or cleanup refactoring, it's also an easy way to deal with issues like emscripten-core#24547 which makes it a bit more pressing. Without this PR, we'd have to duplicate the `emval_as`+`emval_as_int64`+`emval_as_uint64` fix from emscripten-core#13889 for `emval_call` and `emval_call_method` as well, but after this PR everything goes through the same centralised implementation where we can deal with all Embind types in a consistent manner. There are some more things that I'd like to clean up here (including some of the complexity added by this very own PR), but in order to try and keep review scope smaller, I'm going to submit them separately. Fixes emscripten-core#24547.
RReverser
added a commit
to RReverser/emscripten
that referenced
this pull request
Jun 16, 2025
This is the next step in refactorings I started back in emscripten-core#20383 to merge all Embind generic method callers into a single mechanism. I never got around to landing this PR because I kept trying to split it into even smaller changes / steps, never found a good way to do so due to how entangled they were, got frustrated and left it alone. However, aside from being a nice-to-have optimisation or cleanup refactoring, it's also an easy way to deal with issues like emscripten-core#24547 which makes it a bit more pressing. Without this PR, we'd have to duplicate the `emval_as`+`emval_as_int64`+`emval_as_uint64` fix from emscripten-core#13889 for `emval_call` and `emval_call_method` as well, but after this PR everything goes through the same centralised implementation where we can deal with all Embind types in a consistent manner. There are some more things that I'd like to clean up here (including some of the complexity added by this very own PR), but in order to try and keep review scope smaller, I'm going to submit them separately. Fixes emscripten-core#24547.
RReverser
added a commit
to RReverser/emscripten
that referenced
this pull request
Jun 17, 2025
This is the next step in refactorings I started back in emscripten-core#20383 to merge all Embind generic method callers into a single mechanism. I never got around to landing this PR because I kept trying to split it into even smaller changes / steps, never found a good way to do so due to how entangled they were, got frustrated and left it alone. However, aside from being a nice-to-have optimisation or cleanup refactoring, it's also an easy way to deal with issues like emscripten-core#24547 which makes it a bit more pressing. Without this PR, we'd have to duplicate the `emval_as`+`emval_as_int64`+`emval_as_uint64` fix from emscripten-core#13889 for `emval_call` and `emval_call_method` as well, but after this PR everything goes through the same centralised implementation where we can deal with all Embind types in a consistent manner. There are some more things that I'd like to clean up here (including some of the complexity added by this very own PR), but in order to try and keep review scope smaller, I'm going to submit them separately. Fixes emscripten-core#24547.
RReverser
added a commit
to RReverser/emscripten
that referenced
this pull request
Jun 17, 2025
This is the next step in refactorings I started back in emscripten-core#20383 to merge all Embind generic method callers into a single mechanism. I never got around to landing this PR because I kept trying to split it into even smaller changes / steps, never found a good way to do so due to how entangled they were, got frustrated and left it alone. However, aside from being a nice-to-have optimisation or cleanup refactoring, it's also an easy way to deal with issues like emscripten-core#24547 which makes it a bit more pressing. Without this PR, we'd have to duplicate the `emval_as`+`emval_as_int64`+`emval_as_uint64` fix from emscripten-core#13889 for `emval_call` and `emval_call_method` as well, but after this PR everything goes through the same centralised implementation where we can deal with all Embind types in a consistent manner. There are some more things that I'd like to clean up here (including some of the complexity added by this very own PR), but in order to try and keep review scope smaller, I'm going to submit them separately. Fixes emscripten-core#24547.
RReverser
added a commit
to RReverser/emscripten
that referenced
this pull request
Jun 17, 2025
This is the next step in refactorings I started back in emscripten-core#20383 to merge all Embind generic method callers into a single mechanism. I never got around to landing this PR because I kept trying to split it into even smaller changes / steps, never found a good way to do so due to how entangled they were, got frustrated and left it alone. However, aside from being a nice-to-have optimisation or cleanup refactoring, it's also an easy way to deal with issues like emscripten-core#24547 which makes it a bit more pressing. Without this PR, we'd have to duplicate the `emval_as`+`emval_as_int64`+`emval_as_uint64` fix from emscripten-core#13889 for `emval_call` and `emval_call_method` as well, but after this PR everything goes through the same centralised implementation where we can deal with all Embind types in a consistent manner. There are some more things that I'd like to clean up here (including some of the complexity added by this very own PR), but in order to try and keep review scope smaller, I'm going to submit them separately. Fixes emscripten-core#24547.
sbc100
pushed a commit
that referenced
this pull request
Jun 17, 2025
This is the next step in refactorings I started back in #20383 to merge all Embind generic method callers into a single mechanism. I never got around to landing this PR because I kept trying to split it into even smaller changes / steps, never found a good way to do so due to how entangled they were, got frustrated and left it alone. However, aside from being a nice-to-have optimisation or cleanup refactoring, it's also an easy way to deal with issues like #24547 which makes it a bit more pressing. Without this PR, we'd have to duplicate the `emval_as`+`emval_as_int64`+`emval_as_uint64` fix from #13889 for `emval_call` and `emval_call_method` as well, but after this PR everything goes through the same centralised implementation where we can deal with all Embind types in a consistent manner. There are some more things that I'd like to clean up here (including some of the complexity added by this very own PR), but in order to try and keep review scope smaller, I'm going to submit them separately. Fixes #24547.
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
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 PR adds int64_t and uint64_t support to embind when the
-s WASM_BIGINTflag is used (see issue 11726).Emscripten has support for handling
int64_tanduint64_tas JS bigint values, but embind does not know anything about those values.This PR is incomplete. I need to add tests and work out how to add guards so that this change does not cause issues when the
-s WASM_BIGINTis not used.