11708: Update manual for inlay hint customization r=Veykril a=ian-h-chamberlain
Related to #6405, #6883 but not sure if they should be closed or not as this is just a documentation update.
This functionality was changed as of #11445 and now can be customized using native VSCode settings instead of `rust-analyzer`-specific ones.
Co-authored-by: Ian Chamberlain <ian-h-chamberlain@users.noreply.github.com>
11710: editors/code: fix crash due to missing ID= field r=lnicola a=cab404
Assuming ID=linux by default.
Also removed toLowerCase — it really shouldn't be needed.
Fixes#11709
Co-authored-by: Vladimir Serov <me@cab404.ru>
Assuming ID=linux in isNixOs by default. You can get away with
default "", but why do that if there's a default value in spec?)
Also removed toLowerCase — it really shouldn't be needed.
Fixes#11709
Closes#6883
This functionality was changed as of #11445 and now can be customized using native VSCode settings instead of `rust-analyzer`-specific ones.
11688: Add const generics r=HKalbasi a=HKalbasi
#7434 is not in this PR, so there is no evaluation of constants and no default const argument. But the rest (type inference and method resolution with chalk) should work.
Chalk is pedantic about kind of generic arguments, and will panic in case of mixing type and const arguments. I tried to add test that, but I'm not sure if it covers all cases.
Co-authored-by: hkalbasi <hamidrezakalbasi@protonmail.com>
11696: editors/code: fix nixos detection r=lnicola a=cab404
Problem: NixOS started using quotes around it's id field in /etc/os-release
Solution: Parially parsing os-release, and detecting, whether `nixos` appears anywhere in "ID=" field\
See https://github.com/rust-analyzer/rust-analyzer/issues/11695Closes#11695
Co-authored-by: Vladimir Serov <me@cab404.ru>
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.
11692: round of clippy fixes. r=Veykril a=matthiaskrgr
Split these up into smaller chunks so I can easily revert parts of it if needed.
Co-authored-by: Matthias Krüger <matthias.krueger@famsik.de>
- 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).
