Compilation error when trying to use palette

[NeverGivinUp]

When adding any use statement from my local palette crate to my library -- I have not tried using the official version -- I get the following error:

error[E0275]: overflow evaluating the requirement `f64: std::ops::Div<palette::blend::PreAlpha<_>>`
  --> src\text.rs:35:50
   |
35 |         let centering_height_shift = self.height / 2.0;
   |                                                  ^
   |
   = help: consider increasing the recursion limit by adding a `#![recursion_limit = "256"]` attribute to your crate (`web_utils`)
   = note: required because of the requirements on the impl of `std::ops::Div<palette::blend::PreAlpha<palette::blend::PreAlpha<_>>>` for `f64`
   = note: 127 redundant requirements hidden
   = note: required because of the requirements on the impl of `std::ops::Div<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<palette::blend::PreAlpha<_>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>` for `f64`

The error goes away, when I comment out the line impl_scalar_binop!(Div::div, DivAssign::div_assign, [f32, f64]);

I believe is unrelated to my local changes and it certainly is unrelated to the code, where the error occurs. It may be related to a bug in the rust compiler.

[Ogeon]

I had similar errors that came and went away but I don't remember how I fixed it last time.

Which compiler version are you using? Does it change if you switch to another version?

[NeverGivinUp]

I updated to the current nightly during our conversation on the weekend. My code unfortunately requires associated type bounds and does not compile with the stable compiler. How do I use an older nightly compiler?

[Ogeon]

I see, then it's trickier to test with something stable unless it can be minimized into an example without them.

I'm not sure off the top of my head but you may be able to pick the nightly version with rustup.

[NeverGivinUp]

Using an old nightly (in this case the one from 2022-01-01) didn't help. Neither did replacing the division by 2 by a multiplication by 0.5. This was the only line, the compiler didn't like, though. And extreme disambiguation did help

let centering_height_shift = <f64 as Div>::div(self.height, 2.0);

[Ogeon]

What if you write self.height / 2.0f64? Does it still complain?

[Ogeon]

I'm reopening this because there may be something that can mitigate the issue.

[NeverGivinUp]

What if you write self.height / 2.0f64? Does it still complain?

Yes. Also if I create a separate variable with explicit type

let h: f64 = self.height;
h/2.0_f64

Still does not work

[NeverGivinUp]

I'm reopening this because there may be something that can mitigate the issue.

There is an answer in the StackOverflow post, which I originally linked, which seems to contain 2 workarounds. But I didn't read them properly.

[Ogeon]

Ah, so something about how it transforms the division into a function call is getting stuck. It would be nice to have a small test case to keep here and also find out which implementation is the problematic one.

Would you mind sharing the full code or try to reduce it into a minimal test case?

[Ogeon]

I'll have a look at those workarounds later and see if they could help too. Thanks for pointing them out!

[NeverGivinUp]

https://github.com/NeverGivinUp/palette_compilation_rest.git

(was meant to be a compilation test, not a rest)

[Ogeon]

Perfect, thanks! 🙏

[TiemenSch]

This just started hitting my code today. Any multiplication with two f64's trips up one by one. I can't go change all these lines to the <f64 as Mul>::mul(self, rhs) format, since that would be silly. What would you recommend to do?

[Ogeon]

Ouch, sorry about that. You can try to use variables with explicit types to help the compiler, but it's also not ideal. 😕 You could also see if it depends on the compiler version. I didn't get around to figuring out exactly what triggers it before releasing, so I'm sorry for not having better answers right now, but thanks for highlighting that it's still an issue.

[TiemenSch]

For me, it happens in a projects after running a routinely cargo update which made the following results to my Cargo.lock:

    Updating crates.io index
      Adding fast-srgb8 v1.0.0
    Removing find-crate v0.6.3
    Updating getrandom v0.2.8 -> v0.2.9
    Updating palette v0.6.1 -> v0.7.0
    Updating palette_derive v0.6.1 -> v0.7.0
    Updating ratio-color v0.2.0 -> v0.3.0
    Updating serde v1.0.159 -> v1.0.160
    Updating serde_derive v1.0.159 -> v1.0.160
    Updating simba v0.8.0 -> v0.8.1
    Updating syn v2.0.13 -> v2.0.14
    Removing toml v0.5.11
    Updating uuid v1.3.0 -> v1.3.1

Where ratio-coloris my quickly made palette library depending on palette. The error is exactly the one given regarding the recursion limit suggestion and PreAlpha.

The first offending line in my code is a const multiplication of:

pub const DOUBLE_PI: f64 = 2.0_f64 * std::f64::consts::PI; 

But as soon as I patch that, all f64 multiplications inside function bodies get marked, probably because of the order in which things are compiled.

[TiemenSch]

It's rather uncommon for a library to touch the functionalities of others (or std in that matter), which makes it a rather strange error that should have been prohibited by the orphan rule usually?

[Ogeon]

