Feature: Add assist to unwrap tuple declarations
> Implement #12923 for only tuples.
>
> Does not implement unwrapping for structs, as mentioned in the issue.
Add assist to unwrap tuples declarations to separate declarations.
```rust
fn main() {
$0let (foo, bar, baz) = (1.0, "example", String::new())
}
```
becomes:
```rust
fn main() {
let foo = 1.0;
let bar = "example";
let baz = String::new();
}
```
## Changelog
### Feature
- Added assist to unwrap tuple declarations.
feat: type inference for generators
This PR implements basic type inference for generator and yield expressions.
Things not included in this PR:
- Generator upvars and generator witnesses are not implemented. They are only used to determine auto trait impls, so basic type inference should be fine without them, but method resolutions with auto trait bounds may not be resolved correctly.
Open questions:
- I haven't (yet) implemented `HirDisplay` for `TyKind::Generator`, so generator types are just shown as "{{generator}}" (in tests, inlay hints, hovers, etc.), which is not really nice. How should we show them?
- I added moderate amount of stuffs to minicore. I especially didn't want to add `impl<T> Deref for &T` and `impl<T> Deref for &mut T` exclusively for tests for generators; should I move them into the test fixtures or can they be placed in minicore?
cc #4309
proc-macro ABI breakage still affects the tests when a new stable version
releases. Ideally we'd still be able to run the tests on the rust-analyzer
repo without having to update the proc-macro ABI, but for now just to
unblock CI we will ignore them here, as they are still run in upstream.
feat: Display the value of enum variant on hover
fixes#12955
This PR adds const eval support for enums, as well as showing their value on hover, just as consts currently have.
I developed these two things at the same time, but I've realized now that they are separate. However since the hover is just a 10 line change (not including tests), I figured I may as well put them in the same PR. Though if you want them split up into "enum const eval support" and "show enum variant value on hover", I think that's reasonable too.
Since this adds const eval support for enums this also allows consts that reference enums to have their values computed now too.
The const evaluation itself is quite rudimentary, it doesn't keep track of the actual type of the enum, but it turns out that Rust doesn't actually either, and `E::A as u8` is valid regardless of the `repr` on `E`.
It also doesn't really care about what expression the enum variant contains, it could for example be a string, despite that not being allowed, but I guess it's up to the `cargo check` diagnostics to inform of such issues anyway?
Add a new configuration settings to set env vars when running cargo, rustc, etc. commands: cargo.extraEnv and checkOnSave.extraEnv
It can be extremely useful to be able to set environment variables when rust-analyzer is running various cargo or rustc commands (such as `cargo check`, `cargo --print cfg` or `cargo metadata`): users may want to set custom `RUSTFLAGS`, change `PATH` to use a custom toolchain or set a different `CARGO_HOME`.
There is the existing `server.extraEnv` setting that allows env vars to be set when the rust-analyzer server is launched, but using this as the recommended mechanism to also configure cargo/rust has some drawbacks:
- It convolutes configuring the rust-analyzer server with configuring cargo/rustc (one may want to change the `PATH` for cargo/rustc without affecting the rust-analyzer server).
- The name `server.extraEnv` doesn't indicate that cargo/rustc will be affected but renaming it to `cargo.extraEnv` doesn't indicate that the rust-analyzer server would be affected.
- To make the setting useful, it needs to be dynamically reloaded without requiring that the entire extension is reloaded. It might be possible to do this, but it would require the client communicating to the server what the overwritten env vars were at first launch, which isn't easy to do.
This change adds two new configuration settings: `cargo.extraEnv` and `checkOnSave.extraEnv` that can be used to change the environment for the rust-analyzer server after launch (thus affecting any process that rust-analyzer invokes) and the `cargo check` command respectively. `cargo.extraEnv` supports dynamic changes by keeping track of the pre-change values of environment variables, thus it can undo changes made previously before applying the new configuration (and then requesting a workspace reload).
Fix add reference action on macros.
Before we were using the range of the corresponding expression node in the macro expanded file, which is obviously incorrect as we are setting the text in the original source.
For some reason, the test I added is failing and I haven't found a way to fix it. Does anyone know why `check_fix` wouldn't work with macros? Getting this error:
```text
thread 'handlers::type_mismatch::tests::test_add_reference_to_macro_call' panicked at 'no diagnostics', crates/ide-diagnostics/src/handlers/type_mismatch.rs:317:9
```
closes#13219
Use memmem when searching for usages in ide-db
We already have this dependency, so there is no reason not to use it as it is generally faster than std in our use case.
Allow configuration of annotation location.
I've added the ability to configure where lens annotations render relevant to the item they describe. Previously, these would render directly above the line the item is declared on. Now, there is the ability to render these annotations above the entire item (including doc comments, and attributes).
The names of the config options are up for debate, I did what seemed best to me but if anyone has better ideas let me know.
This is my first contribution so if I've missed anything please let me know.
Here's a preview of what the new option looks like:
<img width="577" alt="Screen Shot 2022-09-11 at 10 39 51 PM" src="https://user-images.githubusercontent.com/33100798/189570298-b4fcbf9c-ee49-4b79-aae6-1037ae4f26af.png">
closes https://github.com/rust-lang/rust-analyzer/issues/13218
fixup: remove unnecessary `Option`
Fixup for #13223, two things:
- `normalize_projection_query()` (and consequently `HirDatabase::normalize_projection()`) never returns `None` (well, it used to when I first wrote it...), so just return `Ty` instead of `Option<Ty>`
- When chalk cannot normalize projection uniquely, `normalize_trait_assoc_type()` used to return `None` before #13223, but not anymore because of the first point. I restored the behavior so its callers work as before.
Restructure `find_path` into a separate functions for modules and non-module items
Follow up to https://github.com/rust-lang/rust-analyzer/pull/13212
Also renames `prefer_core` imports config to `prefer_no_std` and changes the behavior of no_std path searching by preferring `core` paths `over` alloc
This PR turned into a slight rewrite, so it unfortunately does a few more things that I initially planned to (including a bug fix for enum variant paths)
New assist: move_format_string_arg
The name might need some improving.
```rust
fn main() {
print!("{x + 1}");
}
```
to
```rust
fn main() {
print!("{}"$0, x + 1);
}
```
fixes#13180
ref to #5988 for similar work
* extracted `format_like`'s parser to it's own module in `ide-db`
* reworked the parser's API to be more direct
* added assist to extract expressions in format args
fix: handle lifetime variables in projection normalization
Fixes#12674
The problem is that we've been skipping the binders of normalized projections assuming they should be empty, but the assumption is unfortunately wrong. We may get back lifetime variables and should handle them before returning them as normalized projections. For those who are curious why we get those even though we treat all lifetimes as 'static, [this comment in chalk](d875af0ff1/chalk-solve/src/infer/unify.rs (L888-L908)) may be interesting.
I thought using `InferenceTable` would be cleaner than the other ways as it already has the methods for canonicalization, normalizing projection, and resolving variables, so moved goal building and trait solving logic to a new `HirDatabase` query. I made it transparent query as the query itself doesn't do much work but the eventual call to `HirDatabase::trait_solve_query()` does.
fix: handle trait methods as inherent methods for trait-related types
Fixes#10677
When resolving methods for trait object types and placeholder types that are bounded by traits, we need to count the methods of the trait and its super traits as inherent methods. This matters because these trait methods have higher priority than the other traits' methods.
Relevant code in rustc: [`assemble_inherent_candidates_from_object()`](0631ea5d73/compiler/rustc_typeck/src/check/method/probe.rs (L783-L792)) for trait object types, [`assemble_inherent_candidates_from_param()`](0631ea5d73/compiler/rustc_typeck/src/check/method/probe.rs (L838-L847)) for placeholder types. Notice the second arg of `push_candidate()` is `is_inherent`.
Previously, annotations would only appear above the name of an item (function signature, struct declaration, etc).
Now, rust-analyzer can be configured to show annotations either above the name or above the whole item (including doc comments and attributes).
The name might need some improving.
extract format_like's parser to it's own module in ide-db
reworked the parser's API to be more direct
added assist to extract expressions in format args
fix: sort all bounds on trait object types
Fixes#13181#12793 allowed different ordering of trait bounds in trait object types but failed to account for the ordering of projection bounds. I opted for sorting all the bounds at once rather than splitting them into `SmallVec`s so it's easier to do the same thing for other bounds when we have them.
fix: Insert whitespaces into static & const bodies if they are expanded from macro on hover
Partially fixes#13143.
To resolve the other part we need to expand macros in unevaluated static & const bodies, and I'm not sure we want to. If for example it includes a call to `assert!()`, expanding it will lead to worse hover.
It seems that we've accidentally deleted the tests here couple of years
ago, and then fairly recently made a typo during refactor as well.
Reinstall tests, with coverage marks this time :-)
A Resolver *always* has a module scope at the end of its scope stack,
instead of encoding this as an invariant we can just lift this scope
out into a field, allowing us to skip going through the scope vec
indirection entirely.
feat: Implement `feature(exhaustive_patterns)` from unstable Rust
Closes#12753
Recognize Rust's unstable `#![feature(exhaustive_patterns)]` (RFC 1872). Allow omitting visibly uninhabited variants from `match` expressions when the feature is on.
This adjusts match checking to the current implementation of the postponed RFC 1872 in rustc.
fix: Parse TypePathFn with preceding `::`
e.g. `impl Fn::() -> ()`.
Fixes#13157. This was the problem, not that the path was not at the end.
I could unify the parsing of `::` of TypePathFn with that of generic arg list, but some code relies on the `::` of generic arg list to be inside it.
fix: Lower float literals with underscores
Fixes#13155 (the problem was the `PI` is defined with `_f64` suffix). `PI` is still truncated, though, because `f64` cannot represent the value with full precision.
Highlight namerefs by syntax until proc-macros have been loaded
Usually when loading up a project, once loading is done we start answering highlight requests while proc-macros haven't always been loaded yet, so we start out with showing a lot of unresolved name-refs. After this PR, we'll use syntax based highlighting for those unresolved namerefs until the proc-macros have been loaded.
Remove hir::Expr::MacroStmts
This hir expression isn't needed and only existed as it was simpler to
deal with at first as it gave us a direct mapping for the ast version of
the same construct. This PR removes it, properly handling the statements
that are introduced by macro call expressions.
This hir expression isn't needed and only existed as it was simpler to
deal with at first as it gave us a direct mapping for the ast version of
the same construct. This PR removes it, properly handling the statements
that are introduced by macro call expressions.
feature: Assist to turn match into matches! invocation
Resolves#12510
This PR adds an assist, which convert 2-arm match that evaluates to a boolean into the equivalent matches! invocation.
fix: Only move comments when extracting a struct from an enum variant
Motivating example:
```rs
#[derive(Debug, thiserror::Error)]
enum Error {
/// Some explanation for this error
#[error("message")]
$0Woops {
code: u32
}
}
```
now becomes
```rs
/// Some explanation for this error
#[derive(Debug, thiserror::Error)]
struct Woops{
code: u32
}
#[derive(Debug, thiserror::Error)]
enum Error {
#[error("message")]
Woops(Woops)
}
```
(the `thiserror::Error` derive being copied and the struct formatting aren't ideal, though those are issues for another day)
fix: sort and deduplicate auto traits in trait object types
Fixes#12739
Chalk solver doesn't sort and deduplicate auto traits in trait object types, so we need to handle them ourselves in the lowering phase, just like [`rustc`](880416180b/compiler/rustc_typeck/src/astconv/mod.rs (L1487-L1488)) and [`chalk-integration`](https://github.com/rust-lang/chalk/blob/master/chalk-integration/src/lowering.rs#L575) do.
Quoting from [the Chalk book](https://rust-lang.github.io/chalk/book/types/rust_types.html#dyn-types):
> Note that -- for this purpose -- ordering of bounds is significant. That means that if you create a `dyn Foo + Send` and a `dyn Send + Foo`, chalk would consider them distinct types. The assumption is that bounds are ordered in some canonical fashion somewhere else.
Also, trait object types with more than one non-auto traits were previously allowed, but are now disallowed with this patch.
Use correct type in "Replace turbofish with type"
And support `?` and `.await` expressions.
Fixes#13148.
The assist can still show up even if the turbofish's type is not used at all, e.g.:
```rust
fn foo<T>() {}
let v = foo::<i32>();
```
I implemented that by checking the expressions' type.
This could probably be implemented better by taking the function's return type and substituting the generic parameter with the provided turbofish, but this is more complicated.
feat: Add a "Unmerge match arm" assist to split or-patterns inside match expressions
Fixes#13072.
The way I implemented it it leaves the `OrPat` in place even if there is only one pattern now but I don't think something will break because of that, and when more code will be typed we'll parse it again anyway. Removing it (but keeping the child pattern) is hard, I don't know how to do that.
Move empty diagnostics workaround back into the server
This only touches on the diagnostics in one place instead of multiple as was previously done, since all published diagnostics will go through this code path anyways.
Closes https://github.com/rust-lang/rust-analyzer/issues/13130
Make use of NoHash hashing for FileId and CrateId
Both of these are mere integers so there is nothing to hash here.
Ideally we would use this for `la_arena::Idx` too, but that doesn't work due to the orphan rule, and `la_arena` is unfortunately a public library so we can't really do much here... Unless we remove the trait restriction but I'd like not to
internal: Re-export standard semantic token types and mods
Should help in preventing future occurences of #13099 by having all token types and mods come through the same place
Add some more highlighting configurations
The following can be enabled/disabled now in terms of highlighting:
- doc comment injection (enabled by default)
- punctuation highlighting (disabled by default)
- operator highlighting (enabled by default)
- punctuation specialized highlighting (disabled by default)
- operator specialized highlighting (disabled by default)
- macro call bang highlighting (disabled by default)
This PR also changes our `attribute` semantic token type to the `decorator` type which landed upstream (but not yet in lsp-types).
Specialized highlighting is disabled by default, as all clients will have to ship something to map these back to the standard punctuation/operator token (we do this in VSCode via the inheritance mapping for example). This is a lot of maintenance work, and not something every client wants to do, pushing that need to use the user. As this is a rather niche use in the first place this will just be disabled by default.
Punctuation highlighting is disabled by default, punctuation is usually something that can be done by the native syntactic highlighting of the client, so there is no loss in quality. The main reason for this though is that punctuation adds a lot of extra token data that we sent over, a lot of clients struggle with applying this, so disabling this improves the UX for a lot of people. Note that we still highlight punctuations with special meaning as that special entity, (the never type `!` will still be tagged as a builtin type if it occurs as such)
Separate highlighting of the macro call bang `!` is disabled by default, as I think people actually didn't like that change that much, though at the same time I feel like not many people even noticed that change (I prefer it be separate, but that's not enough reason for it to be enabled by default I believe :^) )
cc https://github.com/rust-lang/rust-analyzer/issues/12783https://github.com/rust-lang/rust-analyzer/issues/13066
fix: Fix panics on GATs involving const generics
This workaround avoids constant crashing of rust analyzer when using GATs with const generics,
even when the const generics are only on the `impl` block.
The workaround treats GATs as non-existing if either itself or the parent has const generics and
removes relevant panicking code-paths.
Fixes#11989, fixes#12193
feat: Generate static method using Self::assoc() syntax
This change improves the `generate_function` assist to support generating static methods/associated functions using the `Self::assoc()` syntax. Previously, one could generate a static method, but only when specifying the type name directly (like `Foo::assoc()`). After this change, `Self` is supported as well as the type name.
Fixes#13012
feat: Add an assist for inlining all type alias uses
## Description
`inline_type_alias_uses` assist tries to inline all selected type alias occurrences.
### Currently
Type alias used in `PathType` position are inlined.
### Not supported
- Removing type alias declaration if all uses are inlined.
- Removing redundant imports after inlining all uses in the file.
- Type alias not in `PathType` position, such as:
- `A::new()`
- `let x = A {}`
- `let bits = A::BITS`
- etc.
## Demonstration
## Related Issues
Partially fixes#10881
feat: Run test mod from anywhere in parent file
The "Run" feature of rust-analyzer is super useful, especially for running
individual tests or test-modules during development.
One common pattern in rust development is to develop tests in the same file as
production code, inside a module (usually called `test` or `tests`) marked with
`#[cfg(test)]`. Unforunately, this pattern is not well supported by r-a today,
as a test module won't show up as a runnable unless the cursor is inside it.
In my experience, it is quite common to want to run the tests associated with
some production code immediately after editing it, not only after editing the
tests themselves. As such it would be better if test modules were available
from the "Run" menu even when the cursor is outside the test module.
This change updates the filtration logic for runnables in
`handlers::handle_runnables` to special case `RunnableKind::TestMod`, making
test modules available regardless of the cursor location. Other `RunnableKind`s
are unnaffected.
Fixes#9589
fix: resolve associated types of bare dyn types
Fixes#13031
We've been dropping the associated type bindings of trait object types that were written without the `dyn` keyword. This patch reuses the lowering logic for `TypeRef::DynTrait` so the associated type bindings are properly lowered.
The "Run" feature of rust-analyzer is super useful, especially for running
individual tests or test-modules during development.
One common pattern in rust development is to develop tests in the same file as
production code, inside a module (usually called `test` or `tests`) marked with
`#[cfg(test)]`. Unforunately, this pattern is not well supported by r-a today,
as a test module won't show up as a runnable unless the cursor is inside it.
In my experience, it is quite common to want to run the tests associated with
some production code immediately after editing it, not only after editing the
tests themselves. As such it would be better if test modules were available
from the "Run" menu even when the cursor is outside the test module.
This change updates the filtration logic for runnables in
`handlers::handle_runnables` to special case `RunnableKind::TestMod`, making
test modules available regardless of the cursor location. Other `RunnableKind`s
are unnaffected.
Fixes#9589
fix: a bunch of typos
This PR will fix some typos detected by [typos].
There are also some other typos in the function names, variable names, and file
names, which I leave as they are. I'm more certain that typos in comments
should be fixed.
[typos]: https://github.com/crate-ci/typos
This PR will fix some typos detected by [typos].
There are also some other typos in the function names, variable names, and file
names, which I leave as they are. I'm more certain that typos in comments
should be fixed.
[typos]: https://github.com/crate-ci/typos
fix: escape keywords used as names in earlier editions
Fixes#13030
There are keywords in Rust 2018+ that you can use as names without escaping when your crate is in Rust 2015 e.g. "try". We need to be consistent on how to keep track of the names regardless of how they are actually written in each crate. This patch attempts at it by taking such names into account and storing them uniformly in their escaped form.
