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.
</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?
Auto merge of #13264 - lowr:patch/no-dyn-without-trait, r=Veykril
Ensure at least one trait bound in `TyKind::DynTy`
One would expect `TyKind::DynTy` to have at least one trait bound, but we may produce a dyn type with no trait bounds at all. This patch prevents it by returning `TyKind::Error` in such cases.
An "empty" dyn type would have caused panic during method resolution without #13257. Although already fixed, I think an invariant to never produce such types would help prevent similar problems in the future.
projects / rust.git / log