Doc-tests trigger ICE on current nightly

[Tehforsch]

thread 'rustc' panicked at compiler/rustc_hir_analysis/src/collect/predicates_of.rs:400:60:
DefId::expect_local: `DefId(20:172 ~ diman[a908]::si::dimensions::Length::{constant#0})` isn't local

rustc version: rustc 1.86.0-nightly (99768c80a 2025-01-23)

Without any further insight, I'd guess that this is related to https://github.com/rust-lang/rust/issues/133808

[jedbrown]

I just wanted to share this update from the const generics group lead:

In general though I would highly recommend migrating off of GCE and that nobody should be using GCE in an established codebase. It is not fit for usage outside of small examples. In general using nightly features is prone to exactly these kind of "rock and a hard place" issues especially when the feature you're relying on is marked incomplete https://github.com/rust-lang/rust/issues/133808#issuecomment-3009125434

That's always been the rule about nightly features, but is seems GCE is especially unstable. Have you thought about how close one could get to Diman without GCE?

[Tehforsch]

Thanks for the comment. I initially wrote diman under the assumption that GCE would be stabilized "some time soon", knowing that it might take a long time, but without any estimate for how long it would really be. Judging by these comments it seems like it might be a very long time indeed.

Unfortunately I think the main advantage that diman has is in its relatively clear error messages on dimension mismatches and these are due to dimans use of const generics. I am not aware of a way to continue using const generics for the dimension checks without also relying on GCE (although I'd be very happy if there was one).

I had briefly considered some sort of hybrid approach where we use the "classical" typenum-based approach to do the actual dimension checking but implicitly convert into another type that uses const generics and somehow "force" the compiler to use the latter during generation of error messages. The main problem here is that I have no idea something like this could even be done, let alone how and that it would add a ton of complexity to the codebase, even if it worked. This might be worth investigating in a PoC (doing it directly in the diman codebase is sort of ... unthinkable at this point).

Another thing that I have thought about that would definitely be possible and that I'd like to investigate is to do both: One implementation using const generics (which relies on GCE) and one implementation using typenum. The idea would be to make the implementation toggleable via a feature flag (e.g. unstable). If compiled without unstable, diman would generate code using the typenum approach which would be compileable on stable rust. Generated error messages would be cryptic, but it would work. The user could then choose to briefly use unstable to switch the implementation to const generics and get better error messages but wouldn't be stuck with any of the "baggage" that unstable features come with (such as running into ICEs for slightly malformed code ...). This way, we'd maintain the option to "easily" switch to defaulting to the const-generics approach once the feature becomes stabilized. The main problems I see with this approach are 1. code complexity and 2. diman using its unique selling point. I feel like trying to become another library that "simply" uses typenum to do dimension checking is superfluous since uom already exists and has more users and features. I am not sure that there are many users out there who would be willing to use a more experimental library in order to have the option to have better error messages at some undefined point in the future.

So these are my initial thoughts on this, let me know what you think. I am definitely curious about trying these approaches (although I am quite pessimistic about #1 working).