2942: Properly select a target for auto importing r=matklad a=SomeoneToIgnore
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/2932
The corresponding test has the caret placed in the beggining of the document despite the import inserted, but I don't thing I should fix it here:
* in real life, there's some text written before the import and for those cases the caret behaves normally
* it's a separate functionality that needs to be refactored anyway later (the `auto_import_text_edit`)
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
2937: Parse cargo output a line at a time. r=kiljacken a=kiljacken
We previously used serde's stream deserializer to read json blobs from
the cargo output. It has an issue though: If the deserializer encounters
invalid input, it gets stuck reporting the same error again and again
because it is unable to foward over the input until it reaches a new
valid object.
Reading a line at a time and manually deserializing fixes this issue,
because cargo makes sure to only outpu one json blob per line, so should
we encounter invalid input, we can just skip a line and continue.
The main reason this would happen is stray printf-debugging in
procedural macros, so we still report that an error occured, but we
handle it gracefully now.
Fixes#2935
Co-authored-by: Emil Lauridsen <mine809@gmail.com>
We previously used serde's stream deserializer to read json blobs from
the cargo output. It has an issue though: If the deserializer encounters
invalid input, it gets stuck reporting the same error again and again
because it is unable to foward over the input until it reaches a new
valid object.
Reading a line at a time and manually deserializing fixes this issue,
because cargo makes sure to only outpu one json blob per line, so should
we encounter invalid input, we can just skip a line and continue.
The main reason this would happen is stray printf-debugging in
procedural macros, so we still report that an error occured, but we
handle it gracefully now.
Fixes#2935
2931: Added documentation to test_utils r=matklad a=Veetaha
Added some doc comments to test_utils functions while studying this crate. They should be all stable enough to document them.
Also some minor code relocation in `parse_fixture()` closer to its usage according to the advice of @matklad.
Co-authored-by: Veetaha <gerzoh1@gmail.com>
2924: Modify ordering of drops in check watcher to only ever have one cargo r=matklad a=kiljacken
Due to the way drops are ordered when assigning to a mutable variable we
were launching a new cargo sub-process before letting the old one quite.
By explicitly replacing the original watcher with a dummy first, we
ensure it is dropped and the process is completed, before we start the
new process.
Co-authored-by: Emil Lauridsen <mine809@gmail.com>
Due to the way drops are ordered when assigning to a mutable variable we
were launching a new cargo sub-process before letting the old one quite.
By explicitly replacing the original watcher with a dummy first, we
ensure it is dropped and the process is completed, before we start the
new process.
2923: Don't do check progress update for fresh crates r=matklad a=kiljacken
Skip sending progress updates for crates that aren't getting checked.
Co-authored-by: Emil Lauridsen <mine809@gmail.com>
2916: Buffer reads from cargo check's stdout r=matklad a=lnicola
`Stdio::piped()` is unbuffered, which caused RA to read the output of `cargo check` one byte at a time (out of 114KB in my test).
This isn't obviously faster on my system, but making fewer syscalls sounds like a good idea.
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
2810: Improves reference search by StructLiteral r=mikhail-m1 a=mikhail-m1
Hey, I've made some changes to improve search for struct literals, now it works for `struct Foo<|> {`, `struct Foo <|>{`, `struct Foo<|>(`. Unfortunately tuple creation is represented as a call expression, so for tuples it works only is search is started in a tuple declaration. It leads to incorrect classification of function calls during search phase, but from user perspective it's not visible and works as expected. May be it worth to add a comment or rename it to remove this misleading classification. Issue #2549.
Co-authored-by: Mikhail Modin <mikhailm1@gmail.com>
2872: Upgrade Chalk r=matklad a=flodiebold
This is just keeping track of the changes required to upgrade Chalk; currently we can't really merge it since it breaks opaque types.
Now also makes use of the newly introduced `solve_limited` to implement fuel.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
