Use construct_runtime in tests

[gui1117]

related #7949

[gui1117]

here the pallet is declared in its own module, but nothing has changed

[gui1117]

here benchmark macro is called in its own module because benchmark macro uses in scope Call for the pallet call. But construct_runtime already defines the outer Call.

the benchmark call and the test below haven't been changed

[gui1117]

previously Call was a struct which panics in its implementation of dispatchable and was meant to be not used.
Using a random call doesn't change the nature of the test

[kianenigma]

Would be nice to somehow also warn if someone uses PalletInfo = (), because basically now this is now dangerous if you use it in any test setup that has multiple pallets.

[gui1117]

Would be nice to somehow also warn if someone uses PalletInfo = (), because basically now this is now dangerous if you use it in any test setup that has multiple pallets.

yes but we can't deprecate a trait implementation, we can only warn during execution by printing some message, or remove it.

[gui1117]

bot merge

[ghost]

Waiting for commit status.

[ghost]

Checks failed; merge aborted.

[gui1117]

bot merge

[ghost]

Waiting for commit status.

[shawntabrizi]

we can't deprecate a trait implementation

Why not?

[ascjones]

rust-lang/rust#39935

[kianenigma]

I think adding a manual line of warning in the impl is also capable of preventing some people messing up their test setup :D

[ascjones]

I was thinking that once all PalletInfo = () instances have been removed then we just delete the () implementation entirely. Better to get a compilation error than spend ages debugging your tests for a storage collision.

[kianenigma]

I was thinking that once all PalletInfo = () instances have been removed then we just delete the () implementation entirely. Better to get a compilation error than spend ages debugging your tests for a storage collision.

💯