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

Using pest_derive without std under a workspace fails in Windows. #996

Open
Shaddy opened this issue Mar 20, 2024 · 5 comments
Open

Using pest_derive without std under a workspace fails in Windows. #996

Shaddy opened this issue Mar 20, 2024 · 5 comments

Comments

@Shaddy
Copy link

Shaddy commented Mar 20, 2024

Describe the bug

I have a project that requires no_std, using following dependencies in Cargo.toml

pest = { git = "https://github.com/pest-parser/pest.git", version = "2.7.8", default-features = false }
pest_derive = { git = "https://github.com/pest-parser/pest.git", version = "2.7.8", default-features = false, features = ["not-bootstrap-in-src"] }

That fails to locate the bootstrap file under Windows, while in MacOS or Linux is working properly.

To Reproduce

  • Use pest_derive under a workspace project with no_std.

NOTE: I can provide a project to reproduce the bug if necessary.

Expected behavior

pest_bootstrap.exe not panicking trying to locate /meta/src/grammar.pest

Additional context

After debugging generated pest_bootstrap.exe I came to the conclusion that the problematic part is the path retrieved by env!("CARGO_MANIFEST_DIR") here:

    let pest = Path::new(concat!(
        env!("CARGO_MANIFEST_DIR"),
        "/../meta/src/grammar.pest"
    ));

It seems to prepend \\?\ to the Path, making it fail when trying to resolve the relative "../meta" path.

I managed to fix this issue here:

Shaddy@9ea1515

But probably is not the best way to do it, it is just a workaround.

@tomtau
Copy link
Contributor

tomtau commented Mar 20, 2024

I wonder why that would be: is it this https://superuser.com/questions/1069055/what-is-the-function-of-question-marks-in-file-system-paths-in-windows-registry ?

I have seen the ?\C:... path used a lot to get access to files/paths longer than 260 characters. At least when dealing with Win32 API calls. (...)

It could also be a bug in Cargo / Rust tooling in how it populates those env vars on Windows?

@tomtau
Copy link
Contributor

tomtau commented Mar 20, 2024

rust-lang/cargo#9770

@tomtau
Copy link
Contributor

tomtau commented Mar 20, 2024

Maybe a proper fix is to use something like normpath: wasmCloud/wasmCloud@8b876f1 ?

@tomtau
Copy link
Contributor

tomtau commented Mar 21, 2024

or call canonicalize on env!("CARGO_MANIFEST_DIR") and then use .push(es) to construct the path?

@Shaddy
Copy link
Author

Shaddy commented Mar 21, 2024

or call canonicalize on env!("CARGO_MANIFEST_DIR") and then use .push(es) to construct the path?

I tried with canonicalize but it has the same problem, as soon as you enter relative path with the prefix "canonicalize" it simply does not find the file. And if the prefix is already there, it won't be removed.

I also don't understand that if I create a simple project with a build.rs and load the CARGO_MANIFEST_DIR path is not prepended with \\?\, but that's another story (tested just in case, if was because the Cargo.toml rustc version but it seems only happens when running from a different directory).

normpath sounds like the best approach probably at this moment

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

No branches or pull requests

2 participants