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>
