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.

Sign up for GitHub

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
Merged

fix: extract #[callback_vec] vec type for abi #863

Show file tree
Hide file tree
Changes from 2 commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
b7faccf
extract #[callback_vec] vec type for abi
itegulov Jun 30, 2022
1b3cde7
allow dead code
itegulov Jun 30, 2022
56c2949
move extract_vec_type under abi feature
itegulov Jul 12, 2022
9b1a629
Merge branch 'master' into daniyar/callback-vec-abi
itegulov Jul 13, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 9 additions & 0 deletions near-sdk-macros/src/core_impl/abi/abi_generator.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -93,6 +93,15 @@ impl ImplItemMethodInfo {
}
BindgenArgType::CallbackArgVec => {
if callback_vec.is_none() {
let typ = if let Some(vec_type) = utils::extract_vec_type(typ) {
vec_type
} else {
return syn::Error::new_spanned(
&arg.ty,
"Function parameters marked with #[callback_vec] should have type Vec<T>",
)
.into_compile_error();
};
callback_vec = Some(quote! {
Some(
near_sdk::__private::AbiType {
Expand Down
33 changes: 33 additions & 0 deletions near-sdk-macros/src/core_impl/utils/mod.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -39,3 +39,36 @@ pub(crate) fn extract_ok_type(ty: &Type) -> Option<&Type> {
_ => None,
}
}

/// Checks whether the given path is literally "Vec".
/// Note that it won't match a fully qualified name `std::vec::Vec` or a type alias like
/// `type MyVec = Vec<String>`.
fn path_is_vec(path: &Path) -> bool {
path.leading_colon.is_none()
&& path.segments.len() == 1
&& path.segments.iter().next().unwrap().ident == "Vec"
Comment on lines +49 to +50
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.

pub(crate) fn extract_vec_type(ty: &Type) -> Option<&Type> {
match ty {
Type::Path(type_path) if type_path.qself.is_none() && path_is_vec(&type_path.path) => {
let type_params = &type_path.path.segments.first()?.arguments;
let generic_arg = match type_params {
// We are interested in the first (and only) angle-bracketed param:
PathArguments::AngleBracketed(params) if params.args.len() == 1 => {
Some(params.args.first()?)
}
_ => None,
}?;
match generic_arg {
GenericArgument::Type(ty) => Some(ty),
_ => None,
}
}
_ => None,
}
}