feat: Diagnose some incorrect usages of the question mark operator
Trying to figure out how the type stuff in r-a works some more, I think I am doing this correct here but I am not quite sure :)
Bump chalk
There's a bug in current chalk that prevents us from properly supporting GATs, which is supposed to be fixed in v0.86. Note the following:
- v0.86 is only going to be released next Sunday so I'll keep this PR as draft until then.
- This doesn't compile without https://github.com/rust-lang/chalk/pull/779, which I hope will be included in v0.86. I confirmed this compiles with it locally.
Two breaking changes from v0.84:
- `TypeFolder` has been split into `TypeFolder` and `FallibleTypeFolder` (https://github.com/rust-lang/chalk/pull/772)
- `ProjectionTy::self_type_parameter()` has been removed (https://github.com/rust-lang/chalk/pull/778)
Two breaking changes:
- `TypeFolder` has been split into `TypeFolder` and `FallibleTypeFolder`
- `ProjectionTy::self_type_parameter()` has been removed
feat: Autocomplete Cargo-defined env vars in `env!` and `option_env!` (#12448)
Closes#12448
Important to know:
- Variables are taken from https://doc.rust-lang.org/cargo/reference/environment-variables.html and hardcoded as a const array.
- For the sake of simplicity I didn't include the autocompletion of `CARGO_BIN_EXE_<name>` and `OUT_DIR` since it would require information about build.rs and binary name. If somebody knows an easy way of obtaining them I can add those vars as well :)
fix: reorder dyn bounds on render
Fixes#13368#13192 changed the order of dyn bounds, violating the [contract](3a69435af7/crates/hir-ty/src/display.rs (L896-L901)) with `write_bounds_like_dyn_trait()` on render. The projection bounds are expected to come right after the trait bound they are accompanied with.
Although the reordering procedure can be made a bit more efficient, I opted for relying only on the [invariants](3a69435af7/crates/hir-ty/src/lower.rs (L995-L998)) currently documented in `lower_dyn_trait()`. It's not the hottest path and dyn bounds tend to be short so I believe it shouldn't hurt performance noticeably.
Use $crate instead of std for panic builtin_fn_macro
This should be closer to the expected output and gets rid of a few type mismatches in rustc/library
Refactor completions expansion
Depends on https://github.com/rust-lang/rust-analyzer/pull/13384
Diff is unfortunately massive as I changed the functions in the analysis module from associated ones to standalone (unfortunately without an extra commit)
Don't report build-scripts and proc-macros as metadata progress
Seems somewhat confusing to me, given `metadata` is already the step we do for workspace loading
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.
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.
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).
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.
The main change here should be that flags are not inhereted, so
$ rust-analyzer analysis-stats . -v -v
would do what it should do
We also no longer Don\'t
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.
fix: treat enum variants as generic item on their own
Fixup for #13335
It turns out I tried to merge two procedures into one utility function without noticing the incompatibility.
This time I *did* run analysis-stats on the four crates and confirmed it doesn't crash and this patch doesn't cause regression.
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](d875af0ff1/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.
Some additional notes:
- f8f5a5ea57: This isn't related to the change, but I felt it's nicer.
- 78977cd86c: 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()`.
- 7556f74b16: This is split from 4385d3dcd0 to make it easy to revert if it turns out that the GATs with const generics panic is actually not resolved with this PR. cc #11878#11957
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`:
```rust
trait Trait<TP, const CP: usize> {
type Type<TC, const CC: usize> = ();
fn f<TC, const CC: usize>() {}
}
```
- before this commit: `[Self, TP, CP, TC, CC]` for each trait item
- after this commit: `[TC, CC, Self, TP, CP]` for each trait item
