8345: Add pub mod option for UnlinkedFile r=rainy-me a=rainy-me
close#8228
This is a draft that changes `Diagnostic` to contain multiple fixes. Pre analysis is in https://github.com/rust-analyzer/rust-analyzer/issues/8228#issuecomment-812887085 Because this solution is straightforward so I decided to type it out for discussion.
Currently the `check_fix` is not able to test the situation when multiple fixes available. <del>Also because `Insert 'mod x;'` and `Insert 'pub mod x;'` are so similar, I don't know how to test them correctly and want some suggestions.</del>. I added
`check_fixes` to allow checking mutiple possible fixes.
In additional, instead of append after possible existing `mod y`, I think it's possible to Insert `pub mod x;` after `pub mod y`. Should I implement this too?
Co-authored-by: rainy-me <github@rainy.me>
8766: Extract function assist will add async if required r=Veykril a=JamieCunliffe
The extract function assist will check for an AWAIT_EXPR or AWAIT_KW in the body and if found, will add async to the generated function.
closes#8232
Co-authored-by: Jamie Cunliffe <Jamie.Cunliffe@outlook.com>
8795: Allow semantic tokens for strings to be disabled r=matklad a=djrenren
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/7111
Pretty straightforward change, but open to any suggestions if there's a more recommended testing strategy than what I went with.
Co-authored-by: John Renner <john@jrenner.net>
8813: Get some more array lengths! r=lf- a=lf-
This is built on #8799 and thus contains its changes. I'll rebase it onto master when that one gets merged. It adds support for r-a understanding the length of:
* `let a: [u8; 2] = ...`
* `let a = b"aaa"`
* `let a = [0u8; 4]`
I have added support for getting the values of byte strings, which was not previously there. I am least confident in the correctness of this part and it probably needs some more tests, as we currently have only one test that exercised that part (!).
Fixes#2922.
Co-authored-by: Jade <software@lfcode.ca>
8819: Use package root as `cargo check` working directory r=matklad a=bcully
Cargo commands are affected by the `.cargo/config` files above
their working directory. If cargo is invoked from above the directory
holding `Cargo.toml`, it may not pick up important settings like
registry replacements, causing it to behave differently or even fail.
Most cargo invocations are currently setting their working directories
to the directory containing `Cargo.toml`, but a couple of paths remain
in which cargo is invoked from the default workspace root instead.
This change fixes that, resolving some cargo check failures that I
experienced in a multi-root workspace in which packages used different
registries.
Co-authored-by: Brendan Cully <brendan@cully.org>
