internal: Migrate assists to the structured snippet API, part 7/7
Continuing from #16467
Migrates the following assists:
- `generate_trait_from_impl`
This adds `add_placeholder_snippet_group`, which adds a group of placeholder snippets which are linked together and allows for renaming generated items without going through a separate rename step.
This also removes the last usages of `SourceChangeBuilder::{insert,replace}_snippet`, as all assists have finally been migrated to the structured snippet versions of those methods.
The eventual LSP representation looks like it will diverge from RA's representation of `SnippetTextEdit`s, so this'll make it easier to transition to the LSP representation later.
The `lsp-server` crate is currently published without license files, which is
needed when packaging in Linux distributions.
Symlink the files from the repository root so they are kept in sync.
Test showing the files get picked up by `cargo package`:
```
michel in rust-analyzer/lib/lsp-server on add-lsp-server-license [+] is 📦 v0.7.6 via 🐍 v3.12.1 (.venv311) via 🦀 v1.76.0
⬢ [fedora:39] ❯ cargo package --allow-dirty --no-verify
Updating crates.io index
Packaging lsp-server v0.7.6 (/home/michel/src/github/rust-lang/rust-analyzer/lib/lsp-server)
Updating crates.io index
Packaged 12 files, 59.6KiB (16.3KiB compressed)
michel in rust-analyzer/lib/lsp-server on add-lsp-server-license [+] is 📦 v0.7.6 via 🐍 v3.12.1 (.venv311) via 🦀 v1.76.0
⬢ [fedora:39] ❯ tar tf ../../target/package/lsp-server-0.7.6.crate | grep LICENSE
lsp-server-0.7.6/LICENSE-APACHE
lsp-server-0.7.6/LICENSE-MIT
```
Signed-off-by: Michel Lind <salimma@fedoraproject.org>
When we try to extract coverage-relevant spans from MIR, sometimes we see MIR
statements/terminators whose spans cover the entire function body. Those spans
tend to be unhelpful for coverage purposes, because they often represent
compiler-inserted code, e.g. the implicit return value of `()`.
doc: add note about panicking examples for strict_overflow_ops
The first commit adds a note before the panicking examples for strict_overflow_ops to make it clearer that the following examples should panic and why, without needing the reader to hover the mouse over the information icon.
The second commit adds panicking examples for division by zero operations for strict division operations on unsigned numbers. The signed numbers already have two panicking examples each: one for division by zero and one for overflowing division (`MIN/-1`); this commit includes the division by zero examples for the unsigned numbers.
Only point out non-diverging arms for match suggestions
Fixes#121144
There is no reason to point at diverging arms, which will always coerce to whatever is the match block's evaluated type.
This also removes the suggestion from #106601, since as I pointed out in https://github.com/rust-lang/rust/issues/72634#issuecomment-1946210898 the added suggestion is not firing in the right cases, but instead only when one of the match arms already *actually* evaluates to `()`.
r? estebank
Make `async Fn` trait kind errors better
1. Make it so that async closures with the wrong closurekind actually report a useful error
2. Explain why async closures can sometimes not implement `Fn`/`FnMut` (because they capture things)
r? oli-obk
Add an ErrorGuaranteed to ast::TyKind::Err (attempt 2)
This makes it more like `hir::TyKind::Err`, and avoids a `has_errors` assertion in `LoweringContext::lower_ty_direct`.
r? ```@oli-obk```
Add extra indent spaces for rust-playground link
Fixes#120998
Seems add `rustfmt` for this is somehow too heavy,
only adding indent spaces at the starting of each line of code seems good enough.
Consider principal trait ref's auto-trait super-traits in dyn upcasting
Given traits like:
```rust
trait Subtrait: Supertrait + Send {}
trait Supertrait {}
```
We should be able to upcast `dyn Subtrait` to `dyn Supertrait + Send`. This is not currently possible, because when upcasting, we look at the list of auto traits in the object type (`dyn Subtrait`, which has no auto traits in its bounds) and compare them to the target's auto traits (`dyn Supertrait + Send`, which has `Send` in its bound).
Since the target has auto traits that are not present in the source, the upcasting fails. This is overly restrictive, since `dyn Subtrait` will always implement `Send` via its built-in object impl. I propose to loosen this restriction here.
r? types
---
### ~~Aside: Fix this in astconv instead?~~
### edit: This causes too many failures. See https://github.com/rust-lang/rust/pull/119825#issuecomment-1890847150
We may also fix this by by automatically elaborating all auto-trait supertraits during `AstConv::conv_object_ty_poly_trait_ref`. That is, we can make it so that `dyn Subtrait` is elaborated into the same type of `dyn Subtrait + Send`.
I'm open to considering this solution instead, but it would break coherence in the following example:
```rust
trait Foo: Send {}
trait Bar {}
impl Bar for dyn Foo {}
impl Bar for dyn Foo + Send {}
//~^ This would begin to be an overlapping impl.
```
Waker::will_wake: Compare vtable address instead of its content
Optimize will_wake implementation by comparing vtable address instead of its content.
The existing best practice to avoid false negatives from will_wake is to define a waker vtable as a static item. That approach continues to works with the new implementation.
While this potentially changes the observable behaviour, the function is documented to work on a best-effort basis. The PartialEq impl for RawWaker remains as it was.