Indeed, there's no obvious reason why it would be bothered by PreAlpha, unless it tries to somehow evaluate it as a possible candidate in the multiplication. That's what makes your case especially strange.

Do you think it would be possible to make a minimal example of when it fails? It could be cross referenced with the one above to see if there's any pattern.

Also, which compiler version are you using?

[Azorlogh]

I am able to reproduce this the following way:

[package]
name = "bug_palette"
version = "0.1.0"
edition = "2021"

[dependencies]
scad = "1.2.2"
palette = "0.7.0"

// main.rs
use palette::Oklch;
use scad::OffsetType;

fn main() {
    println!("{}", 42.0 * 1.0); // bug also happens when specifying f32 or f64
}

error[E0275]: overflow evaluating the requirement `f32: Mul<PreAlpha<_>>`
 --> src/main.rs:5:25
  |
5 |     println!("{}", 42.0 * 1.0);
  |                         ^
  |
  = help: consider increasing the recursion limit by adding a `#![recursion_limit = "256"]` attribute to your crate (`repro`)
  = note: required for `f32` to implement `Mul<PreAlpha<PreAlpha<_>>>`
  = note: 127 redundant requirements hidden
  = note: required for `f32` to implement `Mul<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<PreAlpha<_>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>`

I'm on latest stable:

stable-x86_64-unknown-linux-gnu (default)
rustc 1.68.2 (9eb3afe9e 2023-03-27)

[Ogeon]

Great, thanks! From this it pretty much looks like it's getting stuck while considering PreAlpha as a possible right-hand-side type. I'm not sure how to stop it, other than deleting the implementation of Mul<PreAlpha<T>> for f32 and so on, but that's the difference I can see from for example Alpha, which hasn't been showing this behavior. I see that there's a lot of bug reports for rustc with similar cases (but not exactly the same in the ones I have checked), so that may be the way to go in the end.

I will give it a proper try this weekend (or tomorrow if I have time)

[Ogeon]

By the way @Azorlogh, does it still fail when removing the scad dependency? It shouldn't be related but I'm curious to see how spooky this issue is.

[Azorlogh]

The issue is quite spooky indeed. Removing any of the use statements makes my example compile fine.
scad::OffsetType itself is just a pretty trivial enum.

[Ogeon]

Definitely spooky but the spookiness also makes it harder to set up a reliable test case for regression. 🤔

[Ogeon]

I found this, that seem to be pretty much the same case: https://github.com/rust-lang/rust/issues/80542

[Ogeon]

I created PR #312 to try to work around this. It works for the example from @Azorlogh, but let me know if it still fails in any other cases. You should be able to change your palette dependency to this to give it a try before it's merged:

[dependencies]
palette = { git = "https://github.com/Ogeon/palette.git", branch = "work_around_issue_283" }

[Ogeon]

The fix has been released in 0.7.1. Feel free to reopen this issue if it appears again.

[Strosel]

This seems to be an issue once again, but now for IntoIterator. My code does not depend on palette directly but yields the following error with no source location:

error[E0275]: overflow evaluating the requirement `&_: IntoIterator`
  |
  = help: consider increasing the recursion limit by adding a `#![recursion_limit = "256"]` attribute to your crate (`...`)
  = note: required for `&palette::lch::Lch<_, _>` to implement `IntoIterator`
  = note: 126 redundant requirements hidden
  = note: required for `&Lch<_, Lch<_, Lch<_, Lch<_, Lch<_, Lch<_, Lch<_, ...>>>>>>>` to implement `IntoIterator`

The specific type varies between compilations, seemingly by random, but so far I've seen OkLabHue, LuvHue, Lch, Rgb, and Luma.

I've tried both cargo clean and building with -Znext-solver but neither works. I've also cloned the repo of the direct dependent on palette which does not yield the error on cargo check or cargo test. I'm at a complete loss as to what is causing the error so any and all help is greatly appreciated.

I'm running the latest stable:

$ rustc -vV
  rustc 1.76.0 (07dca489a 2024-02-04)
  binary: rustc
  commit-hash: 07dca489ac2d933c78d3c5158e3f43beefeb02ce
  commit-date: 2024-02-04
  host: aarch64-apple-darwin
  release: 1.76.0
  LLVM version: 17.0.6

[Ogeon]

Oh, no. 😬 Do you think you could provide a minimal example that reproduces it? I have some idea of where it may be from, but it helps to have an example for testing.

[Strosel]

A minimal example might be quite difficult as the application I'm working on is a decently large GUI using iced (which is the direct dependent of palette)

If you still would like to have a look I could push the current state of my repo to a new branch and send you a link in a couple of hours.

[Ogeon]

That would also be helpful, thanks. Do you know if the problem started after any particular change?

[Strosel]

The problem started when updating to the latest version of iced, I fear that it may be some other bug that causes this and makes the compile go a little haywire.

I committed my working changes here https://github.com/Smalands-Nation/register-rs/tree/iced_migration_palette_bug