Aleksey Kladov [Sun, 13 Jun 2021 11:41:19 +0000 (14:41 +0300)]
internal: start new diagnostics API
At the moment, this moves only a single diagnostic, but the idea is
reafactor the rest to use the same pattern. We are going to have a
single file per diagnostic. This file will define diagnostics code,
rendering range and fixes, if any. It'll also have all of the tests.
This is similar to how we deal with assists.
After we refactor all diagnostics to follow this pattern, we'll probably
move them to a new `ide_diagnostics` crate.
Not that we intentionally want to test all diagnostics on this layer,
despite the fact that they are generally emitted in the guts on the
compiler. Diagnostics care to much about the end presentation
details/fixes to be worth-while "unit" testing. So, we'll unit-test only
the primary output of compilation process (types and name res tables),
and will use integrated UI tests for diagnostics.
bors[bot] [Fri, 11 Jun 2021 22:00:23 +0000 (22:00 +0000)]
Merge #9204
9204: feat: more accurate memory usage info on glibc Linux r=jonas-schievink a=jonas-schievink
This adds support for the new `mallinfo2` API added in glibc 2.33. It addresses a shortcoming in the `mallinfo` API where it was unable to handle memory usage of more than 2 GB, which we sometimes exceed.
Blocked on https://github.com/rust-lang/libc/pull/2228
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
bors[bot] [Fri, 11 Jun 2021 10:44:07 +0000 (10:44 +0000)]
Merge #9192
9192: internal: Build test-macros in a build script r=jonas-schievink a=jonas-schievink
This build the test-proc-macros in `proc_macro_test` in a build script, and copies the artifact to `OUT_DIR`. This should make it available throughout all of rust-analyzer at no cost other than depending on `proc_macro_test`, fixing https://github.com/rust-analyzer/rust-analyzer/issues/9067.
This hopefully will let us later write inline tests that utilize proc macros, which makes my life fixing proc macro bugs easier.
Opening this as a sort of RFC, because I'm not totally sure this approach is the best.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
bors[bot] [Fri, 11 Jun 2021 06:28:32 +0000 (06:28 +0000)]
Merge #9208
9208: minor: Populate import maps eagerly to speed up flyimports r=SomeoneToIgnore a=SomeoneToIgnore
Part of #7542
Follow up of https://github.com/rust-analyzer/rust-analyzer/pull/9206#issuecomment-859097783
Reduces `import_on_the_fly @ sel` case in the `integrated_completion_benchmark` by ~300ms.
Also enables cache priming for manual workspace loading to reflect the results in the benchmarks.
bors[bot] [Thu, 10 Jun 2021 21:28:14 +0000 (21:28 +0000)]
Merge #9206
9206: minor: Speed up fst items lookup during completions r=SomeoneToIgnore a=SomeoneToIgnore
Part of https://github.com/rust-analyzer/rust-analyzer/issues/7542
A number of profile calls added for `import_on_the_fly` contents.
Before:
<img width="606" alt="Screenshot 2021-06-11 at 00 19 13" src="https://user-images.githubusercontent.com/2690773/121598998-22321e80-ca4b-11eb-9a3d-dc9cb2936705.png">
After:
<img width="859" alt="Screenshot 2021-06-11 at 00 19 27" src="https://user-images.githubusercontent.com/2690773/121599022-2a8a5980-ca4b-11eb-82b6-13ab0ed56d58.png">
As a result, low hanging fruit was spotted: crazy amount of `fst_path` calls. Reducing that won ~200ms in the `import_on_the_fly @ sel` case in the `integrated_completion_benchmark`:
<img width="861" alt="Screenshot 2021-06-11 at 00 19 38" src="https://user-images.githubusercontent.com/2690773/121599277-7d641100-ca4b-11eb-8667-53206994de27.png">
I'm not sure how to proceed with the remaining `???` marks in such methods as `collect_import_map` though: there's nothing but library calls in cycles, but maybe I'll come up with something later.
bors[bot] [Thu, 10 Jun 2021 12:09:54 +0000 (12:09 +0000)]
Merge #9202
9202: feat: Make `MemoryUsage` work on Windows r=jonas-schievink a=jonas-schievink
Unfortunately there is no convenient API for heap statistics, so this instead uses the Commit Charge value, which is the amount of memory that needs to be allocated either in physical RAM or in the page file. This approximation seems to be good enough to find queries that waste a large amount of memory, but it should generally be expected to be off by several MB.
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
bors[bot] [Tue, 8 Jun 2021 19:01:23 +0000 (19:01 +0000)]
Merge #9180
9180: fix: fix some IDE functionality inside attribute macros r=jonas-schievink a=jonas-schievink
In `SourceToDefCtx::find_container`, we might encounter a container that has an attribute macro. We need to skip that item, instead of bailing out and creating an empty `Resolver`, otherwise all names in the macro stay unresolved.
Part of https://github.com/rust-analyzer/rust-analyzer/issues/9142
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>