6161: Bump chalk to use latest git to get upstream fix r=jonas-schievink a=Ameobea
* Chalk very recently (like an hour ago) merged a fix that prevents rust analyzer from panicking. This allows it to be usable again for code that hits those situations. See #6134, #6145, Probably #6120
Co-authored-by: Casey Primozic <me@ameo.link>
6154: Shorten type hints for std::iter Iterators r=SomeoneToIgnore a=Veykril
Fixes#3750.
This re-exports the `hir_expand::name::known` module to be able to fetch the `Iterator` and `iter` names.
I'm not sure if there is anything to do with `Solution::Ambig` in `normalize_trait_assoc_type` or whether discarding those results is always wanted.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
Percentage is a UI concern, the physical fact here is fraction. It's
sad that percentage bleeds into the protocol level, we even duplicated
this bad API ourselves!
6158: Fix for negative literals in macros r=matklad a=cutsoy
_This pull request fixes #6028._
When writing `-42.0f32` in Rust, it is usually parsed as two different tokens (a minus operator and a float literal).
But a procedural macro can also generate new tokens, including negative [float literals](https://doc.rust-lang.org/stable/proc_macro/struct.Literal.html#method.f32_suffixed):
```rust
#[proc_macro]
fn example_verbose(input: TokenStream) -> TokenStream {
let literal = Literal::f32_suffixed(-42.0);
quote! { #literal }
}
```
or even shorter
```rust
#[proc_macro]
fn example(input: TokenStream) -> TokenStream {
let literal = -42.0f32;
quote! { #literal }
}
```
Unfortunately, these currently cause RA to crash:
```
thread '<unnamed>' panicked at 'Fail to convert given literal Literal {
text: "-42.0f32",
id: TokenId(
4294967295,
),
}', crates/mbe/src/subtree_source.rs:161:28
```
This pull request contains both a fix 8cf9362 and a unit test 27798ee. In addition, I installed the patched server with `cargo xtask install --server` and verified in VSCode that it no longer crashes when a procedural macro returns a negative number literal.
Co-authored-by: Tim <tim@glacyr.com>
* Chalk very recently (like an hour ago) merged a fix that prevents rust analyzer from panicking. This allows it to be usable again for code that hits those situations. See #6134, #6145, Probably #6120
6124: Better normalized crate name usage r=jonas-schievink a=SomeoneToIgnore
Closes https://github.com/rust-analyzer/rust-analyzer/issues/5343
Closes https://github.com/rust-analyzer/rust-analyzer/issues/5932
Uses normalized name for code snippets (to be able to test the fix), hover messages and documentation rewrite links (are there any tests for those?).
Also renamed the field to better resemble the semantics.
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
6139: Make find_path_prefixed configurable r=matklad a=Veykril
This makes `find_path_prefixed` more configurable allowing one to choose whether it always returns absolute paths, self-prefixed paths or to ignore local imports when building the path.
The config names are just thrown in here, taking better names if they exist :)
This should fix#6131 as well?
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6111: Add assist for converting the base of integer literals. r=SomeoneToIgnore a=vlakreeh
This PR adds an assist similar to Intellij's [convert number to](https://i.imgur.com/JH6wstP.png). It also does a small refactor to [assists/src/tests.rs](fc34403018/crates/assists/src/tests.rs) to add the ability to specify the resolved assist for a specific action within an assist group.
## Demo
Co-authored-by: vlakreeh <zeb@zebulon.dev>
6127: Correctly complete items with leading underscore r=SomeoneToIgnore a=fmease
Fixes#6091. Let me know if the test is placed into the right file or if it is even desired.
Co-authored-by: León Orell Valerian Liehr <liehr.exchange@gmx.net>
This removes all markdown when the client does not support the markdown MarkupKind
Otherwise the output on the editor will have some markdown boilerplate, making it less readable
This seems like a better factoring logically; ideally, clients shouldn't touch
`set_` methods of the database directly. Additionally, I think this
should remove the unfortunate duplication in fixture code.
5954: Add flexible configuration for runnables r=popzxc a=popzxc
This PR introduces two new configuration options for runnables: `overrideCargo` and `cargoExtraArgs`.
These options are applied to all the "run" tasks of rust analyzer, such as binaries and tests.
Overall motivation is that rust-analyzer provides similar options, for example, for `rustfmt`, but not for runnables.
## `overrideCargo`
This option allows user to replace `cargo` command with something else (well, something that is compatible with the cargo arguments).
Motivation is that some projects may have wrappers around cargo (or even whole alternatives to cargo), which do something related to the project, and only then run `cargo`. With this feature, such users will be able to use lens and run tests directly from the IDE rather than from terminal.
## `cargoExtraArgs`
This option allows user to add any additional arguments for `cargo`, such as `--release`.
It may be useful, for example, if project has big integration tests which take too long in debug mode, or if any other `cargo` flag has to be passed.
Co-authored-by: Igor Aleksanov <popzxc@yandex.ru>
6105: Fix path comparison not comparing paths correctly with unequal lengths r=matklad a=Veykril
~~This PR includes the commit from #6102 there as I found a bug while writing that(so either merging this or both in order works) so I included a test there already which was just ignored.~~ This PR fixes that, basically inserting imports didn't consider path length for equality, so depending on the order it might insert the path before or after another import if they only differ in segment length.
~~Diff without the commit of #61022d90d3937d~~
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6019: Remove make::path_from_text r=matklad a=Veykril
This removes the `make::path_from_text` function, which according to a note should've been private. I removed it since it didn't really serve a purpose as it was simply wrapping `make::ast_from_text`.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6033: Make name resolution resolve proc macros instead of relying purely on the build system r=matklad a=jonas-schievink
This makes name resolution look at proc-macro declaration attributes like `#[proc_macro_derive]` and defines the right proc macro in the macro namespace, fixing unresolved custom derives like `thiserror::Error` (which can cause false positives, now that we emit diagnostics for unresolved imports).
This works even when proc-macro support is turned off, in which case we fall back to a dummy expander that always returns an error. IMO this is the right way to handle at least the name resolution part of proc. macros, while the *expansion* itself should rely on the build system to build and provide the macro DLL. It does mean that they may go out of sync, but we can provide diagnostics if that happens (something like "could not find macro X in crate Y – ensure that all files of crate Y are saved").
I think it is valuable to be able to reason about proc macros even when we can't expand them, since proc macro expansion can break between Rust releases or users might not want to turn it on for performance reasons. It allows us to provide better diagnostics on any proc macro invocation we're not expanding (like a weak warning that informs the user that proc macro support is turned off, or that it has been disabled because the server crashed).
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/5763
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
6085: Mark unresolved imports diagnostic as experimental r=jonas-schievink a=jonas-schievink
It causes a lot of false positives for people. We collected all of the known ones during the last week.
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
6073: Dont unnecessarily unnest imports r=matklad a=Veykril
Fixes#6071
This has the side effect that paths that refer to items inside of the current module get prefixed with `self`. Changing this behavior is unfortunately not straightforward should it be unwanted, though I don't see a problem with this as prefixing imports like this with `self` is what I do personally anyways 😅. You can see what I mean with this in one of the tests which had to be changed in `crates/ssr/src/tests.rs`.
There is one test that i still have to look at though, ~~which I by accident pushed with `#[ignore]` on it~~, which is `different_crate_renamed`, for some reason this now doesn't use the crate alias. This also makes me believe that aliases in general will break with this. So maybe this is not as straight forwards as I'd hoped for, but I don't really know how aliases work here.
Edit: The failing test should work now
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6055: Add ok postfix completion r=matklad a=mullr
Wrapping values in `Ok(...)` is so pervasive that it seems reasonable for it to
have its own postfix completion.
Co-authored-by: Russell Mull <russell.mull@gmail.com>
5846: Add references to fn args during completion r=matklad a=adamrk
When completing a function call, if there is an argument taken as a ref or mut ref which matches the name and type of a variable in scope, we will insert a `&` or `&mut` when filling in the function arguments. This addresses https://github.com/rust-analyzer/rust-analyzer/issues/5449.
E.g.
```rust
fn foo(x: &i32) {}
fn main() {
let x = 5;
foo # completing foo here generates `foo(&x)` now instead of `foo(x)`
}
```
Co-authored-by: adamrk <ark.email@gmail.com>
6043: Allow missing trait members assist without needing braces r=matklad a=M-J-Hooper
Assist to complete missing items when implementing a trait does not appear without impl def braces (see #5144 ).
The reason behind this was that this assist is based on `ast::AssocItemList` which only appears in the AST after the braces are added to the impl def.
Instead of relying on and replacing the item list, we now instead replace the entire `ast::Impl` and add the item list if its missing.
Co-authored-by: Matt Hooper <matthewjhooper94@gmail.com>
6018: Correct project_root path for ProjectJson. r=jonas-schievink a=woody77
It was already the folder containing the rust-project.json file, not the file itself. This also removes the Option-ness of it, since it's now an infallible operation to set the member value.
Co-authored-by: Aaron Wood <aaronwood@google.com>
6036: Don't re-read open files from disk when reloading a workspace r=kjeremy a=lnicola
Fixes#5742Fixes#4263
or so I hope.
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
6017: Don't return any TextEdit if formatting is unchanged r=jonas-schievink a=cuviper
I found that `textDocument/formatting` was always returning a full
`TextEdit` replacement, even when there are no changes, which caused Vim
(w/ vim-lsp) to always indicate a modified buffer after formatting. We
can easily compare whether there were changes and return `null` if not,
so the client knows there's nothing to do.
Co-authored-by: Josh Stone <cuviper@gmail.com>
6016: Emit diagnostics for unresolved imports and extern crates r=jonas-schievink a=jonas-schievink
AFAIK, we don't have any major bugs in name resolution that would cause a lot of false positives here (except procedural attribute macro support and some rare issues around `#[path]` on module files), so these are *not* marked as experimental diagnostics right now.
I noticed that diagnostics in a file sometimes don't get displayed after opening, but require some edit to be performed. This seems like a preexisting issue though.
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
5989: Rewrite import merging r=jonas-schievink a=Veykril
Rewrites how import merging is being handled. It is now a recursive function to properly handle merging of intermediate levels in the import trees. With this ordering the imports is also now possible tho it doesn't quite order it the same way as `rustfmt` does yet, namely it orders lowercase identifiers after uppercase identifiers as that is the standard character order that rust uses. This also fixes a few weird behaviors that were visible in some of the `replace_qualified_name_with_use.rs` tests.
This really took longer than I was hoping for, fighting with import trees is quite the exhausting task 😅
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
