fix: more precise binop inference
While inferring binary operator expressions, Rust puts some extra constraints on the types of the operands for better inference. Relevant part in rustc is [this](159ba8a92c/compiler/rustc_hir_typeck/src/op.rs (L128-L152)).
There are two things we currently fail to consider:
- we should enforce them only when both lhs and rhs type are builtin types that are applicable to the binop
- lhs and rhs types may be single reference to applicable builtin types
This PR basically ports [`enforce_builtin_binop_types()`](159ba8a92c/compiler/rustc_hir_typeck/src/op.rs (L159)) and [`is_builtin_binop()`](159ba8a92c/compiler/rustc_hir_typeck/src/op.rs (LL927)) to our inference context.
Assist: desugar doc-comment
My need for this arose due to wanting to do feature dependent documentation and therefor convert parts of my doc-comments to attributes.
Not sure about the pub-making of the other handlers functions, but I didn't think it made much sense to reimplement them.
Unconditionally enable location links in inlay hints again
While the goto functionality still doesn't work in VSCode, the hover part actually does. Also the way this was gated before, one only had to update their config while r-a was running to have the links enabled automatically due to the check only living in the startup code.
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.
Fix aarch64-unknown-linux-gnu_ilp32 target
This was broken because the synthetic object files produced by rustc were for 64-bit AArch64, which caused link failures when combined with 32-bit ILP32 object files.
This PR updates the object crate to 0.30.1 which adds support for generating ILP32 AArch64 object files.
Update mdbook
This updates mdbook from 0.4.21 to 0.4.25. The list of changes is [here](https://github.com/rust-lang/mdBook/blob/master/CHANGELOG.md#mdbook-0425). The only user-visible changes are some changes around the theme picker, and change to the copy-to-clipboard ignoring hidden lines.
Internally there were some dependency updates and small fixes.
This also updates `clap` from 4.0.15 to 4.0.32 whose changelog is [here](https://github.com/clap-rs/clap/blob/master/CHANGELOG.md#4032---2022-12-22). This impacts tools like cargo. I don't see anything particularly noteworthy there, though there are some small user-visible changes.
Unfortunately this required adding a hack for building `rustix` with a bootstrap tool. The comment explains why. I am unable to think of some other workaround (or even a cleaner way to set the rustflag). Ideas are welcome if you can think of alternatives. I'm struggling to even think of a long-term solution, other than asking projects not to do auto-nightly feature detection.
One medium-term solution is to avoid the clap dependency for the mdbook library (which is how rustix gets pulled in). That is one of my goals for the 0.5 release of mdbook, but that probably won't happen until later this year. It would also require dropping clap from `rustbook` and using some other means to parse arguments (there's only two options, so it can probably be done manually).
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
