bors[bot] [Thu, 17 Mar 2022 16:28:21 +0000 (16:28 +0000)]
Merge #11743
11743: fix: Properly unify receivers during method resolution r=flodiebold a=flodiebold
This fixes our type inference problems with `DynMap`; the problem there were the projection types in
```rust
impl<P: Policy> KeyMap<Key<P::K, P::V, P>>
```
which messed up the naive type equality check we did. It also actually simplifies the logic though, IMO. I also added a fix for associated const resolution that I noticed (visibility not being taken into account).
bors[bot] [Thu, 17 Mar 2022 13:14:26 +0000 (13:14 +0000)]
Merge #11740
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
bors[bot] [Wed, 16 Mar 2022 16:35:34 +0000 (16:35 +0000)]
Merge #11694
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.
bors[bot] [Mon, 14 Mar 2022 11:15:00 +0000 (11:15 +0000)]
Merge #11688
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.
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/11695
Vladimir Serov [Sat, 12 Mar 2022 21:26:36 +0000 (00:26 +0300)]
editors/code: fix nixos detection
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/11695
Closes #11695
Morgan Thomas [Sat, 12 Mar 2022 16:44:37 +0000 (08:44 -0800)]
fix: "Extract to function" assist preserves `break` and `continue` labels
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.
Morgan Thomas [Sat, 12 Mar 2022 15:35:13 +0000 (07:35 -0800)]
- clean up match in ide_completion::completions::record::complete_record_literal
- 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
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:
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.
Morgan Thomas [Sat, 12 Mar 2022 02:26:01 +0000 (18:26 -0800)]
Complete enum variants identically to structures.
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).
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`)
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 }];
}
"#,
);
}
```
Steven Joruk [Fri, 11 Mar 2022 21:44:18 +0000 (21:44 +0000)]
refactor: Rename and move const_arg_path
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.
projects / rust.git / log