Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ibc-derive doesn’t work if Context type requires bounds #1016

Closed
mina86 opened this issue Dec 21, 2023 · 2 comments
Closed

ibc-derive doesn’t work if Context type requires bounds #1016

mina86 opened this issue Dec 21, 2023 · 2 comments

Comments

@mina86
Copy link
Contributor

mina86 commented Dec 21, 2023

Feature Summary

ClientState derive requires context type to be specified through a #[generics(...)] annotation. However, this doesn’t work if the context type is generic. For example, consider the following:

use ibc::core::client::context::client_state::ClientState;

#[derive(ClientState)]
#[generics(/* ... */)]
enum AnyClientState {}

struct Context<'a>(&'a ());

What should be put inside of the generics annotation to make the code work? Using:

#[generics(
    ClientValidationContext = Context<'_>,
    ClientExecutionContext = Context<'_>,
)]

results in the proc macro failing to recognise the annotation and output the following message: AnyClientState must be annotated with #[generics(ClientValidationContext = <your ClientValidationContext>, ClientExecutionContext: <your ClientExecutionContext>)]: Multiple errors: (expected :``. Removing the generic argument as in:

#[generics(
    ClientValidationContext = Context,
    ClientExecutionContext = Context,
)]

results in compilation failure:

error[E0726]: implicit elided lifetime not allowed here
 --> src/main.rs:5:31
  |
5 |     ClientValidationContext = Context,
  |                               ^^^^^^^ expected lifetime parameter
  |
help: indicate the anonymous lifetime
  |
5 |     ClientValidationContext = Context<'_>,
  |                                      ++++

Proposal

For my use case it would be enough if generic attributes were recognised after the type.

@Farhad-Shabani
Copy link
Member

Correct, the issue arises when dealing with contexts that involve generic types or lifetimes. We've got the same issue as reported in #910.

@mina86
Copy link
Contributor Author

mina86 commented Dec 21, 2023

Ah, I see, sorry for the duplicate. #910 indeed covers this case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants