chore: rust-analyzer: refactor notification handlers
Fixes the FIXME in `on_notification`.
```rust
// FIXME: Move these implementations out into a module similar to on_request
```
No code has changed, this just moves stuff around.
MIR episode 4
In lowering, it now supports overloaded and arith assignment binary operators, statics. and constants in patterns. There is now 252 functions that we fail to emit mir for them, and the majority of them are due type mismatches or other deep and unrelated issues (but it isn't done yet, for example slice patterns and destructing assignment is not implemented yet).
In evaluating, it now can evaluate associated constants in traits (so now typenum's `U5::ToConst` should work), allocator functions, atomic intrinsics, and some more things. It also provides a (hacky) basis for making progress in #14275. I also added a `Interpret` code lens to `Run` and `Debug` when the experimental `interpret tests` is enabled (previously it showed result in hover, which was unusable even for debugging)
Changes in unrelated files are:
* Changes substitutions of closures, now it includes parent substs ~~before~~ after `sig_ty`.
* ~~A salsa input for retrieving the path of a file id, used in emitting stack trace for interpret result.~~
* Normalizing associated types in layout computing
Deduplicate crates when extending crate graphs
This is quadratic in runtime per deduplication attempt, but I don't think that'll be a problem for the workload here. Don't be scared of the diff, the actual diff is +42 -22, the rest is tests and test data.
Fixes https://github.com/rust-lang/rust-analyzer/issues/14476
Remove proc-macro server command from the rust-analyzer binary
We dropped support for concrete proc-macro abi versions so this no longer serves any purposes.
Revert "Handle dev-dependency cycles"
Reverts rust-lang/rust-analyzer#14475
I managed to fix the problem that causes the metric failures, but this still severely degrades IDE features in a way that makes the user experience ***worse*** than before. I am not sure how to address this, I wonder what the jetbrains plugin is doing in these cases.
Handle dev-dependency cycles
cc https://github.com/rust-lang/rust-analyzer/issues/14167
This should fix cycles errors mostly (it fixes the one on rome/tools at least, but not on rustc. Though there it might just be because of rustc workspace being rustc workspace). Unfortunately this will effectively duplicate all crates currently, since if we want to be completely correct we'd need to set the test cfg for all dev dependencies and the transitive dependencies of those, something I worry we should try to avoid.
fix: Fix pat fragment handling in 2021 edition
Fixes https://github.com/rust-lang/rust-analyzer/issues/9055
The fix isn't that great, but we are kind of forced to do it the quick and hacky way right now since std has changed the `matches` macro to make use of this now. And for a proper fix we need to track hygiene for identifiers which is a long way off anyways
Register obligations during path inference
Fixes#14635
When we infer path expressions that resolve to some generic item, we need to consider their generic bounds. For example, when we resolve a path `Into::into` to `fn into<?0, ?1>` (note that `?0` is the self type of trait ref), we should register an obligation `?0: Into<?1>` or else their relationship would be lost.
Relevant part in rustc is [`add_required_obligations_with_code()`] that's called in [`instantiate_value_path()`].
[`instantiate_value_path()`]: 3462f79e94/compiler/rustc_hir_typeck/src/fn_ctxt/_impl.rs (L1052)
[`add_required_obligations_with_code()`]: 3462f79e94/compiler/rustc_hir_typeck/src/fn_ctxt/_impl.rs (L1411)
Specify `--pre-release` when publishing vsce nightly
According to https://code.visualstudio.com/api/working-with-extensions/publishing-extension#prerelease-extensions, when publishing pre-release versions, `--pre-release` must also be passed in the publish step.
Currently the behavior with and without the flag seems to be the same, but since it's documented to be required, don't rely on this staying that way.
This flag was previously removed in #13020, so this partially reverts that change.
