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

Failure to correctly qualify enums in generated code #199

Closed
codemaster138 opened this issue Nov 6, 2022 · 6 comments
Closed

Failure to correctly qualify enums in generated code #199

codemaster138 opened this issue Nov 6, 2022 · 6 comments
Labels
bug Something isn't working generator

Comments

@codemaster138
Copy link

Problem Description

When using enums, the generated prisma.rs file references the enums only with their name rather than a fully qualified identifier, leading to errors such as:

error[E0412]: cannot find type `MyEnum` in this scope
   --> src/prisma.rs:XXX:XX
    |
XXX |       Not(MyEnum),
    |           ^^^^^^^ not found in this scope
    |
help: consider importing this enum
    |
XXX |     use crate::prisma::MyEnum;
    |

To Reproduce

Steps to reproduce the behavior:

  1. Clone codemaster138/prisma-client-rust-repro
  2. Run cargo prisma generate
  3. Run cargo check

Expected Behavior

The code generator should either:

  • Emit use crate::prisma::<Enum Name> statements as needed or
  • Use fully qualified specifiers for enums (e.g. Not(crate::prisma::MyEnum) instead of Not(MyEnum)

Environment

  • Rust Version: 1.63.0
  • Operating System: macOS Monterey (12.6)
  • Processor: Apple M1 (aarch64)
  • Prisma Client Rust Version: 0.6.3

Additional Context

This seems like an issue that should almost definitely have been caught by now, so, if you can't reproduce this, the possibility of being an M1 platform bug should be investigated...

@codemaster138 codemaster138 changed the title Failure to correctly specify enums in generated code Failure to correctly qualify enums in generated code Nov 6, 2022
@Brendonovich Brendonovich added bug Something isn't working generator labels Nov 6, 2022
@Brendonovich
Copy link
Owner

Similar to #197. Will get on these ASAP for 1.6.4.

@codemaster138
Copy link
Author

Oops, hadn't seen that issue. Sorry!

@Brendonovich
Copy link
Owner

No worries, this problem is a bit different so it's ok. Really appreciate the detailed issue haha.

@codemaster138
Copy link
Author

@Brendonovich I'm not sure whether this is a clean fix, but for the example I provided, changing read_filters.rs:17 like this:

-                quote!(#variant_name(#typ)),
+                quote!(#variant_name(super::super::#typ)),

might help...?

@Brendonovich
Copy link
Owner

@codemaster138 I think that will break primitive types (which is what I made the read filter change for). I'll need to check whether the type is a builtin or custom type.

@Brendonovich Brendonovich added this to the 0.6.4 milestone Nov 6, 2022
@Brendonovich
Copy link
Owner

On second look, this is actually a duplicate. Am working on it rn.

@Brendonovich Brendonovich closed this as not planned Won't fix, can't repro, duplicate, stale Nov 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working generator
Projects
None yet
Development

No branches or pull requests

2 participants