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

GraphQLInputObject macro fails if crate has a local type alias named "Result" #1194

Closed
LGUG2Z opened this issue Oct 2, 2023 · 0 comments · Fixed by #1195
Closed

GraphQLInputObject macro fails if crate has a local type alias named "Result" #1194

LGUG2Z opened this issue Oct 2, 2023 · 0 comments · Fixed by #1195
Labels
bug Something isn't working
Milestone

Comments

@LGUG2Z
Copy link

LGUG2Z commented Oct 2, 2023

Describe the bug
In a crate with this type alias:

type Result<T> = std::result::Result<T, diesel::result::Error>;

Deriving GraphQLInputObject for structs that include optional values will fail.

To Reproduce

Given the above type alias, and the following struct

#[derive(juniper::GraphQLInputObject)]
#[graphql(name = "UserInformation")]
pub struct Update {
    pub email: Option<String>,
    pub username: Option<String>,
}

The following error is returned:

error[E0107]: type alias takes 1 generic argument but 2 generic arguments were supplied
  --> models/src/user.rs:29:51
   |
29 | #[derive(Serialize, Deserialize, Debug, Validate, juniper::GraphQLInputObject)]
   |                                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |                                                   |
   |                                                   expected 1 generic argument
   |                                                   help: remove this generic argument
   |
note: type alias defined here, with 1 generic parameter: `T`
  --> models/src/lib.rs:52:6
   |
52 | type Result<T> = std::result::Result<T, diesel::result::Error>;
   |      ^^^^^^ -
   = note: this error originates in the derive macro `juniper::GraphQLInputObject` (in Nightly builds, run with -Z macro-backtrace for more info)

Expected behavior

Successful compilation, as happens when the type alias is renamed to anything else, for example, there are no issues with the following:

type DatabaseResult<T> = std::result::Result<T, diesel::result::Error>;

Additional context

juniper = { git = "https://github.com/graphql-rust/juniper.git", rev ="984973658217f73d63608283d18723e11ce65161", default-features = false, features = ["schema-language", "url", "chrono"] }
@LGUG2Z LGUG2Z added bug Something isn't working needs-triage labels Oct 2, 2023
tpoliaw added a commit to tpoliaw/juniper that referenced this issue Oct 2, 2023
If user code has a type alias (or custom type) called `Result`, this
would be used instead of the intended standard library result, causing
surprising compile errors from generated code.

Using the fully qualified path allows the generated code to be isolated
from user types.

Fixes graphql-rust#1194
tpoliaw added a commit to tpoliaw/juniper that referenced this issue Oct 4, 2023
If user code has a type alias (or custom type) called `Result` or
`Option` etc, this would be used instead of the intended standard
library types causing surprising compile errors from generated code.

Using the fully qualified path allows the generated code to be isolated
from user types.

Includes two basic regression tests covering `Result` and `Send`.

Fixes graphql-rust#1194
LegNeato pushed a commit that referenced this issue Oct 6, 2023
If user code has a type alias (or custom type) called `Result` or
`Option` etc, this would be used instead of the intended standard
library types causing surprising compile errors from generated code.

Using the fully qualified path allows the generated code to be isolated
from user types.

Includes two basic regression tests covering `Result` and `Send`.

Fixes #1194
@tyranron tyranron added this to the 0.16.0 milestone Oct 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants