feat: render patterns in params for hovering
Fix#17858
This PR introduces an option to [hir-def/src/body/pretty.rs](08c7bbc2db/crates/hir-def/src/body/pretty.rs) to render the result as a single line, which is then reused for rendering patterns in parameters for hovering.
assist: ensure `replace_qualified_name_with_use` applies to the first path segment
This change helps a bit with the discoverability of `replace_qualified_name_with_use`. Specifically, it ensures that a cursor on the first path segment (e.g., `$0std::fmt::Debug`, where `$0` is the cursor) would result in an import along the lines of `use std::fmt;` and `fmt::Debug;` at the usage sites.
internal: Better testing infra for ratoml
This PR makes some improvements on how we test configs that come from `rust-analyzer.toml` files.
It was primarily used to solve #18021 but along the way I could not really determine the cause of the said issue which makes me think that it may not be related to the changes that I made earlier to the ratoml infra. In either way `custom_snippets` are now made `global` because we still don't have a tree that maps a `SourceRootId` to a set of `Snippet`s.
fix: Fix `inline_const_as_literal` error when the number >= 10
## Description
### The Bug
This PR fixes a small bug in the IDE assistence (`inline_const_as_literal`). When the being-inlined constant is a number and it is greater than or equal to 10, the assistence inserts unexpected string `(0x...)` after the number itself. A simple example is followed:
Current `inline_const_as_literal` changes
```rs
const A: usize = 16;
fn f() -> usize {
A // inline the constant
}
```
into
```rs
const A: usize = 16;
fn f() -> usize {
16 (0x10)
}
```
The bug originates from #14925 & #15306 . #14925 added some unittests, but it just tested the number-inlining behavior when the number is `0`.
50882fbfa2/crates/ide-assists/src/handlers/inline_const_as_literal.rs (L124-L138)
And #15306 modified the behavior of `Const::render_eval` and added the `(0x...)` part after the number (if the number >= `10`). Because of insufficient unittests in #14925, changes about `Const::render_eval` in #15306 introduced this bug with no CI failure.
### The Fix
I think `Const::render_eval` is intended for user-facing value displaying (e.g. hover) and not designed for `inline_const_as_literal`. To fix the bug, I defined a new function named `Const::eval`, which evaluates the value itself faithfully and simply and does nothing else.
## Thanks
Thanks `@roife` for your kind help. Your guidance helped me better understand the code.
feat: Automatically add semicolon when completing unit-returning functions
But provide a config to suppress that.
I didn't check whether we are in statement expression position, because this is hard in completion (due to the natural incompleteness of source code when completion is invoked), and anyway using function returning unit as an argument to something seems... dubious.
Fixes#17263.
assist: ensure `replace_qualified_name_with_use` applies to the first path segment
This change helps a bit with the discoverability of `replace_qualified_name_with_use`. Specifically, it ensures that a cursor on the first path segment (e.g., `$0std::fmt::Debug`, where `$0` is the cursor) would result in an import along the lines of `use std::fmt;` and `fmt::Debug;` at the usage sites.
Skip checks for cast to dyn traits
It seems that chalk fails to solve some obvious goals when there are some recursiveness in trait environments.
And it doesn't support trait upcasting yet. rust-lang/chalk#796
This PR just skips for casting into types containing `dyn Trait` to prevent false positive diagnostics like #18047 and #18083
Enumerate lint expectations using AttrId
This PR implements the idea I outlined in https://github.com/rust-lang/rust/issues/127884#issuecomment-2240338547
We can uniquely identify a lint expectation `#[expect(lint0, lint1...)]` using the `AttrId` and the index of the lint inside the attribute. This PR uses this property in `check_expectations`.
In addition, this PR stops stashing expected diagnostics to wait for the unstable -> stable `LintExpectationId` mapping: if the lint is emitted with an unstable attribute, it must have been emitted by an `eval_always` query (like inside the resolver), so won't be loaded from cache. Decoding an `AttrId` from the on-disk cache ICEs, so we have no risk of accidentally checking an expectation.
Fixes https://github.com/rust-lang/rust/issues/127884
cc `@xFrednet`
fix: Correctly escape strings in our quote macro
This is a small change, but it was the cause of 90% of the errors in `rust-analyzer diagnostics .` 🫢 (because this worked incorrectly with `stringify!()`, which means every `quote!()` (the original one) quoting a string also didn't work).
With this change and #18085 together, all remaining errors are type errors.
This may mean we can enable more errors, but this is out of scope for this PR.
This is a small change, but it was the cause of 90% of the errors in `rust-analyzer diagnostics .` 🫢
With this change and #18085 together, all remaining errors are type errors.
This may mean we can enable more errors, but this is out of scope for this PR.
Also emit `missing_docs` lint with `--test` to fulfil expectations
This PR removes the "test harness" suppression of the `missing_docs` lint to be able to fulfil `#[expect]` (expectations) as it is now "relevant".
I think the goal was to maybe avoid false-positive while linting on public items under `#[cfg(test)]` but with effective visibility we should no longer have any false-positive.
Another possibility would be to query the lint level and only emit the lint if it's of expect level, but that is even more hacky.
Fixes https://github.com/rust-lang/rust/issues/130021
try-job: x86_64-gnu-aux
internal: Add preliminary `SyntaxEditor` functionality
Related to #15710
Implements a `SyntaxEditor` interface to abstract over the details of modifying syntax trees, to both simplify creating new code fixes and code actions, as well as start on the path of getting rid of mutable syntax nodes.
`SyntaxEditor` relies on `SyntaxMappingBuilder`s to feed in the correct information to map AST nodes created by `make` constructors, as `make` constructors do not guarantee that node identity is preserved. This is to paper over the fact that `make` constructors simply re-parse text input instead of building AST nodes from the ground up and re-using the provided syntax nodes.
`SyntaxAnnotation`s are used to find where syntax elements have ended up after edits are applied. This is primarily useful for the `add_{placeholder,tabstop}` set of methods on `SourceChangeBuilder`, as that currently relies on the nodes provided being in the final syntax tree.
Eventually, the goal should be to move this into the `rowan` crate when we move away from mutable syntax nodes, but for now it'll stay in the `syntax` crate.
---
Closes#14921 as `SyntaxEditor` ensures that all replace changes are disjoint
Closes#9649 by implementing `SyntaxAnnotation`s
rustdoc rfc#3662 changes under unstable flags
* All new functionality is under unstable options
* Adds `--merge=shared|none|finalize` flags
* Adds `--parts-out-dir=<crate specific directory>` for `--merge=none`
to write cross-crate info file for a single crate
* Adds `--include-parts-dir=<previously specified directory>` for
`--merge=finalize` to write cross-crate info files
* `tests/rustdoc/` tests for the new flags
Distribute rustc_codegen_cranelift for Windows
With support for raw-dylib recently added to cg_clif, and inline assembly support working on Windows for quite a while now, all blockers for distributing cg_clif on Windows that I mentioned in https://github.com/rust-lang/rust/pull/81746#issuecomment-1774099637 are fixed now.
feat: better name suggestions for fn
fix#17631.
Better name suggestions for fn-calls / method-calls in the form of `from()`, `from_xxx()`, `into()`, etc.
Correctly handle stability of `#[diagnostic]` attributes
This commit changes the way we treat the stability of attributes in the
`#[diagnostic]` namespace. Instead of relaying on ad-hoc checks to
ensure at call side that a certain attribute is really usable at that
location it centralises the logic to one place. For diagnostic
attributes comming from other crates it just skips serializing
attributes that are not stable and that do not have the corresponding
feature enabled. For attributes from the current crate we can just use
the feature information provided by `TyCtx`.
r? `@compiler-errors`
But provide a config to suppress that.
I didn't check whether we are in statement expression position, because this is hard in completion (due to the natural incompleteness of source code when completion is invoked), and anyway using function returning unit as an argument to something seems... dubious.
Break into the debugger (if attached) on panics (Windows, Linux, macOS, FreeBSD)
The developer experience for panics is to provide the backtrace and
exit the program. When running under debugger, that might be improved
by breaking into the debugger once the code panics thus enabling
the developer to examine the program state at the exact time when
the code panicked.
Let the developer catch the panic in the debugger if it is attached.
If the debugger is not attached, nothing changes. Providing this feature
inside the standard library facilitates better debugging experience.
Validated under Windows, Linux, macOS 14.6, and FreeBSD 13.3..14.1.
Split x86_64-msvc-ext into two jobs
This is an attempt to mitigate (but not resolve) the high failure rate of the x86_64-msvc-ext builder. The theory being that doing less makes it less likely to fail. But this may not work as having an extra job that may fail might be worse.
try-job: x86_64-msvc-ext
try-job: x86_64-msvc-ext2
Fix double handling in `collect_tokens`
Double handling of AST nodes can occur in `collect_tokens`. This is when an inner call to `collect_tokens` produces an AST node, and then an outer call to `collect_tokens` produces the same AST node. This can happen in a few places, e.g. expression statements where the statement delegates `HasTokens` and `HasAttrs` to the expression. It will also happen more after #124141.
This PR fixes some double handling cases that cause problems, including #129166.
r? `@petrochenkov`
Supress niches in coroutines to avoid aliasing violations
As mentioned [here](https://github.com/rust-lang/rust/issues/63818#issuecomment-2264915918), using niches in fields of coroutines that are referenced by other fields is unsound: the discriminant accesses violate the aliasing requirements of the reference pointing to the relevant field. This issue causes [Miri errors in practice](https://github.com/rust-lang/miri/issues/3780).
The "obvious" fix for this is to suppress niches in coroutines. That's what this PR does. However, we have several tests explicitly ensuring that we *do* use niches in coroutines. So I see two options:
- We guard this behavior behind a `-Z` flag (that Miri will set by default). There is no known case of these aliasing violations causing miscompilations. But absence of evidence is not evidence of absence...
- (What this PR does right now.) We temporarily adjust the coroutine layout logic and the associated tests until the proper fix lands. The "proper fix" here is to wrap fields that other fields can point to in [`UnsafePinned`](https://github.com/rust-lang/rust/issues/125735) and make `UnsafePinned` suppress niches; that would then still permit using niches of *other* fields (those that never get borrowed). However, I know that coroutine sizes are already a problem, so I am not sure if this temporary size regression is acceptable.
`@compiler-errors` any opinion? Also who else should be Cc'd here?
Rollup of 10 pull requests
Successful merges:
- #126452 (Implement raw lifetimes and labels (`'r#ident`))
- #129555 (stabilize const_float_bits_conv)
- #129594 (explain the options bootstrap passes to curl)
- #129677 (Don't build by-move body when async closure is tainted)
- #129847 (Do not call query to compute coroutine layout for synthetic body of async closure)
- #129869 (add a few more crashtests)
- #130009 (rustdoc-search: allow trailing `Foo ->` arg search)
- #130046 (str: make as_mut_ptr and as_bytes_mut unstably const)
- #130047 (Win: Add dbghelp to the list of import libraries)
- #130059 (Remove the unused `llvm-skip-rebuild` option from x.py)
r? `@ghost`
`@rustbot` modify labels: rollup
Win: Add dbghelp to the list of import libraries
This is used by the backtrace crate. But we use a submodule to include backtrace in std (rather than being a real crate) so we need to add the dependency here.
str: make as_mut_ptr and as_bytes_mut unstably const
`@rust-lang/libs-api` the corresponding non-mutable methods are already const fn, so this seems pretty trivial. I hope this is small enough that it does not need an ACP? :)
I would like to get these stabilized ASAP because I want to avoid people doing `s.as_ptr().cast_mut()`, which is UB if they ever write to it, but is already const-stable.
TODO: create a tracking issue.
Do not call query to compute coroutine layout for synthetic body of async closure
There is code in the MIR validator that attempts to prevent query cycles when inlining a coroutine into itself, and will use the coroutine layout directly from the body when it detects that's the same coroutine as the one that's being validated. After #128506, this logic didn't take into account the fact that the coroutine def id will differ if it's the "by-move body" of an async closure. This PR implements that.
Fixes#129811
explain the options bootstrap passes to curl
also fixes a discrepancy where the rust side doesn't use -L
docs are only on the rust side, since duplicated prose has a tendancy to get out-of-sync, and also because there are talks of removing the python script all together eventually.
