Remove the toggleInlayHints command from VSCode
Inlay hints are no longer something specifc to r-a as it has been upstreamed into the LSP, we don't have a reason to give the config for this feature special treatment in regards to toggling. There are plenty of other options out there in the VSCode marketplace to create toggle commands/hotkeys for configurations in general which I believe we should nudge people towards instead.
fix: handle trait methods as inherent methods for trait-related types
Fixes#10677
When resolving methods for trait object types and placeholder types that are bounded by traits, we need to count the methods of the trait and its super traits as inherent methods. This matters because these trait methods have higher priority than the other traits' methods.
Relevant code in rustc: [`assemble_inherent_candidates_from_object()`](0631ea5d73/compiler/rustc_typeck/src/check/method/probe.rs (L783-L792)) for trait object types, [`assemble_inherent_candidates_from_param()`](0631ea5d73/compiler/rustc_typeck/src/check/method/probe.rs (L838-L847)) for placeholder types. Notice the second arg of `push_candidate()` is `is_inherent`.
Remove redundant 'resolve_obligations_as_possible' call
Hi! I was looking for a "good first issue" and saw this one: https://github.com/rust-lang/rust-analyzer/issues/7542. I like searching for performance improvements, so I wanted to try to find something useful there.
There are two tests in integrated_benchmarks.rs, I looked at 'integrated_highlighting_benchmark' (not the one discussed in the issue above).
Profile from that test looks like this:
```
$ RUN_SLOW_BENCHES=1 cargo test --release --package rust-analyzer --lib -- integrated_benchmarks::integrated_highlighting_benchmark --exact --nocapture
Finished release [optimized] target(s) in 0.06s
Running unittests src/lib.rs (target/release/deps/rust_analyzer-a80ca6bb8f877458)
running 1 test
workspace loading: 358.45ms
initial: 9.60s
change: 13.96µs
cpu profiling is disabled, uncomment `default = [ "cpu_profiler" ]` in Cargo.toml to enable.
273ms - highlight
143ms - infer:wait @ per_query_memory_usage
143ms - infer_query
0 - crate_def_map:wait (3165 calls)
4ms - deref_by_trait (967 calls)
96ms - resolve_obligations_as_possible (22106 calls)
0 - trait_solve::wait (2068 calls)
21ms - Semantics::analyze_impl (18 calls)
0 - SourceBinder::to_module_def (20 calls)
36ms - classify_name (19 calls)
19ms - classify_name_ref (308 calls)
0 - crate_def_map:wait (461 calls)
4ms - descend_into_macros (628 calls)
0 - generic_params_query (4 calls)
0 - impl_data_with_diagnostics_query (1 calls)
45ms - infer:wait (37 calls)
0 - resolve_obligations_as_possible (2 calls)
0 - source_file_to_def (1 calls)
0 - trait_solve::wait (42 calls)
after change: 275.23ms
test integrated_benchmarks::integrated_highlighting_benchmark ... ok
```
22106 calls to `resolve_obligations_as_possible` seem like the main issue there.
One thing I noticed (and fixed in this PR) is that `InferenceContext::resolve_ty_shallow` first calls `resolve_obligations_as_possible`, and then calls `InferenceTable::resolve_ty_shallow`. But `InferenceTable::resolve_ty_shallow` [inside](2e9f1204ca/crates/hir-ty/src/infer/unify.rs (L372)) again calls `resolve_obligations_as_possible`.
`resolve_obligations_as_possible` inside has a while loop, which works until it can't find any helpful information. So calling this function for the second time does nothing, so one of the calls could be safely removed.
`InferenceContext::resolve_ty_shallow` is actually quite a hot place, and after fixing it, the total number of `resolve_obligations_as_possible` in this test is reduced to 15516 (from 22106). "After change" time also improves from ~270ms to ~240ms, which is not a very huge win, but still something measurable.
Same profile after PR:
```
$ RUN_SLOW_BENCHES=1 cargo test --release --package rust-analyzer --lib -- integrated_benchmarks::integrated_highlighting_benchmark --exact --nocapture
Finished release [optimized] target(s) in 0.06s
Running unittests src/lib.rs (target/release/deps/rust_analyzer-a80ca6bb8f877458)
running 1 test
workspace loading: 339.86ms
initial: 9.28s
change: 10.69µs
cpu profiling is disabled, uncomment `default = [ "cpu_profiler" ]` in Cargo.toml to enable.
236ms - highlight
110ms - infer:wait @ per_query_memory_usage
110ms - infer_query
0 - crate_def_map:wait (3165 calls)
4ms - deref_by_trait (967 calls)
64ms - resolve_obligations_as_possible (15516 calls)
0 - trait_solve::wait (2068 calls)
21ms - Semantics::analyze_impl (18 calls)
0 - SourceBinder::to_module_def (20 calls)
34ms - classify_name (19 calls)
18ms - classify_name_ref (308 calls)
0 - crate_def_map:wait (461 calls)
3ms - descend_into_macros (628 calls)
0 - generic_params_query (4 calls)
0 - impl_data_with_diagnostics_query (1 calls)
45ms - infer:wait (37 calls)
0 - resolve_obligations_as_possible (2 calls)
0 - source_file_to_def (1 calls)
0 - trait_solve::wait (42 calls)
after change: 238.15ms
test integrated_benchmarks::integrated_highlighting_benchmark ... ok
```
The performance of this test could be further improved but at the cost of making code more complicated, so I wanted to check if such a change is desirable before sending another PR.
`resolve_obligations_as_possible` is actually called a lot of times even when no new information was provided. As I understand, `resolve_obligations_as_possible` could do something useful only if some variables/values were unified since the last check. We can store a boolean variable inside `InferenceTable`, which indicates if `try_unify` was called after last `resolve_obligations_as_possible`. If it wasn't called, we can safely not call `resolve_obligations_as_possible` again.
I tested this change locally, and it reduces the number of `resolve_obligations_as_possible` to several thousand (it is not shown in the profile anymore, so don't know the exact number), and the total time is reduced to ~180ms. Here is a generated profile:
```
$ RUN_SLOW_BENCHES=1 cargo test --release --package rust-analyzer --lib -- integrated_benchmarks::integrated_highlighting_benchmark --exact --nocapture
Finished release [optimized] target(s) in 0.06s
Running unittests src/lib.rs (target/release/deps/rust_analyzer-a80ca6bb8f877458)
running 1 test
workspace loading: 349.92ms
initial: 8.56s
change: 11.32µs
cpu profiling is disabled, uncomment `default = [ "cpu_profiler" ]` in Cargo.toml to enable.
175ms - highlight
21ms - Semantics::analyze_impl (18 calls)
0 - SourceBinder::to_module_def (20 calls)
33ms - classify_name (19 calls)
17ms - classify_name_ref (308 calls)
0 - crate_def_map:wait (461 calls)
3ms - descend_into_macros (628 calls)
0 - generic_params_query (4 calls)
0 - impl_data_with_diagnostics_query (1 calls)
97ms - infer:wait (38 calls)
0 - resolve_obligations_as_possible (2 calls)
0 - source_file_to_def (1 calls)
0 - trait_solve::wait (42 calls)
after change: 177.04ms
test integrated_benchmarks::integrated_highlighting_benchmark ... ok
```
Let me know if adding a new bool field seems like a reasonable tradeoff, so I can send a PR.
Previously, annotations would only appear above the name of an item (function signature, struct declaration, etc).
Now, rust-analyzer can be configured to show annotations either above the name or above the whole item (including doc comments and attributes).
Build release artifact against older Glibc
When GitHub [deprecated Ubuntu 18.04](https://github.blog/changelog/2022-08-09-github-actions-the-ubuntu-18-04-actions-runner-image-is-being-deprecated-and-will-be-removed-by-12-1-22/) runners, rust-analyzer was forced to bump runners to 20.04 which includes an updated Glib. This renders RA incompatible with the still popular Ubuntu 18.04 and other slightly older distro versions.
Until a deprecation plan is announced on RA's side, I propose binaries shall be built against older glibc to maintain compatibility.
This PR changes the Release CI workflow to build the `linux-x64/x86_64-unknown-linux-gnu` release in an Ubuntu 18.04 container.
Fixes#13081 and #13085
The name might need some improving.
extract format_like's parser to it's own module in ide-db
reworked the parser's API to be more direct
added assist to extract expressions in format args
Inlay hints are no longer something specifc to r-a as it has been
upstreamed into the LSP, we don't have a reason to give the config
for this feature special treatment in regards to toggling. There are
plenty of other options out there in the VSCode marketplace to create
toggle commands/hotkeys for configurations in general which I believe
we should nudge people towards instead.
Use proc-macro-srv from sysroot in rust-project.json workspaces
This was discussed [on zulip](https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer/topic/.60sysroot.60.20vs.20.60sysroot_src.60.20for.20.60rust-project.2Ejson.60.3F/near/293023920), basically in `rust-project.json` workspaces RA doesn't respect the `sysroot` setting when picking which `proc-macro-srv` to launch, and this causes abi mismatches in practice.
This is the simple fix that `@Veykril` suggested, and I've verified that it works on Fuchsia by inspecting the cmdline with `pgrep rust-analyzer | xargs ps -fp` to check that it's using the `proc-macro-srv` from our prebuilts which matches the `sysroot` specified in our `rust-project.json`.
Can this be merged as is, or do we need to add tests that exercise this?
fix: sort all bounds on trait object types
Fixes#13181#12793 allowed different ordering of trait bounds in trait object types but failed to account for the ordering of projection bounds. I opted for sorting all the bounds at once rather than splitting them into `SmallVec`s so it's easier to do the same thing for other bounds when we have them.
fix: Insert whitespaces into static & const bodies if they are expanded from macro on hover
Partially fixes#13143.
To resolve the other part we need to expand macros in unevaluated static & const bodies, and I'm not sure we want to. If for example it includes a call to `assert!()`, expanding it will lead to worse hover.
fix: correct broken logic for return complition
It seems that we've accidentally deleted the tests here couple of years
ago, and then fairly recently made a typo during refactor as well.
Reinstall tests, with coverage marks this time :-)
It seems that we've accidentally deleted the tests here couple of years
ago, and then fairly recently made a typo during refactor as well.
Reinstall tests, with coverage marks this time :-)
