-
-
Notifications
You must be signed in to change notification settings - Fork 785
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
Build script fails to resolve syntex::Registry #202
Comments
Apparently this is happening due to rust-lang/cargo#2064. |
As a workaround you can lock quasi to 0.3.11, aster to 0.9.2, syntex to 0.24.0, and syntex_syntax to 0.24.0. I think the problem here might be a bit simpler than that cargo bug. I think here it's just breaking API changes that weren't versioned perfectly. |
@JohnHeitmann: I did do a release yesterday which should have fixed this issue on stable rust. nightly rust support is currently broken due to rust-lang/rust#30713. I was thinking about this issue yesterday, and yeah, I think I did make a semver violation here. While I didn't have to modify any quasi code when I updated it to 0.3.12, I did do a major change on a public dependency. Along with rust-lang/cargo#2064, this means I ended up with two instances of syntex, which caused this confusing error message. I'll be more careful next time. |
I'm still seeing this today (2 different versions of syntex), but might be related to another cargo issue: rust-lang/cargo#2277 Edit: for me the following worked:
The last command outputs the very strange:
Unclear how this can be the case, as 'my_project' uses a bare wildcard ("*") to specify the syntex version. Might be (another) cargo bug. |
This should be fixed now. Please reopen if you still have problems. |
This is happening to me on nightly now, not sure if it's the same issue or not:
In Cargo.toml: [dependencies]
serde = "0.6.11"
serde_json = "0.6.0"
serde_macros = "0.6.11"
|
Disregard that last comment. I discovered the issue: I was depending on a crate that uses Serde but only supported building Rust stable/serde_codegen. Modifying that dependency to build on both stable and nightly did the trick. I'm not totally clear why, but it seems that if syntex is added to the build at all, quasi_macros will choke. |
Can this be reopened? I'm having the same issue again: failing to build on nightly because a dependency somehow introduced syntex (and so far I'm not spotting how to get rid of it.) Seems like this is a problem more people might run into and perhaps there's a way to deal with it at the library level. Edit: Like the previous time I reported it, the error shows the problem as being in quasi_macros, not serde_codegen like in my original report. |
@jimmycuadra: Any chance you could push up your work somewhere in a branch so I could look into it? |
It's already public, actually! The main project is https://github.com/rusoto/rusoto. Check out the feature-rust-codegen branch. You'll also need https://github.com/rusoto/botocore_parser checked out to a sibling directory (there's a path dependency.) Thanks for reopening. |
I'm getting this too. Is there a way to work around this? |
Is there actually anything that can be done to solve this? This seems like a very unfortunately cargo edge case. I'm stuck in syntex hell because my project's dependencies use serde_codegen instead of serde_macros. 😭 |
Happens to me too :( |
Check out this forum topic for how to fix this permanently by using |
This started happening in a crate that uses Serde with code generation.
Output from
cargo build
The text was updated successfully, but these errors were encountered: