11789: fix: Fix lifetime elision hint configuration key r=Veykril a=Veykril
This is inconsistent with the other configuration keys unfortunately, but this is an issue of how we structured them here in general.
I feel like we'll have to do a proper pass over all the configs, check them for consistency and then write down some documentation of how our configs should be laid out, then apply fixes to the inconsistencies all at once which will entail breaking some user configurations unfortunately since we won't be able to do proper fallback handling for some of these.
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/11778
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
11786: fix: fill_match_arms doesn't add wildcard pat for local enums r=Veykril a=OleStrohm
Fix#11783
This adds similar logic to non_exhaustive as is currently on doc(hidden)
Co-authored-by: Ole Strohm <strohm99@gmail.com>
11780: feat: Add type mismatch diagnostic r=flodiebold a=flodiebold
This adds a proper diagnostic for type mismatches, turning "Add reference here", "Missing Ok or Some" and "Remove this semicolon" into quickfixes for this single diagnostic.
The diagnostic is marked as experimental when it does not have one of these quickfixes, so it can be turned off with `rust-analyzer.diagnostics.enableExperimental` (or specifically with `rust-analyzer.diagnostics.disabled` of course, the ID is `type-mismatch`).
There will still be some false positives, but I think there shouldn't be too many especially when the Chalk fix lands, and it's still experimental anyway 🙂
This also fixes type checking for `rustc_legacy_const_generics` just to avoid some errors in tests.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
11774: feat: Tag macro calls as unsafe if they expand to unsafe expressions r=Veykril a=Veykril
as long as they aren't inside an unsafe block inside the macro that is.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
11740: Insert #[must_use] in generate_is_empty_from_len r=lnicola a=Walther
Inserts `#[must_use]` for the generated `is_empty` methods. I also added the `#[must_use]` for the `len()` methods in the documentation examples and tests for this generator while at it, to make sure they too encourage the use of the annotation.
From discussion in https://github.com/rust-analyzer/rust-analyzer/issues/11736 and https://github.com/rust-analyzer/rust-analyzer/pull/11738
Co-authored-by: Walther <veeti.haapsamo@gmail.com>
11694: fix: "Extract to function" assist preserves `break` and `continue` labels r=Veykril a=m0rg-dev
Adds a label / lifetime parameter to `ide_assists::handlers::extract_function::FlowKind::{Break, Continue}`, adds support for emitting labels to `syntax::ast::make::{expr_break, expr_continue}`, and implements the required machinery to let `extract_function` make use of them.
This does modify the external API of the `syntax` crate, but the changes there are simple, not used outside `ide_assists`, and, well, we should probably support emitting `break` and `continue` labels through `syntax` anyways, they're part of the language spec.
Closes#11413.
Co-authored-by: Morgan Thomas <corp@m0rg.dev>
Adds a label / lifetime parameter to `ide_assists::handlers::extract_function::FlowKind::{Break, Continue}`, adds support for emitting labels to `syntax::ast::make::{expr_break, expr_continue}`, and implements the required machinery to let `extract_function` make use of them.
This does modify the external API of the `syntax` crate, but the changes there are simple, not used outside `ide_assists`, and, well, we should probably support emitting `break` and `continue` labels through `syntax` anyways, they're part of the language spec.
Closes#11413.
- use original instead of adjusted type in ide_completion::completions::record::complete_record
- don't even bother checking if we can complete union literals to Default or to struct update syntax
11686: feat: Enum variant field completion, enum variant / struct consistency r=Veykril a=m0rg-dev
This addresses several related inconsistencies:
- tuple structs use tab stops instead of placeholders
- tuple structs display in the completion menu as `Struct {…}` instead of `Struct(…)`
- enum variants don't receive field completions at all
- enum variants display differently from structs in the completion menu
Also, structs now display their type in the completion detail rather than the raw snippet text to be inserted.
As far as what's user-visible, that looks like this:
| | Menu | Completion | Detail |
|-|-|-|-|
| Record struct (old) | `Struct {…}` | `Struct { x: ${1:()}, y: ${2:()} }$0` | `Struct { x: ${1:()}, y: ${2:()} }$0` |
| Record struct (new) | `Struct {…}` | `Struct { x: ${1:()}, y: ${2:()} }$0` | `Struct { x: i32, y: i32 }` |
| Tuple struct (old) | `Struct {…}` | `Struct($1, $2)$0` | `Struct($1, $2)` |
| Tuple struct (new) | `Struct(…)` | `Struct(${1:()}, ${2:()})$0` | `Struct(i32, i32)` |
| Unit variant (old) | `Variant` | `Variant` | `()` |
| Unit variant (new) | `Variant` | `Variant$0` | `Variant` |
| Record variant (old) | `Variant` | `Variant` | `{x: i32, y: i32}` |
| Record variant (new) | `Variant {…}` | `Variant { x: ${1:()}, y: ${2:()} }$0` | `Variant { x: i32, y: i32 }` |
| Tuple variant (old) | `Variant(…)` | `Variant($0)` | `(i32, i32)` |
| Tuple variant (new) | `Variant(…)` | `Variant(${1:()}, ${2:()})$0` | `Variant(i32, i32)` |
Additionally, tuple variants no longer set `triggers_call_info` because it conflicts with placeholder generation, and tuple variants that require a qualified path should now use the qualified path.
Internally, this also lets us break the general "format an item with fields on it" code out into a shared module, so that means it'll be a lot easier to implement features like #11568.
Co-authored-by: Morgan Thomas <corp@m0rg.dev>
In particular:
- unit variants now display in the menu as "Variant", complete to "Variant", and display a detail of "Variant" (was "()")
- tuple variants now display in the menu as "Variant(…)", complete to "Variant(${1:()})$0" (was "Variant($0)"), and display a detail of "Variant(type)" (was "(type)")
- record variants now display in the menu as "Variant {…}", complete to "Variant { x: ${1:()} }$0" (was "Variant"), and display a detail of "Variant { x: type }" (was "{x: type}")
This behavior is identical to that of struct completions. In addition, tuple variants no longer set triggers_call_info, as to my understanding it's unnecessary now that we're emitting placeholders.
Tests have been updated to match, and the render::enum_variant::tests::inserts_parens_for_tuple_enums test has been removed entirely as it's covered by other tests (render::enum_detail_includes_{record, tuple}_fields, render::enum_detail_just_name_for_unit, render::pattern::enum_qualified).
- Add support for placeholder completions in tuple structs
- Denote tuple struct completions with `(…)` instead of ` {…}`
- Show struct completions as their type (`Struct { field: Type }`) in the completion menu instead of raw snippet text (`Struct { field: ${1:()} }$0`)
It wasn't testing the `const_arg` code path, it was actually hitting
const_param's default value code path, so move it to the right place
and rename it.
11676: internal: Expand into pseudo-derive attribute expansions in completions r=Veykril a=Veykril
With this we now properly handle qualified path completions in derives
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
11662: fix: extract_module selection inside impl r=Veykril a=feniljain
Should close: #11508
From issue:
Concern 1: Seems to be fixed in latest `rust-analyzer` build
Concern 2 and 3: Should be fixed by this PR
Concern 4: Got fixed in #11472
Points to note:
- Here I have seperated use items and other items, this is becuase the new `impl` block which we will be creating cannot contain use items as immediate children. As they are the only one item that can be generated by our assist, so seperating them helps in handling their inclusion in new `impl` block inside new `module`
- There's also a new method added which helps in removing remaning left over indentation after removing `impl` or other `item`
Co-authored-by: vi_mi <fkjainco@gmail.com>
11660: Insert dummy values for const generics in subst r=flodiebold a=HKalbasi
fix#11659
This is a band-aid until proper const generic support.
Co-authored-by: hkalbasi <hamidrezakalbasi@protonmail.com>
11663: Internal: Add hir_def::MacroId, add Macro{Id} to ModuleDef{Id} r=Veykril a=Veykril
With this we can now handle macros like we handle ModuleDefs making them work more like other definitions and allowing us to remove a bunch of special cases. This also enables us to track the modules these macros are defined in, instead of only recording the crate they come from.
Introduces a new class of `MacroId`s (for each of the 3 macro kinds) into `hir_def`. We can't reuse `MacroDefId` as that is defined in `hir_expand` which doesn't know of modules, so now we have two different macro ids, this unfortunately requires some back and forth mapping between the two via database accesses which I hope won't be too expensive.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
11445: Upstream inlay hints r=lnicola a=lnicola
Closes https://github.com/rust-analyzer/rust-analyzer/issues/2797
Closes https://github.com/rust-analyzer/rust-analyzer/issues/3394 (since now resolve the hints for the range given only, not for the whole document. We don't actually resolve anything due to [hard requirement](https://github.com/rust-analyzer/rust-analyzer/pull/11445#issuecomment-1035227434) on label being immutable. Any further heavy actions could go to the `resolve` method that's now available via the official Code API for hints)
Based on `@SomeoneToIgnore's` branch, with a couple of updates:
- I squashed, more or less successfully, the commits on that branch
- downloading the `.d.ts` no longer works, but you can get it manually from https://raw.githubusercontent.com/microsoft/vscode/release/1.64/src/vscode-dts/vscode.proposed.inlayHints.d.ts
- you might need to pass `--enable-proposed-api matklad.rust-analyzer`
- if I'm reading the definition right, `InlayHintKind` needs to be serialized as a number, not string
- this doesn't work anyway -- the client-side gets the hints, but they don't display
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
11639: internal: Re-arrange ide_db modules r=Veykril a=Veykril
Thins out the `helpers` module by giving some items more appropriate places to live
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
11598: feat: Parse destructuring assignment r=Veykril a=ChayimFriedman2
Part of #11532.
Lowering is not as easy and may not even be feasible right now as it requires generating identifiers: `(a, b) = (b, a)` is desugared into
```rust
{
let (<gensym_a>, <gensym_b>) = (b, a);
a = <gensym_a>;
b = <gensym_b>;
}
```
rustc uses hygiene to implement that, but we don't support hygiene yet.
However, I think parsing was the main problem as lowering will just affect type inference, and while `{unknown}` is not nice it's much better than a syntax error.
I'm still looking for the best way to do lowering, though.
Fixes#11454.
Co-authored-by: Chayim Refael Friedman <chayimfr@gmail.com>
11574: Small refactor text edit 2nd r=Veykril a=HansAuger
Some more changes to text_edit. Basic idea is to make `Indel` implement `PartialOrd` to take advantage of some sweet sweet iteration, most notably itertool's `merge`.
Co-authored-by: Moritz Vetter <mv@3yourmind.com>
11623: fix: Add type variable table to InferenceTableSnapshot r=flodiebold a=tysg
Fixes#11601.
I observed that removing the `rollback` line in 6fc3d3aa4c fixes the issue.
Looking at the stacktrace, I believe not restoring `type_variable_table` causes `type_variable_table` and `var_unification_table` to go out of sync, then when `hir_ty::infer::unify::InferenceTable::new_var` tries to extend `type_variable_table` to be the same length as `var_unification_table`, problems will arise.
However, I cannot pinpoint exactly how or where the vector capacity overflow happens, so my understanding might not be correct after all.
Co-authored-by: Tianyi Song <42670338+tysg@users.noreply.github.com>
11595: fix: lower string literals with actual value instead of default r=lnicola a=tysg
Fixes#11582. Some questions below in the code review section.
Co-authored-by: Tianyi Song <42670338+tysg@users.noreply.github.com>
11573: refactorings and FIXME fixes in text edit r=lnicola a=HansAuger
This is mainly me learning some rust, and only anecdotally about addressing some `fixme`s. Feel free to nope :)
There is a follow up PR in the pipeline which tackles the other two `fixme`s but it's a bit more invasive. So I wanted to get this out of the way
Co-authored-by: Moritz Vetter <mv@3yourmind.com>
11550: Refactor autoderef/method resolution r=flodiebold a=flodiebold
- don't return the receiver type from method resolution; instead just
return the autorefs/autoderefs that happened and repeat them. This
ensures all the effects like trait obligations and whatever we learned
about type variables from derefing them are actually applied. Also, it
allows us to get rid of `decanonicalize_ty`, which was just wrong in
principle.
- Autoderef itself now directly works with an inference table. Sadly
this has the effect of making it harder to use as an iterator, often
requiring manual `while let` loops. (rustc works around this by using
inner mutability in the inference context, so that things like unifying
types don't require a unique reference.)
- We now record the adjustments (autoref/deref) for method receivers
and index expressions, which we didn't before.
- Removed the redundant crate parameter from method resolution, since
the trait_env contains the crate as well.
- in the HIR API, the methods now take a scope to determine the trait env.
`Type` carries a trait env, but I think that's probably a bad decision
because it's easy to create it with the wrong env, e.g. by using
`Adt::ty`. This mostly didn't matter so far because
`iterate_method_candidates` took a crate parameter and ignored
`self.krate`, but the trait env would still have been wrong in those
cases, which I think would give some wrong results in some edge cases.
Fixes#10058.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
