Better handle type errors involving `Self` literals
When encountering a type error involving a `Self` literal, point at the self type of the enclosing `impl` and suggest using the actual type name instead.
```
error[E0308]: mismatched types
--> $DIR/struct-path-self-type-mismatch.rs:13:9
|
LL | impl<T> Foo<T> {
| - ------ this is the type of the `Self` literal
| |
| found type parameter
LL | fn new<U>(u: U) -> Foo<U> {
| - ------ expected `Foo<U>` because of return type
| |
| expected type parameter
LL | / Self {
LL | |
LL | | inner: u
LL | |
LL | | }
| |_________^ expected `Foo<U>`, found `Foo<T>`
|
= note: expected struct `Foo<U>`
found struct `Foo<T>`
= note: a type parameter was expected, but a different one was found; you might be missing a type parameter or trait bound
= note: for more information, visit https://doc.rust-lang.org/book/ch10-02-traits.html#traits-as-parameters
help: use the type name directly
|
LL | Foo::<U> {
| ~~~~~~~~
```
Fix#76086.
This was made possible by the removal of plugin support, which
simplified lint store creation.
This simplifies the places in rustc and rustdoc that call
`describe_lints`, which are early on. The lint store is now built before
those places, so they don't have to create their own lint store for
temporary use, they can just use the main one.
Fixed the `has_body()` function operator. Before that, this function was
returning false for all shims.
Change resolve_drop_in_place() to also return an instance for empty
shims, since they may still be required for vtable construction.
Add more APIs to retrieve information about types, and add more instance
resolution options.
Make `Instance::body()` return an Option<Body>, since not every instance
might have an available body. For example, foreign instances, virtual
instances, dependencies.
In cases like Kani, we will invoke the rustc_internal run command
directly for now. It would be handly to be able to have a callback
that can return a value.
We also need extra methods to convert stable constructs into internal
ones, so we can break down the transition into finer grain commits.
Building rustc with `--rust-profile-use` is currently dumping a lot of
warnings of "no profile data available for function" from `rustc_smir`
and `stable_mir`. These simply aren't exercised by the current profile-
gathering steps, but that's to be expected for new or experimental
functionality. I think for most people, these warnings will be just
noise, so it makes sense to only have them in verbose builds.
code: expose workspaces to other extensions; remove `addProject` command
This (mostly red) PR does three things:
- Exposes two methods to companion extensions (`setWorkspaces` and `notifyRustAnalyzer`).
- `setWorkspaces` is needed to update `linkedProjects` _without_ writing workspace/global configuration.
- `notifyRustAnalyzer` to get the server to pull the new configuration.
- Makes `Ctx` implement `RustAnalyzerExtensionApi` to prevent accidental regressions.
- Remove `rust-analyzer.addProject`, as that will live in a buck2 companion extension. No need for that to be in rust-analyzer!
I can see the utility of combining `notifyRustAnalyzer` and `setWorkspaces` into a single method (`updateWorkspacesAndNotify()`?), but I don't feel strongly about this. My feeling is that this API could be easily changed in the future.
Take into account implicit dereferences when suggesting fields.
```
error[E0609]: no field `longname` on type `Arc<S>`
--> $DIR/suggest-field-through-deref.rs:10:15
|
LL | let _ = x.longname;
| ^^^^^^^^ help: a field with a similar name exists: `long_name`
```
CC https://github.com/rust-lang/rust/issues/78374#issuecomment-719564114
