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.
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
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 :-)
Lift out the module scope into a field in the Resolver
A Resolver *always* has a module scope at the end of its scope stack,
instead of encoding this as an invariant we can just lift this scope
out into a field, allowing us to skip going through the scope vec
indirection entirely.
A Resolver *always* has a module scope at the end of its scope stack,
instead of encoding this as an invariant we can just lift this scope
out into a field, allowing us to skip going through the scope vec
indirection entirely.
feat: Implement `feature(exhaustive_patterns)` from unstable Rust
Closes#12753
Recognize Rust's unstable `#![feature(exhaustive_patterns)]` (RFC 1872). Allow omitting visibly uninhabited variants from `match` expressions when the feature is on.
This adjusts match checking to the current implementation of the postponed RFC 1872 in rustc.
fix: Parse TypePathFn with preceding `::`
e.g. `impl Fn::() -> ()`.
Fixes#13157. This was the problem, not that the path was not at the end.
I could unify the parsing of `::` of TypePathFn with that of generic arg list, but some code relies on the `::` of generic arg list to be inside it.
fix: Lower float literals with underscores
Fixes#13155 (the problem was the `PI` is defined with `_f64` suffix). `PI` is still truncated, though, because `f64` cannot represent the value with full precision.
