Marcro fails clippy checks with specific wit that doesn't have a return value

[jsturtevant]

What happened?

The host_bindgen macro fails clippy:

cargo clippy --profile=dev --all-targets --all-features -- -D warnings
   Compiling hyperlight-wasm v0.1.0 (/home/jstur/projects/hyperlight-wasm/src/hyperlight_wasm)
    Checking examples_common v0.9.0 (/home/jstur/projects/hyperlight-wasm/src/examples_common)
    Checking hyperlight-wasm-aot v0.1.0 (/home/jstur/projects/hyperlight-wasm/src/hyperlight_wasm_aot)
error: unneeded unit expression
 --> src/hyperlight_wasm/examples/wasi_examples/main.rs:6:5
  |
6 |     hyperlight_component_macro::host_bindgen!("../wasi_samples/wit/component-world.wasm");
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#unused_unit
  = note: `-D clippy::unused-unit` implied by `-D warnings`
  = help: to override `-D warnings` add `#[allow(clippy::unused_unit)]`
  = note: this error originates in the macro `hyperlight_component_macro::host_bindgen` (in Nightly builds, run with -Z macro-backtrace for more info)

error: could not compile `hyperlight-wasm` (example "wasi_examples") due to 1 previous error
warning: build failed, waiting for other jobs to finish...

This is becuase it generates code like:

fn r#do_something(&mut self, r#number: u32) -> () {
        let ret = ::hyperlight_host::sandbox::Callable::call::<
            ::std::vec::Vec<u8>,
        >(
            &mut self.sb,
            "r#wasi_sample::r#example::do-something",
            ({ alloc::vec::Vec::from(u32::to_ne_bytes(r#number)) },),
        );
        let ::std::result::Result::Ok(ret) = ret else {
            panic!("bad return from guest {:?}", ret)
        };
        ()
    }

The work around is to add

#![allow(renamed_and_removed_lints)]
#![allow(unused_unit)]

to the top of the file that uses the macro. unused_unit is apparently removed?

What did you expect to happen?

shouldn't have to modify my clippy warnings

Steps to reproduce the behavior

When using wit like:

package wasi-sample:example;

world example {
  import host;
  export adder;
}

interface adder {
  add: func(left: u32, right: u32) -> u32;
  call-host: func(input: string) -> string;
  do-something: func(number: u32);
}

interface host {
  print: func(message: string);
  host-function: func(input: string) -> string;
}

Hyperlight Version

0.6.1

OS version

Details

On Linux:
$ cat /etc/os-release
# paste output here

$ uname -a
# paste output here

On Windows:
C:\> cmd /c ver
# paste output here

Additional Information

No response

[jsturtevant]

I think it is coming from

hyperlight/src/hyperlight_component_util/src/rtypes.rs

Lines 524 to 530 in dcc5b59

	pub fn emit_func_result(s: &mut State, r: &Result) -> TokenStream {
	match r {
	Result::Unnamed(vt) => emit_value(s, vt),
	Result::Named(rs) if rs.is_empty() => quote! { () },
	_ => panic!("multiple named function results are not currently supported"),
	}
	}

[syntactically]

Most lints aren't supposed to apply to macro-generated code, since usually the focus there is on making the macros clear over trying to ensure that every special case is the most idiomatic it can be.

(The lints do get triggered when you build with HYPERLIGHT_COMPONENT_MACRO_DEBUG=/path/to/file.rs, since the tokens are included from the file rather than the macro output, but I think that's fine)

I remember running into a similar problem with this lint triggering where it shouldn't be and solved it just by adding #[allow] in the appropriate place inside the macro. I think I would rather do that than add special cases.

(Or try to fix the bugs in clippy...)\

[jsturtevant]

Most lints aren't supposed to apply to macro-generated code, since usually the focus there is on making the macros clear over trying to ensure that every special case is the most idiomatic it can be.

(The lints do get triggered when you build with HYPERLIGHT_COMPONENT_MACRO_DEBUG=/path/to/file.rs, since the tokens are included from the file rather than the macro output, but I think that's fine)

I thought this was the case but it seems to get triggered during clippy for some reason even with out the ENV.

I remember running into a similar problem with this lint triggering where it shouldn't be and solved it just by adding #[allow] in the appropriate place inside the macro. I think I would rather do that than add special cases.

makes sense

[syntactically]

I thought this was the case but it seems to get triggered during clippy for some reason even with out the ENV.

Yes, IMO this is probably a bug in Clippy, but I haven't had a chance to minimize an example/report/etc yet.