I'd prefer getting rid of it, but it's used in the impl search and not
super easy to replace there (I think ideally the impl search would do
proper unification, but that's a bit more complicated).
8402: Remove Ty::substs{_mut} r=flodiebold a=flodiebold
Almost all uses actually only care about ADT substs, so it's better to be explicit. The methods were a bad abstraction anyway since they already didn't include the inner types of e.g. `TyKind::Ref` anymore.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
Almost all uses actually only care about ADT substs, so it's better to
be explicit. The methods were a bad abstraction anyway since they
already didn't include the inner types of e.g. `TyKind::Ref` anymore.
8397: Return proper error code when server is loading r=matklad a=ceronman
When requests are made to rust-analyzer and the server is still loading, a response error is returned with the code `ContentModified` and text `"Rust Analyzer is still loading..."`. This error code doesn't seem to be the more appropriate for this situation. Using `ServerNotInitialized` seems better.
As this is such a small change, I have not created an issue for it.
Co-authored-by: Manuel Ceron <manuel.ceron@jetbrains.com>
8392: Add space after lifetime in expand macro r=edwin0cheng a=sharksforarms
When a lifetime is followed by an ident, this lead to invalid syntax. This adds a whitespace between the lifetime and the identifier.
Noticed this here: https://github.com/simrat39/rust-tools.nvim/issues/2#issuecomment-814551847
Co-authored-by: Emmanuel Thompson <eet6646@gmail.com>
8389: Do not import on the fly during fields of record literal syntax r=SomeoneToIgnore a=memoryruins
When only fields are relevant during record literal syntax (`Foo { field_$0 }`), RA already avoids completions of in-scope items, but with `rust-analyzer.completion.enableAutoimportCompletions` enabled, more than field names were eagerly suggested. This PR adds a case to `import_on_the_fly` to avoid the extra completions in this context.
Closes#8300
Co-authored-by: memoryruins <memoryruinsmusic@gmail.com>
8386: Avoid O(n²) when constructing AttrSourceMap r=jonas-schievink a=jonas-schievink
Brings https://github.com/rust-analyzer/rust-analyzer/issues/8377 down to 2.52s on my machine. Not quite back to where it was before, so I'll leave that issue open for now.
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
8380: infer: remove `record_pat_field_resolutions` field r=jonas-schievink a=jonas-schievink
Same as https://github.com/rust-analyzer/rust-analyzer/pull/8376, this
can be computed from other data
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
8371: Don't use HirDisplayWrapper when displaying SourceCode r=matklad a=Veykril
The issue was basically that when displaying for `DisplayTarget::SourceCode` some `hir_fmt` functions would create `HirDisplayWrapper`s which would then `fmt` these triggering the Display panic since `fmt::Display` can't fail the same way as `HirDisplay`. Simple fix is to just use `hir_fmt` directly. Should probably write that down somewhere in source, looking for a good spot to put that right now.
Fixes#8077, Fixes#8370
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
8376: infer: remove `record_field_resolutions` field r=flodiebold a=jonas-schievink
It stores no useful data, since we can derive all fields from
`variant_resolutions`
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
8375: feat: show errors from `cargo metadata` and initial `cargo check` in the status bar r=matklad a=matklad
bors r+
🤖
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
8374: Intern TypeRefs stored in Body r=jonas-schievink a=jonas-schievink
Minor improvement to memory usage (1 MB or so)
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
8364: Memory usage improvements r=jonas-schievink a=alexmaco
These are mostly focused on splitting up enum variants with large size differences between variants by `Box`-ing things up.
In my testing this reduces the memory usage somewhere in the low percentages, even though the measurements are quite noisy.
Co-authored-by: Alexandru Macovei <alexnmaco@gmail.com>
