Config revamp
Fixes https://github.com/rust-lang/rust-analyzer/issues/11790
Fixes https://github.com/rust-lang/rust-analyzer/issues/12115
This PR changes a lot of config names, and a few ones are being merged or split apart. The reason for this is that our configuration names currently are rather inconsistent and some where poorly chosen in regards to extensability. This PR plans to fix that.
We still allow the old config names by patching them to the new ones before deserializing to keep backwards compatability with other clients (the VSCode client will auto update the config) but ideally we will get rid of that layer in the future.
Here is a list of the changes:
These are simple renames `old_name | alias1 | alias2 ... -> new_name` (the vscode client will fix these up automagically):
```
assist_allowMergingIntoGlobImports -> imports_merge_glob
assist_exprFillDefault -> assist_expressionFillDefault
assist_importEnforceGranularity -> imports_granularity_enforce
assist_importGranularity | assist_importMergeBehavior | assist_importMergeBehaviour -> imports_granularity_group
assist_importGroup -> imports_group_enable
assist_importPrefix -> imports_prefix
cache_warmup -> primeCaches_enable
cargo_loadOutDirsFromCheck -> cargo_buildScripts_enable
cargo_runBuildScripts | cargo_runBuildScriptsCommand -> cargo_runBuildScripts_overrideCommand
cargo_useRustcWrapperForBuildScripts -> cargo_runBuildScripts_useRustcWrapper
completion_snippets -> completion_snippets_custom
diagnostics_enableExperimental -> diagnostics_experimental_enable
experimental_procAttrMacros -> procMacro_attributes_enable
highlighting_strings -> semanticHighlighting_strings_enable
highlightRelated_breakPoints -> semanticHighlighting_breakPoints_enable
highlightRelated_exitPoints -> semanticHighlighting_exitPoints_enable
highlightRelated_yieldPoints -> semanticHighlighting_yieldPoints_enable
highlightRelated_references -> semanticHighlighting_references_enable
hover_documentation -> hover_documentation_enable
hover_linksInHover | hoverActions_linksInHover -> hover_links_enable
hoverActions_debug -> hoverActions_debug_enable
hoverActions_enable -> hoverActions_enable_enable
hoverActions_gotoTypeDef -> hoverActions_gotoTypeDef_enable
hoverActions_implementations -> hoverActions_implementations_enable
hoverActions_references -> hoverActions_references_enable
hoverActions_run -> hoverActions_run_enable
inlayHints_chainingHints -> inlayHints_chainingHints_enable
inlayHints_closureReturnTypeHints -> inlayHints_closureReturnTypeHints_enable
inlayHints_hideNamedConstructorHints -> inlayHints_typeHints_hideNamedConstructorHints
inlayHints_parameterHints -> inlayHints_parameterHints_enable
inlayHints_reborrowHints -> inlayHints_reborrowHints_enable
inlayHints_typeHints -> inlayHints_typeHints_enable
lruCapacity -> lru_capacity
runnables_cargoExtraArgs -> runnables_extraArgs
runnables_overrideCargo -> runnables_command
rustcSource -> rustc_source
rustfmt_enableRangeFormatting -> rustfmt_rangeFormatting_enable
```
These are configs that have been merged or split apart, which have to be manually updated by the user:
```
callInfo_full -> signatureInfo_detail, signatureInfo_documentation_enable
cargo_allFeatures, cargo_features -> cargo_features
checkOnSave_allFeatures, checkOnSave_features -> checkOnSave_features
completion_addCallArgumentSnippets completion_addCallParenthesis -> completion_callable_snippets
```
Remove handling of `#[rustc_deprecated]`
This should be merged along with rust-lang/rust#95960.
Because the attribute still exists in rustc, I've left the definition here. With that said, any use of it is an error, so I've removed any handling of `#[rustc_deprecated]`.
fix: doc url link type
fix: #12033
I did some debugging and found the cause looks like to be some doc links' `LinkType` are kept as `Shortcut` which don't make sense for url links.
This PR should resolve both problems in the origin issue, but aside this PR, more work are needed for doc_links.
about `LinkType`: f29bd1e228/src/lib.rs (L191-L210)
improve the default constructor mode when filling fields
Instead of filling a boolean field with `bool::default()` it's not `false` and same for `Option` instead of using `Option::default()` it will be `None`
Collect obligations from RPITs (Return Position `impl Trait`) of a function which is being inferred.
This allows inferring {unknown}s from RPIT bounds.
fix: handle raw identifiers in move_module_to_file
Fixes#12045
Note that I special case'd mod named `r#mod` as commented in the code. Although it's very unlikely that one would use such name, I included it in this fix for the sake of completeness.
fix: Spawn a new thread with a larger stack for the LSP and proc-macro server
This runs the server and proc-macro process in dedicated threads with 8 MB of stack space to paper over OS differences and fix occasional stack overflows.
This hopefully resolves https://github.com/rust-lang/rust-analyzer/issues/11669
internal: Add a `NameContext` to `CompletionContext`, move out some ImmediateLocation variants
Continues the completion rewrite I started some time ago
(will merge tomorrow after stable since our completion tests still let a lot through)
fix: support `associated_const_equality` in parser
This pr fixes#11965. The parser now allows eq constraints on associated constants.
I've added tests for `HasCount<Count = {N}>` and `HasCount<Count = 0>`
feat: Add trailing `;` when typing `=` in assignment
This does have a false positive to keep in mind, it will add a trailing `;` in the following snippet too, which is probably not desired:
```rust
fn is_zero(i: i32) -> bool {
i $0 0
}
```
However, that function is unlikely to be written from the "inside out" like that, so it might be acceptable. Typically `=` is only inserted last when the author realizes that an existing expression should be assigned to some variable.
feat: allow customizing the command for running build scripts
I have tested this locally and it fixed#9201 with some small changes on the compiler side with suggestions from https://github.com/rust-analyzer/rust-analyzer/issues/9201#issuecomment-1019554086.
I have also added an environment variable `IS_RA_BUILDSCRIPT_CHECK` for crates to detect that it is a check for buildscripts, and allows defaulting to bogus values for expected environment variables.
11883: fix(ide): move moudle directory when rename r=rainy-me a=rainy-me
fix: #10992
Added `FileSystemEdit::MoveDir` variant for move dirs. Original implemented as recursively move child mod files but had many issues like
1. left empty dir after rename file
2. only affect rust file
3. not performant
so changed to current version
Co-authored-by: rainy-me <github@yue.coffee>
11964: internal: Show more project building errors to the user r=Veykril a=Veykril
Something very fishy is going on with the `rustc_workspace` handling, which caused this bug to only manifest in the `std` library but not other library crate... So there is either a bug there or just the fact that we seem to add duplicate dependencies (I think this is what we are doing with this right?) might be tripping something up somewhere.
cc https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer/topic/Rust-analyzer.20use.20inside.20stdlib
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
11953: fix: `extract_module` is too eager r=Veykril a=iDawer
Refactored `extract_module`.
Searching for usages and import resolving are done lazily.
Close#11944
Co-authored-by: iDawer <ilnur.iskhakov.oss@outlook.com>
- `T: ~const Drop` has a special meaning in Rust 1.61 that we don't implement.
(So ideally, we'd only ignore `~const Drop`, but this should be fine
for now.)
- `Destruct` impls are built-in in 1.62 (current nightlies as of 08-04-2022), so until
the builtin impls are supported by Chalk, we ignore them as well.
Since `Destruct` is implemented for everything in non-const contexts
IIUC, this should also work fine.
Fixes#11932.
11920: Consider types of const generics r=flodiebold a=HKalbasi
fix#11913
We should emit type_mismatch in const generics, probably after #7434. Currently they will lead to a misleading, time of use type error (like the added test).
Co-authored-by: hkalbasi <hamidrezakalbasi@protonmail.com>
11925: internal: Add and use `HirFormatter::write_{str,char}` r=Veykril a=lnicola
Saves slightly over 3 KB of `text`, but comparing the total with that from two weeks ago in #11776, this is a losing battle (we're 951 KB larger).
```
text data bss dec hex filename
24693512 1542704 4424 26240640 1906680 rust-analyzer-baseline
24690216 1542112 4424 26236752 1905750 rust-analyzer-pr
```
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
While we don't support const args in type inference yet, we can at least
make use of the fallback path resolution to resolve paths in const args
in the IDE layer to enable some features for them.
11905: internal: Remove hir_expand macro recursion check r=jonas-schievink a=jonas-schievink
This check is insufficient to ensure finite macro nesting, and so all callers already have their own recursion limit, which makes this check redundant.
...at least I hope it's redundant. Would be great if someone could double-check this.
Originally, this check was added in https://github.com/rust-analyzer/rust-analyzer/pull/3671
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
11891: Better error message on Flycheck Error message (from: unactionable error message if we are using `clippy` as the checker) r=Veykril a=flipbit03
I have commented on this [S-unactionable issue](https://github.com/rust-analyzer/rust-analyzer/issues/6589) that the Flycheck error message should maybe provide a hint about what tool it actually runs. Searching on some places on the Internet I've found multiple people, including myself, losing copious amounts of time on the same issue. So I've decided to make this very small PR :-)
From an user experience standpoint, the current error message is unhelpful to the end user, because the end user does not know exactly what it needs to check/fix (outdated, broken, or missing `cargo clippy`). In my own case, `cargo clippy` was actually missing altogether (developing off `rust:1.59.0-bullseye` official Docker image).
Thanks in advance!
Co-authored-by: Cadu <cadu.coelho@gmail.com>
11896: fix: Show the path to be created in the unresolved-module fix label r=Veykril a=Veykril
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
11894: complete pattern args based on type name r=Veykril a=cameron1024
Addresses #11892
Changes function argument completion to cover a case like this:
```rust
struct Foo { bar: i32 }
fn qux(Foo { bar }: Foo) {
println!("{bar}");
}
```
When completing the function call for `qux`, instead of expanding to `qux(_)`, it will now expand to `qux(foo)` (based on the snake-cased version of the name of the ADT)
Non ADTs are unaffected
Co-authored-by: cameron <cameron.studdstreet@gmail.com>
Co-authored-by: cameron1024 <cameron.studdstreet@gmail.com>
11865: Fix: Select correct insert position for disabled group import r=jonasbb a=jonasbb
The logic for importing with and without `group_imports` differed
significantly when no previous group existed. This lead to the problem
of using the wrong position when importing inside a module (#11585) or
when inner attributes are involved.
The existing code for grouped imports is better and takes these things
into account.
This PR changes the flow to use the pre-existing code for adding a new
import group even for the non-grouped import settings.
Some coverage markers are updated and the `group` is removed, since they
are now invoked in both cases (grouping and no grouping).
Tests are updated and two tests (empty module and inner attribute) are
added.
Fixes#11585
Co-authored-by: Jonas Bushart <jonas@bushart.org>
11699: feat: assist to remove unneeded `async`s r=Ethiraric a=Ethiraric
This should fix#11392
This PR adds a quickfix on functions marked with `async` that suggests, if and only if no `await` expression in find in the body of the function (it relies on `SyntaxNode::descendants()` to recursively traverse blocks), to remove the `async` keyword.
The lint is made so that it triggers only if the cursor is not in the body of the function, so that it does not pollute the quickfix list.
It does not trigger a diagnostic. I don't know if this repository is the place to implement those (`clippy`?). If it is, I would very much like pointers on where to start looking.
If there are test cases I haven't thought about, please do suggest.
Co-authored-by: Ethiraric <ethiraric@gmail.com>
10802: Allow clients to configure the global workspace search limit r=Veykril a=knutwalker
Playing around with [helix](https://helix-editor.com) I realized that the global worksapce symbol search works different compared to vs-code.
Helix requires all possible symbols in one query and does no subsequent refinement searched.
This PR adds a configuration option to override the default search limit with the default being the currently hardocded value.
Helix users can increment this limit for their instance with a config like
```toml
[[language]]
name = "rust"
language-server = { command = "rust-analyzer" }
[language.config]
workspace = { symbol = { search = { limit = 65536 }}}
```
Other editors are not affected by this change.
Co-authored-by: Paul Horn <dev@knutwalker.engineer>
11866: fix: Prevent underflow in range conversion r=Veykril a=skyfmmf
Previously, when line numbers of Rust spans were converted to LSP ranges, they could underflow resulting in very large line numbers. As an underflow is always wrong, prevent it and use 0 instead.
This was noticed when opening an empty file in `src/bin/` of a library crate. In this case rustc produces a span with `"line_start": 0, "line_end": 0` resulting in the underflow.
Co-authored-by: Felix Maurer <felix@felix-maurer.de>
11879: Suggest infered type in auto complete r=HKalbasi a=HKalbasi
fix#11855
It doesn't work for return types and consts (so their tests are failing) because I can't find their body node in the original file. (Are these original and fake file documented somewhere?)
Also it currently needs to type first character of the type (or manual ctrl+space) to open the auto complete panel, is it possible to open it automatically on typing `:` and `->`?
Co-authored-by: hkalbasi <hamidrezakalbasi@protonmail.com>
11877: fix: splitting path of a glob import wrongly adds `self` r=Veykril a=iDawer
Close #11703
`ast::UseTree::split_prefix` handles globs now.
Removed an extra branch for globs in `ide_db::imports::merge_imports::recursive_merge` (superseeded by split_prefix).
Co-authored-by: iDawer <ilnur.iskhakov.oss@outlook.com>
rustc has removed the use of lang items to mark the primitive impls, so
just look through the crate graph for them (this should be fine
performance-wise since we cache the crates that contain these impls).
Fixes#11876.
11878: fix: Paper over GAT panic r=flodiebold a=flodiebold
TIL that Chalk expects the arguments to a generic associated type to come *before* the ones for the parent trait, not *after* as we have been doing with all other nested generics. Fixing this requires a larger refactoring, so for now this just papers over the problem by completely ignoring parameters of associated types.
Fixes#11769.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
TIL that Chalk expects the arguments to a generic associated type to
come *before* the ones for the parent trait, not *after* as we have been
doing with all other nested generics. Fixing this requires a larger
refactoring, so for now this just papers over the problem by completely
ignoring parameters of associated types.
Fixes#11769.
11857: Lower postfix suggestions in completions list r=Veykril a=avrong
Fixes#11850
Adds a parameter for postfix suggestions in `CompletionRelevance`, and basing on it, decreases relevance score of such items in completion list
Co-authored-by: Aleksei Trifonov <avrong@avrong.me>
11870: Recover from missing type annotation r=Veykril a=HKalbasi
We were missing the init expression in case of `let x: = 2`, which breaks type inference of that variable (previously x were `{unknown}`, now it is `i32`).
Co-authored-by: hkalbasi <hamidrezakalbasi@protonmail.com>
11871: internal: Move `rust.ungram` into `rust-analyzer/crates/syntax` r=Veykril a=Veykril
This makes updating the grammar a lot simpler for us. Though removing it from ungrammar can't be done without bumping it to 2.0 so I'll leave it in there for the time being.
cc https://github.com/rust-analyzer/ungrammar/pull/47
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
`ast::UseTree::split_prefix` handles globs now.
Removed an extra branch for globs in `ide_db::imports::merge_imports::recursive_merge` (superseeded by split_prefix).
Previously, when line numbers of Rust spans were converted to LSP
ranges, they could underflow resulting in very large line numbers. As
an underflow is always wrong, prevent it and use 0 instead.
The logic for importing with and without `group_imports` differed
significantly when no previous group existed. This lead to the problem
of using the wrong position when importing inside a module (#11585) or
when inner attributes are involved.
The existing code for grouped imports is better and takes these things
into account.
This PR changes the flow to use the pre-existing code for adding a new
import group even for the non-grouped import settings.
Some coverage markers are updated and the `group` is removed, since they
are now invoked in both cases (grouping and no grouping).
Tests are updated and two tests (empty module and inner attribute) are
added.
Fixes#11585
When last expression in a function body is noreturn asm, then analyzer
complains about the type mismatch by highlighting entire body. This
fixes it by introducing loop {} in the expanded code.
Keep things consistent with the package.json , which uses `self` and
`crate` instead of `by_self` and `by_crate`. Both names are in fact
allowed as aliases, but we should be consistent so that people reading
the docs and using a schema do not see red squiggles.
E.g. when there's a type mismatch on the return value of a function. To
fix this, we have to return the expected type as the type of the block
when there's a mismatch. That meant some IDE code that expected
otherwise had to be adapted, in particular the "add return type" assist.
For the "wrap in Ok/Some" quickfix, this sadly means it usually can't be applied
in all branches of an if expression at the same time anymore, because
there's a type mismatch for each branch that has the wrong type.
11840: Fix another const generic panic r=flodiebold a=HKalbasi
fix#11835
If I change `dyn` to `impl` in the test, it will infer the type as `IntoIterator::Item<impl Iterator<Item = [Ar<u8, 7>; 9]> + ?Sized>` instead of `[Ar<u8, 7>; 9]`. Maybe it needs some action?
Co-authored-by: hkalbasi <hamidrezakalbasi@protonmail.com>
11809: feat: disable experimental diagnostics by default r=jonas-schievink a=jonas-schievink
Now that we diagnose type mismatches, we have another diagnostic that can potentially produce false positives, so let's disable experimental diagnostics by default.
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
11802: fix: add stubs to make proc macros work that use the `SourceFile` API r=jonas-schievink a=jonas-schievink
Helps with the rocket 0.4 macros, at least on some Rust versions.
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/11264
bors r+
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
11805: fix: Don't try to resolve methods on unknown types r=Veykril a=flodiebold
Fixes#10454, and some type mismatches.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
11791: fix: some fixes and improvements to signature help r=jonas-schievink a=jonas-schievink
bors r+
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
11789: fix: Fix lifetime elision hint configuration key r=Veykril a=Veykril
This is inconsistent with the other configuration keys unfortunately, but this is an issue of how we structured them here in general.
I feel like we'll have to do a proper pass over all the configs, check them for consistency and then write down some documentation of how our configs should be laid out, then apply fixes to the inconsistencies all at once which will entail breaking some user configurations unfortunately since we won't be able to do proper fallback handling for some of these.
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/11778
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
11786: fix: fill_match_arms doesn't add wildcard pat for local enums r=Veykril a=OleStrohm
Fix#11783
This adds similar logic to non_exhaustive as is currently on doc(hidden)
Co-authored-by: Ole Strohm <strohm99@gmail.com>
11780: feat: Add type mismatch diagnostic r=flodiebold a=flodiebold
This adds a proper diagnostic for type mismatches, turning "Add reference here", "Missing Ok or Some" and "Remove this semicolon" into quickfixes for this single diagnostic.
The diagnostic is marked as experimental when it does not have one of these quickfixes, so it can be turned off with `rust-analyzer.diagnostics.enableExperimental` (or specifically with `rust-analyzer.diagnostics.disabled` of course, the ID is `type-mismatch`).
There will still be some false positives, but I think there shouldn't be too many especially when the Chalk fix lands, and it's still experimental anyway 🙂
This also fixes type checking for `rustc_legacy_const_generics` just to avoid some errors in tests.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
11774: feat: Tag macro calls as unsafe if they expand to unsafe expressions r=Veykril a=Veykril
as long as they aren't inside an unsafe block inside the macro that is.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
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
Co-authored-by: Walther <veeti.haapsamo@gmail.com>
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.
Closes#11413.
Co-authored-by: Morgan Thomas <corp@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.
Closes#11413.
- 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).
- 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>
11573: refactorings and FIXME fixes in text edit r=lnicola a=HansAuger
This is mainly me learning some rust, and only anecdotally about addressing some `fixme`s. Feel free to nope :)
There is a follow up PR in the pipeline which tackles the other two `fixme`s but it's a bit more invasive. So I wanted to get this out of the way
Co-authored-by: Moritz Vetter <mv@3yourmind.com>
