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

Closed
Shaddy opened this issue Mar 20, 2024 · 8 comments · Fixed by #1034
Closed

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

Shaddy opened this issue Mar 20, 2024 · 8 comments · Fixed by #1034

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

@tomtau
Copy link
Contributor

tomtau commented Aug 5, 2024

@Shaddy did you manage to fix it? I tried to reproduce it and found that the issue is with the pest_bootstrap executable path:

Bootstrap failed: process didn't exit successfully: `\\?\C:\...\.cargo\git\checkouts\pest-00764f90b4d25bc4\5e96e41\target\debug\pest_bootstrap.exe ...

but that's invoked by the cargo crate:

opts.spec = Packages::Packages(vec!["pest_bootstrap".to_owned()]);

@Shaddy
Copy link
Author

Shaddy commented Aug 20, 2024

@Shaddy did you manage to fix it? I tried to reproduce it and found that the issue is with the pest_bootstrap executable path:

Bootstrap failed: process didn't exit successfully: `\\?\C:\...\.cargo\git\checkouts\pest-00764f90b4d25bc4\5e96e41\target\debug\pest_bootstrap.exe ...

but that's invoked by the cargo crate:

opts.spec = Packages::Packages(vec!["pest_bootstrap".to_owned()]);

Yes! I did the workaround I mention in the first comment, to just normalize the path (Shaddy@9ea1515) but in my case I kept the project local. I could try to reproduce this back if you want

@tomtau
Copy link
Contributor

tomtau commented Aug 23, 2024

@Shaddy
I tried

use normpath::PathExt;
//....
    let pest = Path::new(concat!(
        env!("CARGO_MANIFEST_DIR"),
        "/../meta/src/grammar.pest"
    )).normalize().expect("normalize path").into_path_buf();

and it didn't seem to help

@tomtau tomtau linked a pull request Aug 26, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants