Add `Read`, `Write` and `Seek` impls for `Arc<File>` where appropriate
If `&T` implements these traits, `Arc<T>` has no reason not to do so
either. This is useful for operating system handles like `File` or
`TcpStream` which don't need a mutable reference to implement these
traits.
CC #53835.
CC #94744.
internal: Migrate more assists to use the structured snippet API
Continuing from #14979
Migrates the following assists:
- `generate_derive`
- `wrap_return_type_in_result`
- `generate_delegate_methods`
As a bonus, `generate_delegate_methods` now generates the function and impl block at the correct indentation 🎉.
[`filter_next`]: suggest making binding mutable if it needs to be
Fixes#10029
changelog: [`filter_next`]: suggest making binding mutable if it needs to be and adjust applicability
Rollup of 2 pull requests
Successful merges:
- #113331 (Add filter with following segment while lookup typo for path)
- #113524 (Remove the library/term exception in tidy's pal checker code)
r? `@ghost`
`@rustbot` modify labels: rollup
Add filter with following segment while lookup typo for path
From the discussion: https://github.com/rust-lang/rust/pull/112917#discussion_r1239150173
Seems we can not get the assoc items for `Struct`, `Enum` in the resolving phase.
A obvious filter is avoid suggesting the same name with the following segment path.
Use `following_seg` can extend the function `smart_resolve_partial_mod_path_errors` for more scenarios, such as `std::sync_error::atomic::AtomicBool` in test case.
r? `@estebank`
move pal cfgs in f32 and f64 to sys
I'd like to push forward on `sys` being a separate crate. To start with, most of these PAL exception cases are very simple little bits of code like this, so I thought I would try tidying them up.
Re-enable some coverage tests on Linux
These tests were originally disabled (on all platforms) in #110393, because those changes had made them start failing on Linux for unclear reasons.
I tried to re-enable them unconditionally in #111179, since they worked locally on my Mac, but I found that they were still failing on Linux, so I gave up at that time.
Later while working on #112300 I was able to re-enable them on Windows and Mac, since those changes made it possible to add specific `ignore-` directives to individual tests. I noticed at the time that the tests actually seemed to be working again on Linux, but by that point I didn't want to risk more CI failures, so I left them disabled on Linux with an intention to re-enable them later.
Now I'm going back to re-enable them on Linux too, since they seem to work fine.
---
Because `run-coverage` tests are sensitive to line numbers, and `x test tidy` doesn't like leading blank lines, I've replaced the old comment/ignore with an informative comment that occupies the same number of lines.
Feature: Add a memory layout viewer
**Motivation**: rustc by default doesn't enforce a particular memory layout, however it can be useful to see what it is doing under the hood, or if using a particular repr ensure it is behaving how you want it to. This command provides a way to visually explore memory layouts of structures.
**Example**:
this structure:
```rust
struct X {
x: i32,
y: u8,
z: Vec<bool>,
w: usize,
}
```
produces this output:
<img width="692" alt="image" src="https://github.com/rust-lang/rust-analyzer/assets/22418744/e0312233-18a7-4bb9-ae5b-7b52fcff158a">
**Work yet to be done**:
- tests (see below)
- html is mildly janky (see below)
- enums and unions are viewed flatly, how should they be represented?
- should niches be marked somehow?
This was written for my own use, and the jank is fine for me, but in its current state it is probably not ready to merge mostly because it is missing tests, and also because the code quality is not great. However, before I spend time fixing those things idk if this is even something wanted, if it is I am happy to clean it up, if not that's cool too.
[`unnecessary_literal_unwrap`]: don't lint if binding initializer comes from expansion
Fixes https://github.com/rust-lang/rust-clippy/discussions/11109
changelog: [`unnecessary_literal_unwrap`]: don't lint if binding initializer comes from expansion
Copy stage0 `rustc` binaries to `stage0-sysroot`
This is basically a revival of https://github.com/rust-lang/rust/pull/101711 and https://github.com/rust-lang/rust/pull/107956, with an added check that the full sysroot will only be created if the original rustc comes from `stage0/bin`.
What is/should be tested:
- [x] `rustup toolchain link stage0` (new libstd is used correctly)
- [x] `python3 x.py fmt dist --stage 0`
- [x] Custom rustc/cargo in `config.toml` (in this case this logic is ignored)
- [x] Perfbot (try perf run has succeeded)
- [x] Real use case (https://github.com/rust-lang/backtrace-rs/pull/542)
(Hopefully) fixes: https://github.com/rust-lang/rust/issues/101691
This is not the "end all, be all" solution to this problem, but as long as it resolves the basic use-case, and doesn't break perfbot, I say ship it. This code will probably be nuked anyway Soon™ because of the stage redesign.
