| Age | Commit message (Collapse) | Author | Lines |
|---|
|
More correctly, a `TyKind::AssociatedType` is not the same as `TyKind::Projection`.
We used to map next-solver `TyKind::Alias` to Chalk's `TyKind::AssociatedType`. This is very incorrect, as `AssociatedType` is assumed to be fully normalized, and caused a lot of type mismatches.
Unfortunately fixing this causes a lot of stack overflows, because the next solver doesn't have something akin to `AssociatedType` so we normalize again and again. The reason is that is the lazy-normalization nature of the next solver, which means we need to stop normalizing everything. This will be fixed in the next commit.
|
|
Migrate `InferenceTable` into next-solver
|
|
|
|
|
|
Fix LifetimeParam::lifetime_bounds invalid implement
|
|
Add a FAQ entry about RA and Cargo build lock/cache conflicts
|
|
Lifetime node example:
```
LIFETIME_PARAM@15..21
LIFETIME@15..17
LIFETIME_IDENT@15..17 "'a"
COLON@17..18 ":"
WHITESPACE@18..19 " "
TYPE_BOUND_LIST@19..21
TYPE_BOUND@19..21
LIFETIME@19..21
LIFETIME_IDENT@19..21 "'b"
```
|
|
|
|
|
|
feat: support navigation on primitives
|
|
|
|
|
|
|
|
Clarify intro in README and manual
|
|
The first sentence a new user should see should ideally answer the
questions:
* What is rust-analyzer?
* Why might I want to use it?
The vast majority of users will be interested in using rust-analyzer
inside their favourite editor. We should clarify that rust-analyzer is
an LSP implementation and that it supports all the classic IDE
features.
Whilst it's also true that rust-analyzer is modular and organised into
libraries, the first impression should (I think) focus on an overview
and the primary use case.
|
|
Remove support for register_attr
|
|
|
|
This was removed in rustc in 2022: https://github.com/rust-lang/rust/pull/101123
Closes #20525.
|
|
fix: add `else` keyword completion after `let` statements
|
|
Improve make::struct_ field_list whitespace
|
|
Example
---
**Before this PR**:
```rust
struct Variant{
field: u32
}
```
**After this PR**:
```rust
struct Variant {
field: u32
}
```
|
|
Example
---
```rust
fn foo() {
let _ = 2 el$0
}
```
->
```rust
fn foo() {
let _ = 2 else {
$0
};
}
```
|
|
internal: Upgrade rustc crates
|
|
The main changes are (there are some other small changes):
- Using a specific type for trait IDs in the new solver, allowing us to simplify a lot of code.
- Add `BoundConst` similar to `BoundTy` and `BoundRegion` (previously consts used `BoundVar` directly), due to a new trait requirement.
|
|
internal: Add a regression test for a fixed new trait solver bug
|
|
fix: Fix typo in config
|
|
Not sure what exactly fixed it, but why not.
|
|
To make it backwards-compatible.
|
|
fix: Make sense of the mess that were (are) different kind of generics in the solver
|
|
fix: Deduplicate methods in completion by function ID and not by name
|
|
Because duplicates can be found with traits. Worse, the inherent methods could be private, and we'll discover that only later. But even if they're not they're different methods, and its seems worthy to present them all to the user.
|
|
To the extent possible.
Previously they were confused. Sometimes generic params were treated as `Param` and sometimes as `Placeholder`. A completely redundant (in the new solver) mapping of salsa::Id to ints to intern some info where we could just store it uninterned (not in Chalk though, for some weird reason).
Plus fix a cute bug in closure substitution that was caught by the assertions of Chalk but the next solver did not have such assertions. Do we need more assertions?
|
|
fix: Avoid `--target` option being given twice to `rustc` when invoked through `cargo rustc` while fetching target data layout
|
|
|
|
fix: When mapping next-solver's `dyn` type, add `Self` (aka. bound var ^1.0) to auto traits' substitutions
|
|
rust-lang/dependabot/cargo/tracing-subscriber-0.3.20
Bump tracing-subscriber from 0.3.19 to 0.3.20
|
|
Bumps [tracing-subscriber](https://github.com/tokio-rs/tracing) from 0.3.19 to 0.3.20.
- [Release notes](https://github.com/tokio-rs/tracing/releases)
- [Commits](https://github.com/tokio-rs/tracing/compare/tracing-subscriber-0.3.19...tracing-subscriber-0.3.20)
---
updated-dependencies:
- dependency-name: tracing-subscriber
dependency-version: 0.3.20
dependency-type: direct:production
...
Signed-off-by: dependabot[bot] <support@github.com>
|
|
fix: Add progress bars to more places in analysis-stats
|
|
auto traits' substitutions
Chalk represents dyn types as a list of predicate, the self type should be there. The next solver represents them quite differently. The `Self` was forgotten for the auto trait case.
|
|
minor: Don't require a full `InferenceTable` for `CastTy`
|
|
A DB is enough.
|
|
Namely, mir lowering, const eval and IDE things.
|
|
fix: Attach the db in one more place in highlighting
|
|
|
|
fix: In highlight_related, when on an unsafe block, don't highlight unsafe operations of other unsafe blocks
|
|
perf: Cache trait solving across queries in the same revision
|
|
operations of other unsafe blocks
|
|
fix: Remove `SolverDefId::ForeignId`
|
|
Replace it with normal `SolverDefId::TypeAliasId`.
The split caused a very funny bug where code was getting `TypeAliasId` where it expected `ForeignId`, because `TypeAliasId` had a `From` impl from `hir_def::TypeAliasId` and `ForeignId` had not, plus a careless `into()`.
I could've fixed this specific bug but opted to remove the split instead; currently, it just provides more room for bugs, as we don't have typed IDs for the solver anyway, and even when we'll have (hopefully), that doesn't seem like a very useful distinction, for example in hir-def foreign types are just `TypeAliasId` with some flags.
Constructing a test for this isn't trivial; the trivial test (creating a foreign type, even proving a trait bound for it) fails to fail before the change, probably because we don't use the new solver everywhere yet so we don't trigger this specific code path.
|
|
Enable warning logs by default
|
