5326: infer: Add type inference support for Union types r=flodiebold a=otavio
This adds the type inference to Union types and add a small test case
for it, ensuring it keeps working in future.
Fixes: #5277
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
----
#
Co-authored-by: Otavio Salvador <otavio@ossystems.com.br>
This adds the type inference to Union types and add a small test case
for it, ensuring it keeps working in future.
Fixes: #5277
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
cc #4944
cc #5317
This doesn't fully close#4944 -- looks like we hit SO in syntax
highlighting, when we use `Semantics::expand_macro`.
Seems like we need to place expansion limit on the macro itself (store
it as a part of MacroCallId?)!
4996: Correctly generate new struct field in file containing struct def r=matklad a=TimoFreiberg
WIP because the test doesn't pass.
Testing the fix by hand looked good, although quickfixes seem to not support setting the editor cursor yet, which i think we want for "generate missing defs from usage" fixes.
Co-authored-by: Timo Freiberg <timo.freiberg@gmail.com>
5286: Only take first 500 syntax errors r=jonas-schievink a=yihuang
Too many syntax errors make some editor/ide slow, fix#3434.
Co-authored-by: yihuang <yi.codeplayer@gmail.com>
5270: Add argument count mismatch diagnostic r=matklad a=jonas-schievink
Closes https://github.com/rust-analyzer/rust-analyzer/issues/4025.
This currently has one false positive on this line, where `max` is resolved to `Iterator::max` instead of `Ord::max`:
8aa10c00a4/crates/expect/src/lib.rs (L263)
(I have no idea why it thinks that `usize` is an `Iterator`)
TODO:
* [x] Tests
* [x] Improve diagnostic text for method calls
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
Previous solution for binning paths into disjoint directories was
simple and fast -- just a single binary search.
Unfortunatelly, it wasn't coorrect: if the ditr are
/d
/d/a
/d/c
then partitioning the file /d/b/lib.rs won't pick /d as a correct
directory.
The correct solution here is a trie, but it requires exposing path
components.
So, we use a poor man's substitution -- a *vector* of sorted paths,
such that each bucket is prefix-free
closes#5246
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>
5197: SSR internal refactorings r=davidlattimore a=davidlattimore
- Extract error code out to a separate module
- Improve error reporting when a test fails
- Refactor matching code
- Update tests so that all paths in search patterns can be resolved
Co-authored-by: David Lattimore <dml@google.com>
5211: Fix inference of indexing argument (partly) r=flodiebold a=flodiebold
We need to add the `T: Index<Arg>` obligation to be resolved later as well, otherwise we can't make inferences about `Arg` later based on the `Index` impls.
This still doesn't fix indexing with integer variables though; there's a further problem with Chalk floundering because of the variable, I think.
Co-authored-by: Florian Diebold <florian.diebold@freiheit.com>
We need to add the `T: Index<Arg>` obligation to be resolved later as well,
otherwise we can't make inferences about `Arg` later based on the `Index` impls.
This still doesn't fix indexing with integer variables though; there's a further
problem with Chalk floundering because of the variable, I think.
5209: Fixes to memory usage stats r=matklad a=jonas-schievink
This brings the unaccounted memory down from 287mb to 250mb, and displays memory used by VFS and "other" allocations.
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
5116: Categorize assists r=matklad a=kjeremy
Categorize assists so that editors can use them. Follows the LSP spec pretty close (and some things may need adjustments) but this populates the Refactor menu in vscode and pushes quickfixes through again.
This is a prerequisite to filtering out assists that the client doesn't care about.
Fixes#4147
Co-authored-by: Jeremy Kolb <kjeremy@gmail.com>
Co-authored-by: kjeremy <kjeremy@gmail.com>
5192: Implement rust-analyzer feature configuration to tests. r=matklad a=daxpedda
Fixes#3198.
I'm unsure if it is desired this way, maybe we want to make a seperate configuration?
Co-authored-by: daxpedda <daxpedda@gmail.com>
5089: Disable auto-complete on comments r=matklad a=BGluth
Resolves#4907 by disabling any auto-completion on comments.
As flodiebold [pointed out](https://github.com/rust-analyzer/rust-analyzer/issues/4907#issuecomment-648439979), in the future we may want to support some form of auto-completion within doc comments, but for now it was suggested to just disable auto-completion on them entirely.
The implementation involves adding a new field `is_comment` to `CompletionContext` and checking if the immediate token we auto-completed on is a comment. I couldn't see a case where we need to check any of the ancestors, but let me know if this is not sufficient. I also wasn't sure if it was necessary to add a new field to this struct, but I decided it's probably the best option if we want to potentially do auto-completion on doc comments in the future.
Finally, the three tests I added should I think ideally not filter results by `CompletionKind::Keyword`, but if I want to get unfiltered results, I need access to a non-public function [get_all_completion_items](9a4d02faf9/crates/ra_ide/src/completion/test_utils.rs (L32-L39)) which I don't know if I should make public just for this.
5161: SSR: Add initial support for placeholder constraints r=matklad a=davidlattimore
5184: Always install required nightly extension if current one is not nightly r=matklad a=Veetaha
This is weird, but having switched back to stable by uninstalling the extension appears that vscode doesn't destroy the `PersistentState` and thus changing to `nightly` channel doesn't work because the last check for nightly extension was less than 1 hour ago. The simple solution is to skip this check if we know that the current extension version is not nightly.
5185: Force showing extension activation error pop-up notification r=matklad a=Veetaha
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/5091
5186: fix: correct pd/ppd/tfn/tmod completion doc r=matklad a=fannheyward
a33eefa3b2/crates/ra_ide/src/completion/complete_snippet.rs (L23-L24)
Co-authored-by: BGluth <gluthb@gmail.com>
Co-authored-by: David Lattimore <dml@google.com>
Co-authored-by: Veetaha <veetaha2@gmail.com>
Co-authored-by: Heyward Fann <fannheyward@gmail.com>
5149: Implement Chalk variable kinds r=flodiebold a=flodiebold
This means we need to keep track of the kinds (general/int/float) of variables in `Canonical`, which requires some more ceremony. (It also exposes some places where we're not really dealing with canonicalization correctly -- another thing to be cleaned up when we switch to using Chalk's types directly.)
Should fix the last remaining issue of #2534.
Co-authored-by: Florian Diebold <florian.diebold@freiheit.com>
This means we need to keep track of the kinds (general/int/float) of variables
in `Canonical`, which requires some more ceremony. (It also exposes some places
where we're not really dealing with canonicalization correctly -- another thing
to be cleaned up when we switch to using Chalk's types directly.)
Should fix the last remaining issue of #2534.
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).
