5244: Add a command to compute memory usage statistics r=matklad a=jonas-schievink
This allows inspecting memory usage on a live rust-analyzer instance after it has been used interactively.
This will only work with `--features jemalloc`, so maybe it should print something more useful when that's not available? Right now it will just print 0 Bytes for every query.
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
5245: Refactor AssistBuilder to manage a SourceChange r=matklad a=theduke
`AssistBuilder` now managaes a full `SourceChange` instead of a
`Vec<SourceFileEdit>`.
This prepares AssistBuilder to handle creation of new files.
Co-authored-by: Christoph Herzog <chris@theduke.at>
5175: More memory-efficient impl collection r=matklad a=jonas-schievink
This saves roughly 90 MB in `ImplsFromDepsQuery`, which used to copy the list of all impls from libcore into *every* crate in the graph. It also stops collecting inherent impls from dependencies entirely, as those can only be located within the crate defining the self type.
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
This makes the intention of inherent vs. trait impls somewhat more
clear and also fixes (?) an issue where trait impls with an unresolved
trait were added as inherent impls instead (hence the test changes).
We might as well handle them internally, via queries.
I am not sure, but it looks like the current LibraryData setup might
even predate salsa? It's not really needed and creates a bunch of
complexity.
Anchoring to the SourceRoot wont' work if the path is absolute:
#[path = "/tmp/foo.rs"]
mod foo;
Anchoring to a file will.
However, we *should* anchor, instead of just producing an abs path.
I can imagine a situation where, for example, rust-analyzer processes
crates from different machines (or, for example, from in-memory git
branch), where the same absolute path in different crates might refer
to different files in the end!
4819: Add an FST index to `ImportMap` and use it to speed up auto import r=matklad a=jonas-schievink
For the importing crate, we still use the symbol index, but I've modified it to only look at files that comprise that crate (instead of the whole workspace).
Oh, and since now the symbol query limit is respected correctly, it's possible that some results from the local crate now disappear if there are many matches.
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/4763
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
4689: Implement return position impl trait / opaque type support r=matklad a=flodiebold
This is working, but I'm not that happy with how the lowering works. We might need an additional representation between `TypeRef` and `Ty` where names are resolved and `impl Trait` bounds are separated out, but things like inference variables don't exist and `impl Trait` is always represented the same way.
Also note that this doesn't implement correct handling of RPIT *inside* the function (which involves turning the `impl Trait`s into variables and creating obligations for them). That intermediate representation might help there as well.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
Co-authored-by: Florian Diebold <florian.diebold@freiheit.com>
4729: Hover actions r=matklad a=vsrs
This PR adds a `hoverActions` LSP extension and a `Go to Implementations` action as an example:
4748: Add an `ImportMap` and use it to resolve item paths in `find_path` r=matklad a=jonas-schievink
Removes the "go faster" queries I added in https://github.com/rust-analyzer/rust-analyzer/pull/4501 and https://github.com/rust-analyzer/rust-analyzer/pull/4506. I've checked this PR on the rustc code base and the assists are still fast.
This should fix https://github.com/rust-analyzer/rust-analyzer/issues/4515.
Note that this does introduce a change in behavior: We now always refer to items defined in external crates using paths through the external crate. Previously we could also use a local path (if for example the extern crate was reexported locally), as seen in the changed test. If that is undesired I can fix that, but the test didn't say why the previous behavior would be preferable.
Co-authored-by: vsrs <vit@conrlab.com>
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
The idea behind requiring the label is a noble one, but we are not
really using it consistently anyway, and it should be easy to retrofit
later, should we need it.
