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.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JsSymbol primitive #761
base: main
Are you sure you want to change the base?
JsSymbol primitive #761
Changes from 2 commits
a110490
53ad833
23a797c
cf740fd
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This method needs to validate
napi_status
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For this part I was definitely playing the follow-the-pattern game. Is there a reason why the other create primitives aren't validated? I can understand
null
/undefined
/boolean
as they are effectively just getters for global values, butnumber
doesn't have any validation.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
JsNumber should be validating it since it's effectively infallible due to protections on the Rust side.
Thinking about this one a bit more, it should probably return something to indicate an error since there are valid cases where it could
throw
.Maybe check if it's throwing and return None and then assert that it's ok.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not following. I understand this part:
In
neon_runtime::primitive::number()
, the value passed in has to be anf64
, so it's inherently validated by the Rust type system.While in
neon_runtime::primitive::symbol()
,desc
has to be either a null pointer or aLocal
representing aValueType::String
. Adding the status check makes sense to me given that someone could pass in a differentLocal
type, but I don't understand this part:What does this have to do with
throw
? If we're in a throwing state, and this function returnsOption<Local>
We'd have to expect/unwrap it inJsSymbol::new_internal()
in order to returnHandle<JsSymbol>
. If we then unwrap theNone
, that panic would override the current throw state which seems to defeat the point.If it's the case that you're mistaking this function for the description getter, that one currently returns
None
when in a throwing state:Although this is a side effect of
napi::get_property()
failing inneon_runtime::object::get_string()
rather than explicitly checking for the throw state inJsSymbol::description()
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right! I was thinking this method accepts a
str
as a description and converting toJsString
could fail, but it's already anapi_value
here. 🤦I agree, checking the status shouldn't be necessary. It might not hurt to check in a
debug_assert
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer if this were built into Node-API, but looks like it isn't. The best I can tell reading the ECMAScript spec, this property is guaranteed to exist and it's impossible to overwrite. @dherman is that correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI, when I first wrote up the RFC, node@10 was still in maintenance LTS, and symbol.prototype.description was unsupported. With this implementation, if I downgrade to 10.24, the description tests fail both the node and rust getter with:
neon_runtime::tag::is_string(env, local)
returns false in the description function, so it returnsNone
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The good news is we no longer support Node 10 and can make that simplification.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would probably be a little simpler if we added
napi_get_named_property
toneon-runtime
. Usually strings are user provided so we can't be guaranteed they don't contain null, but this one could be a constant.