Morgan Thomas [Sat, 12 Mar 2022 01:17:01 +0000 (17:17 -0800)]
- Break out functionality related to rendering struct completions into `crates/ide_completion/src/render/compound.rs`
- 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`)
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`
bors[bot] [Wed, 9 Mar 2022 10:26:34 +0000 (10:26 +0000)]
Merge #11663
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.
bors[bot] [Mon, 7 Mar 2022 16:49:12 +0000 (16:49 +0000)]
Merge #11445
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
bors[bot] [Sun, 6 Mar 2022 12:22:35 +0000 (12:22 +0000)]
Merge #11633
11633: Automatically change text color in logo based on dark mode r=Veykril a=arzg
Currently the black text in the logo in the README just has a white stroke so it’s readable in dark mode. This PR adds automatic detection of whether the user is using system dark mode, and if they are changes the text colour to white and removes the stroke.
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.
bors[bot] [Sat, 5 Mar 2022 11:20:05 +0000 (11:20 +0000)]
Merge #11574
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`.
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>
This implements the first approach of https://github.com/rust-analyzer/rust-analyzer/issues/8860#issuecomment-845461773:
> treat every Local as having potentially many sources?
The way this is written does allow changing to a MultiLocal approach instead though, I'll investigate whether that turns out to be better or not.
bors[bot] [Fri, 4 Mar 2022 12:55:07 +0000 (12:55 +0000)]
Merge #11140
11140: Preserve order of generic args r=HKalbasi a=HKalbasi
https://github.com/rust-lang/rust/pull/90207 removed order restriction of generic args, i.e. const generics can now become before of type generics. We need to preserve this order to analyze correctly, and this PR does that.
It also simplifies implementation of const generics a bit IMO.
Implementing default generics the same problem of #7434, we need lower them to body and then evaluate them.
projects / rust.git / log