fix: don't generate `PartialEq`/`PartialOrd` methods body for types don't match
Fixes#12985
This PR changes the implementation of well-known trait methods body generation so that it takes generic arguments of traits into account and does not generate `PartialEq`/`PartialOrd` methods body when the self type and rhs type don't match.
I took this opportunity to add `hir::TraitRef`, which has been suggested by a FIXME note. I didn't change the signature of the existing method `hir::Impl::trait_(self, db) -> Option<Trait>` as suggested by FIXME but added a new method because you quite often only want to know the trait rather than `TraitRef`s.
Update command-group from 1.0.8 to 2.0.1
With #13552 the depencency of on the command-group crate was introduced, which also introduced a dependency on nix. That version of nix does not build on Haiku. This change introduces a newer version of command-group, which also updates nix from 0.22.3 to 0.26.1, which is compatible on Haiku.
With #13552 the depencency of on the command-group crate was introduced, which also
introduced a dependency on nix. That version of nix does not build on Haiku. This
change introduces a newer version of command-group, which also updates nix from
0.22.3 to 0.26.1, which is compatible on Haiku.
Remove hover inlay tooltips, replace them with location links
Turns out we re-implemented what clients can already figure out through the use of location-links. We might want lazy resolves tooltips later on still, but for now this simplifies things again.
remove recursive 'Display' implementations
closes#13920
`@lnicola` is this the solution you were looking for?
having explicitly unimplemented methods seems preferable to apparently implemented methods that can't be called
Fix panicking Option unwraping in match arm analysis
Hi, first PR here!
I've noticed my IDE sometimes briefly becoming pretty slow to respond while writing Rust. When checking the logs I found reams of this same error repeating itself.
```
thread 'Worker' panicked at 'called `Option::unwrap()` on a `None` value'
crates/ide-assists/src/handlers/convert_match_to_let_else.rs:90:46
```
RA seemed to have been panicking on virtually every keystroke I made whenever I was part way through writing/refactoring a match statement of relevance to this assist.
The fix in this PR should be self-explanatory.
interior-mutable types should be 'static' rather than 'const
with the 'tracking' feature enabled, `limit::Limit` is interior mutable, so the `const` `hir_def::nameres::mod_resolution::MOD_DEPTH_LIMIT` is probably meant to be `static` rather than `const`.
with `const` you get a new copy of it everywhere it's used, instead of the shared, global value that seems to be the intent.
This fix brought to you by the catchily-named `clippy::declare_interior_mutable_const` lint.
Refine search for const and function assoc items
This changes our searching behavior, before we always associated all usages and definitions of associated items with all implementations of a trait and the trait itself. Now, when searching for references of a an associated trait item, we still do the same and consider all implementations, but when searching for an associated item of an implementation we now only consider the uses of that specific implementations associated item.
This does not affect associated type aliases as we unfortunately are missing information in the IDE layer here still.
