Copy-paste things needed for nearcore#8323

[Ekleog-NEAR]

This is only copy-paste, and should be purely non-functional changes only.

Some files were deleted from the 127ff1164ff commit of wasmer, in order to not use space in the git history forever.

Further changes needed to actually implement the protocol update will be done in separate PRs, that will also be extracted from nearcore#8323.

[nagisa]

Integrate with the top-level deny.toml

[Ekleog-NEAR]

I’ve dropped these files as part of #8796, so that this PR remains a simple copy-paste even when it’ll have been squashed by near-buildozer :)

[aborg-dev]

Hey @Ekleog-NEAR , for some reason this broke my local test build with the following error message:

akashin@hal ~/r/nearcore (compute_costs_feature)> cargo test
   Compiling near-o11y v0.0.0 (/Users/akashin/repos/nearcore/core/o11y)
   Compiling awc v3.0.0
   Compiling near-vm-vm v0.0.0 (/Users/akashin/repos/nearcore/runtime/near-vm/lib/vm)
   Compiling neard v0.0.0 (/Users/akashin/repos/nearcore/neard)
   Compiling near-vm-compiler-test-derive v0.0.0 (/Users/akashin/repos/nearcore/runtime/near-vm/tests/lib/compiler-test-derive)
   Compiling near-vm-types v0.0.0 (/Users/akashin/repos/nearcore/runtime/near-vm/lib/types)
error: mismatched attribute proc macro signature
  --> runtime/near-vm/tests/lib/compiler-test-derive/src/lib.rs:40:65
   |
40 | pub fn compiler_test(attrs: TokenStream, input: TokenStream) -> TokenStream {
   |                                                                 ^^^^^^^^^^^ found TokenStream2, expected type `proc_macro::TokenStream`
   |
   = note: attribute proc macros must have a signature of `fn(TokenStream, TokenStream) -> TokenStream`

error: mismatched attribute proc macro signature
  --> runtime/near-vm/tests/lib/compiler-test-derive/src/lib.rs:40:29
   |
40 | pub fn compiler_test(attrs: TokenStream, input: TokenStream) -> TokenStream {
   |                             ^^^^^^^^^^^ found TokenStream2, expected type `proc_macro::TokenStream`
   |
   = note: attribute proc macros must have a signature of `fn(TokenStream, TokenStream) -> TokenStream`

error: mismatched attribute proc macro signature
  --> runtime/near-vm/tests/lib/compiler-test-derive/src/lib.rs:40:49
   |
40 | pub fn compiler_test(attrs: TokenStream, input: TokenStream) -> TokenStream {
   |                                                 ^^^^^^^^^^^ found TokenStream2, expected type `proc_macro::TokenStream`
   |
   = note: attribute proc macros must have a signature of `fn(TokenStream, TokenStream) -> TokenStream`

error: could not compile `near-vm-compiler-test-derive` due to 3 previous errors
warning: build failed, waiting for other jobs to finish...

The rustc version: rustc 1.69.0-nightly (13471d3b2 2023-03-02)

Do you have any suggestions on how to fix this?

[nagisa]

@Akashin try cargo clean first and foremost.

[aborg-dev]

Thanks for the suggestion, @nagisa. I ran cargo clean before the cargo test, but it still fails with the same error. Another data-point is that cargo build works fine.

Digging more into this and reading https://petanode.com/posts/rust-proc-macro/, is seems like the solution is to use

proc_macro::TokenStream instead of proc_macro2::TokenStream in the function compiler_test(attrs: TokenStream, input: TokenStream) -> TokenStream. But then apparently there was some reason why this was done differently?

[nagisa]

Probably not, this code is just quite old and IIRC wasn't part of CI for quite some time at this point, I believe.

[Ekleog-NEAR]

@Akashin Can you try with cargo nextest run? cargo test is unsupported by quite a few of our tests already, and on my GCP VM, running cargo nextest run from the root of aab4fa5 passes. (Using rustc 1.68.2, which is the one specified by the rust-toolchain.toml file on this commit.)

Anyway, if you have a fix to the issue you’re seeing feel free to fix it; as @nagisa said it’s literally just old code copy-pasted from the wasmer that I’m not at all sure whether/how it’s even used in practice :)

[aborg-dev]

@Ekleog-NEAR , ah, I didn't know about nextest, looks fancy!
After a bit of experimentation, I found that using Rust 1.68.2 fixes the problem on my end, so that must have been the root cause.
I think this is good enough for me, thanks for the help!