Skip to content
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

Merged
merged 4 commits into from
Jul 13, 2022

Conversation

itegulov
Copy link
Contributor

Forgot to extract the underlying type from Vec<_> for ABI

Copy link
Contributor

@austinabell austinabell left a 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

Comment on lines +48 to +49
&& path.segments.len() == 1
&& path.segments.iter().next().unwrap().ident == "Vec"
Copy link
Contributor

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

Copy link
Contributor Author

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.

Copy link
Contributor

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)]
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Comment on lines +48 to +49
&& path.segments.len() == 1
&& path.segments.iter().next().unwrap().ident == "Vec"
Copy link
Contributor

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

@itegulov itegulov merged commit 61b5a8e into master Jul 13, 2022
@itegulov itegulov deleted the daniyar/callback-vec-abi branch July 13, 2022 05:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants