intellij-rust: false positives when detecting errors in editor

It was difficult, but I solved this riddle! The bug was introduced in #9229 (included into 0.4.179 release). I’m fixing it in #9461 that will likely be included into 0.4.180 (will be released next Monday).

Technical explanation: CargoBasedCrate had identity-based equals/hashCode (looking ahead, this led to the bug). CrateGraphServiceImpl.crateGraph is stored under a CachedValue that stores a cached value indirectly under SoftReference (“indirectly” means SoftReference -> SomeWrapper -> CrateGraph), so Java GC can collect SomeWrapper anytime, that means invalidation of the the crateGraph cached value (and its re-calculation during a next access). Hence it’s possible that at some point we have multiple CargoBasedCrate instances referring to the “same” crate. Crate.hasTransitiveDependencyOrSelf(Crate) (introduced in #9229) uses CargoBasedCrate.equals/hashCode in order to check if a crate is a dependency of another crate. The combination of these nuances has led to the fact that in some circumstances Crate.hasTransitiveDependencyOrSelf(Crate) could wrongly return false, that turns the #9229 filtering mechanism against valid impls (like impl Copy for primitives), that in turn leads to observable false-positives

The issue is fixed in the nightly plugin. You can try it now (see instructions)

Thank everyone for participating!

So far I haven’t seen the problem since I reverted to Rust 0.4.178.4873-222, so I would say it’s a good work around.

I think those type-related optimizations above may have broken something in the trait system in version 0.4.179. It seems unable to see what traits are supported by a type.

Procedure:

• Visit this page and download the appropriate 0.4.178 version depending on your IntelliJ version: https://plugins.jetbrains.com/plugin/8182-rust/versions/stable
• Open the settings and the plugin section.
• Click on the setting cog wheel at the top, NOT the one in the plugin information area (see below).
• Select Install Plugin from disk.

No need to uninstall it first. Maybe a Restart & Invalidate Caches may be safer, though I didn’t need to do it.

It was difficult, but I solved this riddle! The bug was introduced in #9229 (included into 0.4.179 release). I’m fixing it in #9461 that will likely be included into 0.4.180 (will be released next Monday).

Technical explanation: CargoBasedCrate had identity-based equals/hashCode (looking ahead, this led to the bug). CrateGraphServiceImpl.crateGraph is stored under a CachedValue that stores a cached value indirectly under SoftReference (“indirectly” means SoftReference -> SomeWrapper -> CrateGraph), so Java GC can collect SomeWrapper anytime, that means invalidation of the the crateGraph cached value (and its re-calculation during a next access). Hence it’s possible that at some point we have multiple CargoBasedCrate instances referring to the “same” crate. Crate.hasTransitiveDependencyOrSelf(Crate) (introduced in #9229) uses CargoBasedCrate.equals/hashCode in order to check if a crate is a dependency of another crate. The combination of these nuances has led to the fact that in some circumstances Crate.hasTransitiveDependencyOrSelf(Crate) could wrongly return false that turns the #9229 filtering mechanism against valid impls (like impl Copy for primitives) that in turn leads to observable false-positives

Remarkable! Great work!

@blueglyph you can do it via https://uploads.jetbrains.com not to make them publicly available