Workspace path mismatch with Rust Analyzer

[jssblck]

Hello! Thanks for taking the time to make this library, it's great!

In #9, an issue was observed with "workspace usage". The decision was that this wasn't truly broken, which is fair, but a problem when the code interacts with Rust Analyzer.

Specifically, I have code like this:

// Workspace is at `/project`, e.g. `/project/Cargo.toml` is the workspace root.

// In `/project/server/src/api.rs`, Rust Analyzer displays an error:
#[utoipauto::utoipauto(paths = "./server/src")]
#[derive(OpenApi)]
#[openapi(
    info(
        description = include_str!("../../docs/api.md"),
    ),
    modifiers(&InfoAddon, &SecurityAddon),
)]
struct ApiDoc;

This causes Rust Analyzer to report the error "Failed to parse file: ./server/src":

However, the build succeeds:

; cargo clean && cargo build
     Removed 8110 files, 4.5GiB total
   Compiling proc-macro2 v1.0.86
   ...
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 25.44s

Obviously, this isn't a case where the library is broken, but I think this is a case where the library makes assumptions about how the macro is executed that aren't compatible with Rust Analyzer.

Do you have any suggestions for steps I could take to resolve this issue?

[DenuxPlays]

I think I have the same issue but just have not recognized it.

I use RustRover as my IDE so I do not get to see the Rust-Analyzer errors directly but I've never had code-completion/intellisense on my ApiDoc struct.

I'll have a look but my knowledge about the rust-analyzer is fairly limited.
Would be great if someone else could also take a look at it.

[jssblck]

I suspect that the issue here is that Rust Analyzer executes the macro in a different directory, so making the macro normalize the path to be based on the workspace root would fix the problem.

If I get time I'll take a stab at fixing it!

[DenuxPlays]

I suspect that the issue here is that Rust Analyzer executes the macro in a different directory, so making the macro normalize the path to be based on the workspace root would fix the problem.

If I get time I'll take a stab at fixing it!

This would be great 👌

Let me know if you need any help.
Also if this isn't the root problem please report it back.

[ProbablyClem]

I've noticed the same issue but had no clue about how to fix it.
Thanks for your help

[ginkcode]

I don't have solution for this issue. But I think rust-analyzer diagnostics is quite annoying rather than giving any useful info.
As we always verify project via cargo check / clippy.
If you're using VSCode, can turn it off via this setting:

"rust-analyzer.diagnostics.enable": false

[DenuxPlays]

Idea:

Check if we can find out the project Directory (maybe Cargo envs)

CD into absolut path instead of the relative

[DenuxPlays]

Maybe this if they have a crate to use

https://doc.rust-lang.org/cargo/commands/cargo-locate-project.html

Would also improve workspace support

[domenicquirl]

I suspect that the issue here is that Rust Analyzer executes the macro in a different directory, so making the macro normalize the path to be based on the workspace root would fix the problem.

Just as a note / some context: I mentioned doing this previously in #7 (comment), but didn't actually end up doing it because there was a simpler fix for the specific issue with normalizing module paths:

The fully correct thing would probably be to actually resolve the Cargo.toml responsible for the file / module to determine the crate root.

[DenuxPlays]

I think I did it with this pr:

#47

But I haven't tested it enough yet.