Skip to content
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.

&[u64] not supported in impl_runtime_apis!() #9790

Open
nazar-pc opened this issue Sep 15, 2021 · 3 comments
Open

&[u64] not supported in impl_runtime_apis!() #9790

nazar-pc opened this issue Sep 15, 2021 · 3 comments
Labels
I4-annoyance The client behaves within expectations, however this “expected behaviour” itself is at issue.

Comments

@nazar-pc
Copy link
Contributor

&Vec<u64> works while &[u64] doesn't:

  error[E0277]: the size for values of type `[u64]` cannot be known at compilation time
      --> .../substrate/substrate-test-runtime/src/lib.rs:1046:33
       |
  1046 |                 fn benchmark_vector_add_one(slice: &[u64]) -> Vec<u64> {
       |                                             ^^^^^^^^ doesn't have a size known at compile-time
       |
       = help: the trait `Sized` is not implemented for `[u64]`
       = note: all local variables must have a statically known size
       = help: unsized locals are gated as an unstable feature
@bkchr
Copy link
Member

bkchr commented Sep 16, 2021

Using a reference or a vector doesn't make any difference, because we need to encode it before calling into the runtime.

We should improve the macro and print a proper error, instead of letting it fail this way.

@bkchr bkchr added the I4-annoyance The client behaves within expectations, however this “expected behaviour” itself is at issue. label Sep 16, 2021
@nazar-pc
Copy link
Contributor Author

There is a difference from point of view of idiomatic Rust API. Especially since it is going to be encoded anyway, there is no reason to have a reference to vector in function signature. This is something clippy complained about when I ran it over the project.

@bkchr
Copy link
Member

bkchr commented Sep 27, 2021

Just because clippy is complaining, it doesn't mean that it is a correct complain.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
I4-annoyance The client behaves within expectations, however this “expected behaviour” itself is at issue.
Projects
None yet
Development

No branches or pull requests

2 participants