internal: Remove hover fallback in favor of ranged hover
The fallback is usually more annoying than useful at this point (it messes with the range of diagnostic popups a lot), we now have a ranged hover to check the type of something which works a lot better.
Closes https://github.com/rust-lang/rust-analyzer/issues/11602
Don't respond with a ContentModified while loading the workspace
Initially this was done to prevent frequent inlay hint flickering, but this causes a lot of problems for a bunch of clients. We can (and already kind of have) move this into the semantic token request handlers instead.
Fixes https://github.com/rust-lang/rust-analyzer/issues/10910
Don't run flycheck on startup unless checkOnSave is enabled
The main reason people disable it is because they don't want the expensive checks to occur automatically, so we shouldn't trigger them at the start up either if this is disabled.
Fix checkOnSave to check config patching not always working
This early return was missed in the initial PR, so if we aren't patching the `completion_addCallArgumentSnippets` `completion_addCallParenthesis` configs we won't be patching the checkOnSave ones...
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.
