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`)
11683: fix: Stop wrapping ConstParam's default values in ConstArg r=Veykril a=steven-joruk
I came across this problem while implementing the assist for inlining type aliases. This was causing `ConstParam::default_val` to always return `None` for block expressions. The `const_arg_path` test was actually testing const params so I've updated that.
The only code that uses `default_val` right now is the `extract_function` assist. I couldn't figure out how to hit the affected code path, if someone can give me hint I'll add a test.
This test in my WIP branch fails without this:
```rust
#[test]
fn param_expression() {
check_assist(
inline_type_alias,
r#"
type A<const N: usize = { 1 }> = [u32; N];
fn main() {
let a: $0A;
}
"#,
r#"
type A<const N: usize = { 1 }> = [u32; N];
fn main() {
let a: [u32; { 1 }];
}
"#,
);
}
```
Co-authored-by: Steven Joruk <steven@joruk.com>
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>
11672: Add support for new `where` clause location in associated types. r=Veykril a=Dirbaio
A recent Rust nightly changed it: https://github.com/rust-lang/rust/issues/89122
This allows both the old and new location.
Fixes#11651
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
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>
