Bevy malformed system errors are extremely unhelpful due to macro-magic

[alice-i-cecile]

Following the full reproduction (with more context) here, the following code produces the two following errors:

use bevy::prelude::*;

#[derive(Debug)]
struct MyResource;

// The user has forgotten to add the Res wrapper around MyResource
fn malformed_system_parameter_system(my_res: MyResource) {}

// The user has invalidly requested a mutable reference to Commands,
// rather using `mut commands: Commands`
fn requesting_commands_as_reference_system(commands: &mut Commands) {}

fn main() {
    App::new()
        //
        .add_system(malformed_system_parameter_system)
        //
        .add_system(requesting_commands_as_reference_system)
        .run()
}

Errors:

the trait bound `fn(MyResource) {malformed_system_parameter_system}: IntoSystem<(), (), _>` is not satisfied
required because of the requirements on the impl of `IntoSystemDescriptor<_>` for `fn(MyResource) {malformed_system_parameter_system}`

the trait bound `for<'r, 's, 't0> fn(&'r mut bevy::prelude::Commands<'s, 't0>) {requesting_commands_as_reference_system}: IntoSystem<(), (), _>` is not satisfied
required because of the requirements on the impl of `IntoSystemDescriptor<_>` for `for<'r, 's, 't0> fn(&'r mut bevy::prelude::Commands<'s, 't0>) {requesting_commands_as_reference_system}`

Errors like this occur constantly whenever users try to include a parameter to a function that is transformed into a system that does not implement SystemParam.
As you might expect, there is quite a bit of type magic required to get this to work at all, and we use an all_tuples macro to work around the lack of variadic generics.

The ideal error message would identify which argument(s) is at fault, and complain that it does not implement SystemParam.

[davidpdrsn]

I'm having similar issues in axum. We have this trait which is implemented for functions with different number of arguments. Bevy does something similar.

Here is a minimal repro:

use std::future::Future;

pub trait Handler<T> {}

impl<F, Fut> Handler<()> for F
where
    F: FnOnce() -> Fut,
    Fut: Future,
{
}

impl<F, Fut, T1> Handler<(T1,)> for F
where
    F: FnOnce(T1) -> Fut,
    Fut: Future,
{
}

#[test]
fn test() {
    fn check_handler<H, T>(_: H)
    where
        H: Handler<T>,
    {
    }

    check_handler(|| {});
}

The issue here is that the closure passed to check_handler doesn't return a future but the error message is quite opaque:

error[E0277]: the trait bound `[closure@src/lib.rs:27:19: 27:24]: Handler<_>` is not satisfied
  --> src/lib.rs:27:5
   |
21 |     fn check_handler<H, T>(_: H)
   |        ------------- required by a bound in this
22 |     where
23 |         H: Handler<T>,
   |            ---------- required by this bound in `check_handler`
...
27 |     check_handler(|| {});
   |     ^^^^^^^^^^^^^ the trait `Handler<_>` is not implemented for `[closure@src/lib.rs:27:19: 27:24]`

For more information about this error, try `rustc --explain E0277`.
error: could not compile `bad-error` due to previous error

This isn't exactly because of "macro-magic" but because Handler is implemented as Handler<()> and Handler<(T1,)> and I suppose rust doesn't know which impl the user is trying to access so doesn't have any context to provide a better error.