Re: [PATCH v4 2/3] rust: macros: add macro to easily run KUnit tests

2024-11-03 Thread Miguel Ojeda
On Sat, Nov 2, 2024 at 1:08 AM Boqun Feng  wrote:
>
> Hmm.. so I think clippy won't warn for a normal Rust #[test] function:
>
> https://github.com/rust-lang/rust-clippy/pull/7811

That is a very good point. It is a bit surprising that those details
are not documented, but we could mimic that behavior.

(Personally, I don't particularly enjoy exceptional/context-dependent
cases, unless it is something used everywhere, like `use`ing the
prelude that we have).

Cheers,
Miguel



Re: [PATCH v4 2/3] rust: macros: add macro to easily run KUnit tests

2024-11-01 Thread Boqun Feng
On Fri, Nov 01, 2024 at 11:12:06PM +0100, Miguel Ojeda wrote:
> On Fri, Nov 1, 2024 at 10:38 PM Boqun Feng  wrote:
> >
> > but this lint doesn't make sense to me, I would say we just drop this
> > lint?
> 
> I am not sure if it is intended to fire there (i.e. to resolve
> constants), but seems OK since it is not something one would want
> normally to write except in exceptional cases.
> 

Hmm.. so I think clippy won't warn for a normal Rust #[test] function:

https://github.com/rust-lang/rust-clippy/pull/7811

but since in this patch #[test] is handled by us instead of by "rustc
--test" (I assume this is how Rust std handle #[cfg(test)] and
#[test]?), clippy doesn't know.

> So we could drop it globally, but if it is just this case that we
> expect, then I think it is better to just `#[expect(...)]` it (or
> perhaps use a different example) and then, if we see in the future
> that we have quite a few "trivial" comparisons like this, then we can
> drop it globally.
> 

It seems to me that clippy agrees not triggering this in test code at
least.

Regards,
Boqun

> Cheers,
> Miguel



Re: [PATCH v4 2/3] rust: macros: add macro to easily run KUnit tests

2024-11-01 Thread Miguel Ojeda
On Fri, Nov 1, 2024 at 10:38 PM Boqun Feng  wrote:
>
> but this lint doesn't make sense to me, I would say we just drop this
> lint?

I am not sure if it is intended to fire there (i.e. to resolve
constants), but seems OK since it is not something one would want
normally to write except in exceptional cases.

So we could drop it globally, but if it is just this case that we
expect, then I think it is better to just `#[expect(...)]` it (or
perhaps use a different example) and then, if we see in the future
that we have quite a few "trivial" comparisons like this, then we can
drop it globally.

Cheers,
Miguel