bors [Mon, 10 Oct 2022 13:40:09 +0000 (13:40 +0000)]
Auto merge of #13384 - Veykril:macro-fallbacks, r=Veykril
Expand unmatched mbe fragments to reasonable default token trees
Currently we expand unmatched fragments by not replacing them at all, leaving us with `$ident`. This trips up the parser or subsequent macro calls. Instead it makes more sense to replace these with some reasonable default depending on the fragment kind which should make more recursive macro calls work better for completions.
Lukas Wirth [Mon, 10 Oct 2022 12:25:14 +0000 (14:25 +0200)]
Expand unmatched mbe fragments to reasonable default token trees
Currently we expand unmatched fragments by not replacing them at all,
leaving us with `$ident`. This trips up the parser or subsequent macro
calls. Instead it makes more sense to replace these with some reasonable
default depending on the fragment kind which should make more recursive
macro calls work better for completions.
bors [Mon, 10 Oct 2022 08:24:37 +0000 (08:24 +0000)]
Auto merge of #13303 - jplatte:convert-named-struct-to-tuple-struct, r=Veykril
Add convert_named_struct_to_tuple_struct assist
Closes #11643, since the assist for converting in the other direction is already there (I based most of the implementation and all of the tests on it).
bors [Mon, 10 Oct 2022 07:54:55 +0000 (07:54 +0000)]
Auto merge of #13367 - matklad:fix-problem-matchers, r=Veykril
fix: in VSCode, correctly resolve relative paths to errors
VS Code problem matcher are restricted to be static "regexes". You can't create a problem matcher dynamically, and you can't use custom code in lieu of problem matcher.
This creates a problem for rust/cargo compiler errors. They use paths relative to the root of the Cargo workspace, but VS Code doesn't necessary know where that root is.
Luckily, there's a way out: our current problem matcher is defined like this:
That means that relative pahts would be resoleved relative to workspace root. VS Code allows to specify a command inside `${}`. So we can plug custom logic there to fetch Cargo's workspace root!
bors [Mon, 10 Oct 2022 06:34:58 +0000 (06:34 +0000)]
Auto merge of #13376 - DropDemBits:strip-generic-bounds-and-defaults, r=Veykril
internal: Add `GenericParamList::to_generic_args` and `{TypeParam,ConstParam}::remove_default` APIs
Also fixes `generate_impl` not removing the default const param value, though it seems that no one has encountered or reported that issue yet 😅
This initially started out as refactoring `utils::generate_impl_text_inner` to understand it better (which was the reason for adding `{TypeParam,ConstParam}::remove_default`), but ended up also finding another place that needed `GenericParamList::to_generic_args`, hence its addition in here.
Aleksey Kladov [Sat, 8 Oct 2022 22:18:11 +0000 (23:18 +0100)]
fix: in VSCode, correctly resolve relative paths to errors
VS Code problem matcher are restricted to be static "regexes". You can't
create a problem matcher dynamically, and you can't use custom code in
lieu of problem matcher.
This creates a problem for rust/cargo compiler errors. They use paths
relative to the root of the Cargo workspace, but VS Code doesn't
necessary know where that root is.
Luckily, there's a way out: our current problem matcher is defined like
this:
That means that relative pahts would be resoleved relative to workspace
root. VS Code allows to specify a command inside `${}`. So we can plug
custom logic there to fetch Cargo's workspace root!
bors [Tue, 4 Oct 2022 18:26:43 +0000 (18:26 +0000)]
Auto merge of #13344 - lowr:patch/change-generic-param-order, r=Veykril
fix: use `BoundVar`s from current generic scope
Fixup for #13335, addresses https://github.com/rust-lang/rust-analyzer/pull/13339#issuecomment-1266654607
Before the change in generic parameter order, `BoundVar`s for trait reference didn't change whether you are in an impl's scope or in an associated item's scope. Now that item's generic params come before its parent's, we need to shift their indices when we are in an associated item's scope.
bors [Tue, 4 Oct 2022 06:18:57 +0000 (06:18 +0000)]
Auto merge of #13342 - rust-lang:revert-13328-rustc-proc-macro, r=Veykril
Revert "Add proc-macro dependency to rustc crates"
1. This panics since it indexes into the wrong thing, so fixes https://github.com/rust-lang/rust-analyzer/issues/13340
2. This didn't fix what I thought it would either
Reverts rust-lang/rust-analyzer#13328
bors [Mon, 3 Oct 2022 12:13:25 +0000 (12:13 +0000)]
Auto merge of #13335 - lowr:patch/change-generic-param-order, r=Veykril
internal: change generic parameter order
tl;dr: This PR changes the `Substitution` for trait items and methods like so:
```rust
trait Trait<TP, const CP: usize> { // note the implicit Self as first parameter
type Type<TC, const CC: usize>;
fn f<TC, const CC: usize>() {}
}
impl<TP, const CP: usize> S {
fn f<TC, const CC: usize>() {}
}
```
- before this PR: `[Self, TP, CP, TC, CC]` for each trait item, `[TP, CP, TC, CC]` for `S::f`
- after this PR: `[TC, CC, Self, TP, CP]` for each trait item, `[TC, CC, TP, CP]` for `S::f`
---
This PR "inverts" the generic parameters/arguments of an item and its parent. This is to fulfill [chalk's expectation](https://github.com/rust-lang/chalk/blob/d875af0ff196dd6430b5f5fd87a640fa5ab59d1e/chalk-solve/src/rust_ir.rs#L498-L502) on the order of generic arguments in `Substitution`s for generic associated types and it's one step forward for GATs support (hopefully). Although chalk doesn't put any constraint for other items, it feels more natural to get everything aligned than special casing GATs.
One complication is that `TyBuilder` now demands its users to pass in parent's `Substitution` upon construction unless it's obvious that the the item has no parent (e.g. an ADT never has parent). All users *should* already know the parent of the item in question, and without this, it cannot be easily reasoned about whether we're pushing the argument for the item or for its parent.
- 78977cd86cd17e008f94f8579d6a5aaebe46e69b: There's one major change here other than the generic param order: Default arguments are now bound by the same `Binder` as the item in question rather than a `Binder` limited to parameters they can refer to (i.e. arguments that syntactically appear before them). Now that the order of generic parameters is changed, it would be somewhat complicated to make such `Binder`s as before, and the "full" `Binder`s shouldn't be a problem because we already make sure that the default arguments don't refer to the generic arguments after them with `fallback_bound_vars()`.
Ryo Yoshida [Sun, 2 Oct 2022 12:13:21 +0000 (21:13 +0900)]
Change generic parameter/argument order
This commit "inverts" the order of generic parameters/arguments of an
item and its parent. This is to fulfill chalk's expectation on the
order of `Substitution` for generic associated types and it's one step
forward for their support (hopefully).
Although chalk doesn't put any constraint on the order of `Substitution`
for other items, it feels natural to get everything aligned rather than
special casing GATs.
One complication is that `TyBuilder` now demands its users to pass in
parent's `Substitution` upon construction unless it's obvious that the
the item has no parent (e.g. an ADT never has parent). All users
*should* already know the parent of the item in question, and without
this, it cannot be easily reasoned about whether we're pushing the
argument for the item or for its parent.
Quick comparison of how this commit changes `Substitution`:
Auto merge of #13311 - lowr:fix/for-loop-item-resolution, r=Veykril
fix: infer for-loop item type with `IntoIterator` and `Iterator`
Part of #13299
We've been inferring the type of the yielded values in for-loop as `<T as IntoIterator>::Item`. We infer the correct type most of the time when we normalize the projection type, but it turns out not always. We should infer the type as `<<T as IntoIterator>::IntoIter as Iterator>::Item`.
When one specifies `IntoIter` assoc type of `IntoIterator` but not `Item` in generic bounds, we fail to normalize `<T as IntoIterator>::Item` (even though `IntoIter` is defined like so: `type IntoIter: Iterator<Item = Self::Item>` - rustc does *not* normalize projections based on other projection's bound I believe; see [this playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=e88e19385094cb98fadbf647b4c2082e)).
Note that this doesn't fully fix # 13299 - given the following code, chalk can normalize `<I as IntoIterator>::IntoIter` to `S`, but cannot normalize `<S as Iterator>::Item` to `i32`.
```rust
struct S;
impl Iterator for S { type Item = i32; /* ... */ }
fn f<I: IntoIterator<IntoIter = S>>(it: I) {
for elem in it {}
//^^^^{unknown}
}
```
This is because chalk finds multiple answers that satisfy the query `AliasEq(<S as Iterator>::Item = ?X`: `?X = i32` and `?X = <I as IntoIterator>::Item` - which are supposed to be the same type due to the aforementioned bound on `IntoIter` but chalk is unable to figure it out.
Auto merge of #13237 - Veykril:process-changes, r=Veykril
Amalgamate file changes for the same file ids in process_changes
When receiving multiple change events for a single file id where the last change is a delete the server panics, as it tries to access the file contents of a deleted file. This occurs due to the VFS changes and the in memory file contents being updated immediately, while `process_changes` processes the events afterwards in sequence which no longer works as it will only observe the final file contents. By folding these events together, we will no longer try to process these intermediate changes, as they aren't relevant anyways.
Amalgamate file changes for the same file ids in process_changes
When receiving multiple change events for a single file id where the
last change is a delete the server panics, as it tries to access the
file contents of a deleted file. This occurs due to the VFS changes and
the in memory file contents being updated immediately, while
`process_changes` processes the events afterwards in sequence which no
longer works as it will only observe the final file contents. By
folding these events together, we will no longer try to process these
intermediate changes, as they aren't relevant anyways.
Auto merge of #13296 - Strum355:package-information-package-name, r=Veykril
Fix PackageInformation having the crate name instead of package name
The `PackageInformation` type from the LSIF PR used the _crate_ name instead of the _package_ name. This caused issues when looking up crates by this name on the Sourcegraph backend, where we sync crate contents, for crates such as actix-web and many of its components (actix-files, actix-http etc etc), see screenshot 1 for the observed symptom.
This PR hasnt been tested on other entry points besides cargo (such as project json).
See screenshot 2 for the change in behaviour via SCIP snapshot comparison.
![before and after from SCIP snapshot output](https://user-images.githubusercontent.com/18282288/192287733-d7e73ff0-abbc-4ae5-82d0-bf9dc45d755c.png)
</details>
Follow-up PR to my question over at the [rust-lang Zulip](https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer/topic/canonical.20crate.20name.20confusion.20for.20monikers), excuse any incorrect usages of the term package vs crate.
Auto merge of #13209 - lowr:feat/inference-for-generator, r=Veykril
feat: type inference for generators
This PR implements basic type inference for generator and yield expressions.
Things not included in this PR:
- Generator upvars and generator witnesses are not implemented. They are only used to determine auto trait impls, so basic type inference should be fine without them, but method resolutions with auto trait bounds may not be resolved correctly.
Open questions:
- I haven't (yet) implemented `HirDisplay` for `TyKind::Generator`, so generator types are just shown as "{{generator}}" (in tests, inlay hints, hovers, etc.), which is not really nice. How should we show them?
- I added moderate amount of stuffs to minicore. I especially didn't want to add `impl<T> Deref for &T` and `impl<T> Deref for &mut T` exclusively for tests for generators; should I move them into the test fixtures or can they be placed in minicore?
Auto merge of #13286 - Veykril:proc-macro-srv-tests, r=Veykril
Don't run proc-macro-srv tests on the rust-analyzer repo
proc-macro ABI breakage still affects the tests when a new stable version releases. Ideally we'd still be able to run the tests on the rust-analyzer repo without having to update the proc-macro ABI, but for now just to unblock CI we will ignore them here, as they are still run in upstream.
Don't run proc-macro-srv tests on the rust-analyzer repo
proc-macro ABI breakage still affects the tests when a new stable version
releases. Ideally we'd still be able to run the tests on the rust-analyzer
repo without having to update the proc-macro ABI, but for now just to
unblock CI we will ignore them here, as they are still run in upstream.
Auto merge of #12966 - OleStrohm:master, r=Veykril
feat: Display the value of enum variant on hover
fixes #12955
This PR adds const eval support for enums, as well as showing their value on hover, just as consts currently have.
I developed these two things at the same time, but I've realized now that they are separate. However since the hover is just a 10 line change (not including tests), I figured I may as well put them in the same PR. Though if you want them split up into "enum const eval support" and "show enum variant value on hover", I think that's reasonable too.
Since this adds const eval support for enums this also allows consts that reference enums to have their values computed now too.
The const evaluation itself is quite rudimentary, it doesn't keep track of the actual type of the enum, but it turns out that Rust doesn't actually either, and `E::A as u8` is valid regardless of the `repr` on `E`.
It also doesn't really care about what expression the enum variant contains, it could for example be a string, despite that not being allowed, but I guess it's up to the `cargo check` diagnostics to inform of such issues anyway?