const generic parameter is not ordered correctly on async fn with body

[zjijz]

#[async_trait]
trait Test {
    async fn run<const DUMMY: bool>(self) -> ()
    where
        Self: Sized
    {
        println!("what")
    }
}

expands to

trait Test {
    #[allow(clippy :: used_underscore_binding)]
    #[must_use]
    fn run<'async_trait, const DUMMY : bool>(self)
     ->
         ::core::pin::Pin<Box<dyn ::core::future::Future<Output = ()> +
                              ::core::marker::Send + 'async_trait>> where
     Self: Sized, Self: ::core::marker::Send + 'async_trait {
        #[allow(unused_parens, clippy :: missing_docs_in_private_items, clippy
                :: needless_lifetimes, clippy :: ptr_arg, clippy ::
                trivially_copy_pass_by_ref, clippy ::
                type_repetition_in_bounds, clippy ::
                used_underscore_binding,)]
        async fn __run<const DUMMY : bool, AsyncTrait: ?Sized + Test +
                       ::core::marker::Send>(_self: AsyncTrait) -> () where
         (): Sized, AsyncTrait: Sized {

            {
                ::std::io::_print(::core::fmt::Arguments::new_v1(&["what\n"],
                                                                 &match () {
                                                                      () =>
                                                                      [],
                                                                  }));
            }
        }
        Box::pin(__run::<Self, DUMMY>(self))
    }
}

Example: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=8958651135342165990e5cf7d6735145

The compiler gives these error messages:

error: type parameters must be declared prior to const parameters
 --> src/main.rs:5:1
  |
5 | #[async_trait]
  | ^^^^^^^^^^^^^^ help: reorder the parameters: lifetimes, then types, then consts: `<AsyncTrait: ?Sized + Test + ::core::marker::Send, const DUMMY: bool>`
  |
  = note: this error originates in an attribute macro (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0747]: type provided when a constant was expected
 --> src/main.rs:5:1
  |
5 | #[async_trait]
  | ^^^^^^^^^^^^^^
  |
  = note: type arguments must be provided before constant arguments
  = help: reorder the arguments: types, then consts: `<AsyncTrait, DUMMY>`
  = note: this error originates in an attribute macro (in Nightly builds, run with -Z macro-backtrace for more info)

This issue seems to specifically be the param ordering on the inner async function: async fn __run<const DUMMY : bool, AsyncTrait: ?Sized + Test ....

I think expand.rs:420 is the offending line as it simply appends the _self type to the param list. I imagine this isn't an issue when only using lifetimes and types because this upholds the required order. This also means prepending doesn't solve the issue as well (since it would break using lifetime generics).

My idea would be to assume the user orders the manual generics properly and find insert the _self type right before const generics start. Another option is to sort the params after inserting, which would also fix an incorrect ordering provided by the user.

EDIT: This is while using #![feature(min_const_generics)].

[zjijz]

Apparently, this is only an issue for #![feature(min_const_generics)] and not #![feature(const_generics)] (rust-lang/rust#74953).

However, #![feature(const_generics)] breaks with this message:

error[E0747]: type provided when a constant was expected
 --> src/lib.rs:5:1
  |
5 | #[async_trait]
  | ^^^^^^^^^^^^^^
  |
  = note: this error originates in an attribute macro (in Nightly builds, run with -Z macro-backtrace for more info)
help: if this generic argument was intended as a const parameter, try surrounding it with braces:
  |
5 | { #[async_trait] }

Example: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=5d0ad43b1ec667ae0326a97dd56b9c42.

[taiki-e]

Both issues will be fixed by #136.

Another option is to sort the params after inserting, which would also fix an incorrect ordering provided by the user.

I think adjusting the wrong input silently is a bad idea.