-
Notifications
You must be signed in to change notification settings - Fork 614
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
slint does not compile due to "lifetime parameters or bounds on type Target
do not match the trait declaration"
#5702
Comments
Interesting, I've never seen this before. How did you install Rust/Cargo? Is there any chance this goes away if you wipe the |
Rustup. I'm using the stable channel. It shouldn't make a difference but I'm on Fedora 40.
It does not unfortunately. It's a fresh clone but I cleared my target folder just to be sure. |
This definitely strange. I went into an existing rust project of mine and added fn main() {
let str = "some string";
let _abc = str
.parse::<css_color_parser2::Color>().unwrap();
for (name, c) in css_color_parser2::NAMED_COLORS.iter() {
println!("color: {}", name);
}
} And it failed, with the same error as above. I deleted the I noticed that |
Thanks for the analysis - I think you're right. We should eliminate the dependency to |
We have multiple uses of the parser. One in the compiler, where all we're interested in are the named colors from the CSS standard. This is the one you're running into and it's easy to fix - I'll do that right away. The other uses are in the Node.js and Python bindings, where we aim to support parsing |
The crate uses an old version of lazy_static that doesn't seem to reliably compiler with newer versions of Rust. This is a partial fix for #5702 as all the compiler needs is the named color table.
I tried to verify this, but I'm not successful here. The upload to crates.io seems to have "1", not "0.1" for the dependency: https://docs.rs/crate/css-color-parser2/latest/source/Cargo.toml In fact, my local build (with latest Rust, etc.) shows with Would you be able to run |
@SirMangler I have one more question: The issue description refers to an attempt to build Slint from the git repo from what looks like the v1.7.1 tag. That tag does have a |
The crate uses an old version of lazy_static that doesn't seem to reliably compiler with newer versions of Rust. This is a partial fix for #5702 as all the compiler needs is the named color table.
Oddly, the css-color-parser2 crate page links to a github which appears to not contain any of the latest changes on the crate (ie lazy_static v1.5 as you have noted). I got that version number from the linked github's latest version of the Cargo.toml, you're correct that the actual version is 1.0.1.
On a fresh clone, this is 1.5.0. However on my clone that I got to build with the various steps i took with the Cargo.lock file, the version of lazy_static that it builds successfully with is 1.4.0 (as reported by cargo tree). I'm not sure sure how this resulted from the steps I took, I wasn't manually editing any configs. Edit: Actually I just remembered, I did prototype some code with lazy_static a while ago, this might explain why this existed in the Cargo.lock. It was sheer coincidence that I had this project open and chose to test with it. |
The commit to replace the css-color-parser dependency has allowed the build to continue further, however this has revealed that lazy_static is causing other areas (namely the use of the cpp_common crate) to fail to compile.
|
It sounds like to me then that your |
If anything it's the reverse, it only compiled with the existing/old Cargo.lock because I had an older version of lazy_static pinned that does compile with the newer version of Rust, and as I said before it successfully builds with lazy_static |
Ahh, I see - sorry, I got it the wrong way around. I see that this is also tracked upstream with rust-lang-nursery/lazy-static.rs#217 |
Note that lazy_static 1.5.0 was released on Jun 21st. Which is after people reported rust-lang-nursery/lazy-static.rs#217 |
That's interesting, my assumption is 1.5 did work at some point, but then was broken by a later rust update. |
Another strange fact is that our CI test several versions of rust (MSRV, stable, beta, nightly) and always use the latest version of all crates (no .lock file). |
This commennt hawkw/sharded-slab#92 (comment) seems to indicate that this might be dependent on some env variable. |
Personally I'm on rust 1.80.0, lazy_static 1.5.0 is broken but not 1.4.0, I haven't got these environment variables set and I have tried clearing my cargo registry. |
With some other research: https://stackoverflow.com/questions/77710297/encountered-e0195-lifetime-parameters-or-bounds-on-type-target-do-not-match Can you look at the file Can you try to clear your cargo registry cache. I have this crazy theory that maybe some tool (eg, a broken cargo fix or clippy fix) could have modified things its not supposed to modify. |
Interesting, for me, it's Edit: Clearing it actually did update that line to |
Following that stackoverflow post, I ran |
I think the error persists because cargo assumes that these directory are never changed and does not invalidate the cache in your target directory. I'm going to close this issue as this is not a Slint issue. Would be interesting to know how this file was changed. As I said, it could be a bug in one of the tools that fixup things that did a fix in a macro where it shouldn't have. (If you ever figure out, let us know 😉) |
Thank you both for your help! I'm very glad that we have a fix documented here now for anyone else who runs into this! |
Steps to recreate:
cargo build
Tested on slint
release/1.7
and on master e0f3fd4Tested with both rust version 1.78 and 1.80
Output log
Thanks for your help!
The text was updated successfully, but these errors were encountered: