minor: Allow multiple snippet edits in a `TextDocumentEdit`
Explicitly[^1] allow a single `TextDocumentEdit` to have multiple `SnippetTextEdit`s. This allows things like renaming extracted variables and functions without having to go through a separate rename step. For an example of what this looks like, see the video in [this comment](https://github.com/microsoft/vscode/issues/145374#issuecomment-1177341711).
The behavior described here lines up with [what VSCode does](bdc113ffe1/src/vscode-dts/vscode.d.ts (L3728-L3731)), and presumably what the eventual LSP behavior will be.
[^1]: This was technically the case before #15269, a single `TextDocumentEdit` always had multiple edits which were `InsertTextFormat.Snippet` as all of the edits were marked as being snippets, even if there weren't any tab stops or placeholders.
minor: Make "Expand macro" command title more explicit
Closes [#15856](https://github.com/rust-lang/rust-analyzer/issues/15856).
I opted for "caret", since it's the better term (cursor is the mouse), but I'm not sure how popular it is these days.
This is a aspect of Rust that frequently trips up people who are not
aware of it yet. This diagnostic attempts to explain what's happening
and why the lifetime constraint, that was never mentioned in the source,
arose.
Lint `needless_borrow` and `explicit_auto_deref` on most union field accesses
Changes both lints to follow rustc's rules around auto-deref through `ManuallyDrop` union fields rather than just bailing on union fields.
changelog: [`needless_borrow`] & [`explicit_auto_deref`]: Lint on most union field accesses
As the .last-warned-change-id is only used for change tracking,
we don't need to generate/write it outside of the tty.
Otherwise, rust-analyzer could create this file, and developers
wouldn't be able to see the bootstrap change alerts, assuming
that they have already seen them.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
This method is trying to detect macro invocations, so that it can split a span
into two parts just after the `!` of the invocation.
Under some circumstances (probably involving nested macros), it gets confused
and produces a span that is larger than the original span, and possibly extends
outside its enclosing function and even into an adjacent file.
In extreme cases, that can result in malformed coverage mappings that cause
`llvm-cov` to fail. For now, we at least want to detect these egregious cases
and avoid them, so that coverage reports can still be produced.
Deny more `~const` trait bounds
thereby fixing a family of ICEs (delayed bugs) for `feature(const_trait_impl, effects)` code.
As discussed
r? `@fee1-dead`
Allow adding values to the `!llvm.module.flags` metadata for a generated
module. The syntax is
`-Z llvm_module_flag=<name>:<type>:<value>:<behavior>`
Currently only u32 values are supported but the type is required to be
specified for forward compatibility. The `behavior` element must match
one of the named LLVM metadata behaviors.viors.
This flag is expected to be perma-unstable.
Due to the way the current tree mutation api works, we need to collect
changes before we can apply them to the real syntax tree, and also can only
switch to a file once.
`destructure_tuple_binding_in_sub_pattern` also gets migrated even
though can't be used.
Now that cranelift is distributed with Rustup, I find myself constantly searching for the https://github.com/rust-lang/rust/pull/81746 PR. I think that it would be useful to also describe the Rustup installation/usage instructions here in README.
Add `std:#️⃣:{DefaultHasher, RandomState}` exports (needs FCP)
This implements rust-lang/libs-team#267 to move the libstd hasher types to `std::hash` where they belong, instead of `std::collections::hash_map`.
<details><summary>The below no longer applies, but is kept for clarity.</summary>
This is a small refactor for #27242, which moves the definitions of `RandomState` and `DefaultHasher` into `std::hash`, but in a way that won't be noticed in the public API.
I've opened rust-lang/libs-team#267 as a formal ACP to move these directly into the root of `std::hash`, but for now, they're at least separated out from the collections code in a way that will make moving that around easier.
I decided to simply copy the rustdoc for `std::hash` from `core::hash` since I think it would be ideal for the two to diverge longer-term, especially if the ACP is accepted. However, I would be willing to factor them out into a common markdown document if that's preferred.
</details>
