BigInt-related API fixes and non-breaking changes #285
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.
BigInt-related API fixes and (for now, only) non-breaking changes.
input conversions for BigInt:
all integer types (8, 16, 32, 64) now accept bigint and number
64-bit integer types ([u]long, [u]int64, gtype) now convert the value to BigInt and then call
[U]Int64Value()
(the other integer types still convert to Number first, which means IIRC that if an out-of-range BigInt is passed, they'll get converted to trash rather than the low bits, as the user would expect. but it's better for performance and user can just
& 0xFFFFFFFFn
)GType consistency (these are breaking, but very little used so I think a fix like this is justified):
GValueToV8
now convertsGType
to BigInt to be consistentGType
s only support conversion from BigInt nowI've also annotated the places that should be changed to completely support BigInt, but would be a breaking change.
other non-BigInt related fixes:
CanConvertV8ToGValue