-
Notifications
You must be signed in to change notification settings - Fork 251
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
fix: extract #[callback_vec] vec type for abi #863
Conversation
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.
Just a change to the dead_code comment is fine
&& path.segments.len() == 1 | ||
&& path.segments.iter().next().unwrap().ident == "Vec" |
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.
Why is this necessary? Anything else other than a Vec
would fail to compile by the macros, so why not allow aliases? Very niche case so fine to ignore
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.
As I said in my other comment a verbose check just makes errors more transparent, but yeah this certainly comes with its own downsides. Happy to go either way.
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.
Yeah, we can leave for now. Easier to add support for aliases later than to take it away
/// Extracts the inner generic type from a `Vec<_>` type. | ||
/// | ||
/// For example, given `Vec<String>` this function will return `String`. | ||
#[allow(dead_code)] |
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 should just be marked as only non-wasm32 config rather than allowing dead code, to make sure if this goes unused in the future it will be warned to remove.
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.
Dead code warning is happening because it is only used in modules enabled by abi
feature. My reasoning for not annotating this function with #[cfg(feature = "abi")]
was that it has nothing specific to do with abi and it might be generally useful in other places (e.g. should we actually check the collection type in near_bindgen macro to report an error that makes sense? right now you would get an error saying that an iterator cannot be collected to type X which might be difficult to interpret).
If you think it still should be under abi feature I am happy to do so.
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.
yeah just under the abi feature is better, my bad on the assumption it was based on target. Better this way because if it's needed otherwise, can just change the config then. Harder to remember to remove the function if unused, or remove the dead_code annotation if it does become used.
&& path.segments.len() == 1 | ||
&& path.segments.iter().next().unwrap().ident == "Vec" |
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.
Yeah, we can leave for now. Easier to add support for aliases later than to take it away
Forgot to extract the underlying type from
Vec<_>
for ABI