I.e, instead of constructing a whole new `LetStmt` to replace the old
one, suggest to only change the part of the `LetStmt` that we don't
like. This makes the suggestion less likely to introduce spurious
changes, but also makes the diagnostic much nicer imo.
Fixesrust-lang/rust-clippy#15771 by not adding a semicolon that the
initial `LetStmt` didn't have
Fixesrust-lang/rust-clippy#15784 by using the `init.span` with the
correct `SyntaxContext`
changelog: [`let_unit_value`]: don't add spurious semicolon
changelog: [`let_unit_value`]: don't mangle macro calls
This PR:
- adds structured suggestions to all 3 lint scenarios
- adds more examples of linted patterns, and recommended fixes
- moves some test cases to `_unfixable.rs`, to allow running rustfix on
the main file
- stops the lint from firing multiple times on types like `&mut &mut
&mut T`
Open questions:
- I'd like to add a note explaining why chained `&mut` are useless.. but
can't really come up with something consice. I very much don't like the
one in the docs -- it's a bit too condescending imo.
- see comments in the diff for more
I do realize that the PR ended up being quite wide-scoped, but that's
primarily because once I added structured suggestions to one of the lint
cases, `ui_test` started complaining about warnings remaining after the
rustfix run, which of course had to with the fact that the other two
lint cases didn't actually fix the code they linted, only warned. I
_guess_ `ui_test` could be smarter about this, by understanding that if
a warning was created without a suggestion, then that warning will still
remain in the fixed file. But oh well.
changelog: [`mut_mut`]: add structured suggestions, improve docs
fixesrust-lang/rust-clippy#13021
Emit allocator attributes for allocator shim
This emits the same attributes we place on allocator declarations on the definitions in the allocator shim as well. This complements https://github.com/rust-lang/rust/pull/146766, which added the attribute for `#[global_allocator]` definitions. Emitting the attributes on the definitions ensures that they cannot be lost of the allocator shim participates in LTO.
See https://github.com/rust-lang/rust/issues/145995 for context, though that one was about `#[global_allocator]`. I'm not sure whether this can occur with the allocator shim as well or not, but better safe than sorry.
I'm not sure whether there is any good way to test this, as the allocator shim is not part of `--emit=llvm-ir`. I've verified this locally by inspecting the bitcode produced by `-C save-temps`.
r? ``@bjorn3``
mbe: macro_check: Fix function comments referencing non-existent parameters
Several functions had comments referencing a non-existent `valid`
parameter. Remove those. The `guar` parameter that handles errors is
already documented.
In the process, remove another duplicate reference to an
already-documented parameter (`binders`).
std: implement `hostname`
Resolves https://github.com/rust-lang/libs-team/issues/330
Tracking issue: https://github.com/rust-lang/rust/issues/135142
This is based on rust-lang/rust#135141, but I've reimplemented the UNIX version, which now:
* uses `sysconf(_SC_HOST_NAME_MAX)` as an initial buffer length
* returns `OutOfMemory` if the `Vec` allocation fails
* retries the operation if it detects that the name returned by `gethostname` was truncated
Additionally, as part of the rebase, I had to move some WinSock abstractions (initialisation and error access) to `sys::pal` so that they can be accessed from `sys::net::hostname`.
CC ``@orowith2os`` (and thank you for your work!)
debuginfo: add an unstable flag to write split DWARF to an explicit directory
Bazel requires knowledge of outputs from actions at analysis time, including file or directory name. In order to work around the lack of predictable output name for dwo files, we group the dwo files in a subdirectory of --out-dir as a post-processing step before returning control to bazel. Unfortunately some debugging workflows rely on directly opening the dwo file rather than loading the merged dwp file, and our trick of moving the files breaks those users. We can't just hardlink the file or copy it, because with remote build execution we wouldn't end up with the un-moved file copied back to the developer's workstation. As a fix, we add this unstable flag that causes dwo files to be written to a build-system-controllable location, which then lets bazel hoover up the dwo files, but the objects also have the correct path for the dwo files.
r? `@davidtwco`
This allows building a rustc capable of running the frontend without any
backend present. While this may not seem all that useful, it allows
running the frontend of rustc to report errors or running miri to
interpret a program without any backend present. This is useful when you
are trying to say run miri in the browser as upstream LLVM can't be
compiled for wasm yet. Or to run rustc itself in miri like I did a while
ago and caught some UB.
Rollup of 5 pull requests
Successful merges:
- rust-lang/rust#146653 (improve diagnostics for empty attributes)
- rust-lang/rust#146987 (impl Ord for params and use unstable sort)
- rust-lang/rust#147101 (Use `Iterator::eq` and (dogfood) `eq_by` in compiler and library )
- rust-lang/rust#147123 (Fix removed version numbers of `doc_auto_cfg` and `doc_cfg_hide`)
- rust-lang/rust#147149 (add joboet to library review rotation)
r? `@ghost`
`@rustbot` modify labels: rollup
Fix removed version numbers of `doc_auto_cfg` and `doc_cfg_hide`
Tracking issue: https://github.com/rust-lang/rust/issues/43781
The `doc_auto_cfg` and `doc_cfg_hide` features were removed in a recent nightly (by https://github.com/rust-lang/rust/pull/138907).
I believe that the rustc version numbers at which the features were declared to be removed were incorrect, however, and should both be "1.92" (±1). As evidence in favour of this, the error we get from using this was:
```text
error[E0557]: feature has been removed
--> src/lib.rs:22:29
|
22 | #![cfg_attr(docsrs, feature(doc_auto_cfg))]
| ^^^^^^^^^^^^ feature has been removed
|
= note: removed in 1.58.0; see <https://github.com/rust-lang/rust/pull/138907> for more information
= note: merged into `doc_cfg`
```
Note especially the "removed in 1.58" claim. Further evidence is found in the comment further up this file: 4ffeda10e1/compiler/rustc_feature/src/removed.rs (L49-L53)
I've chosen 1.92 as that was the milestone which https://github.com/rust-lang/rust/pull/138907 was added to.
cc `@GuillaumeGomez`
Use `Iterator::eq` and (dogfood) `eq_by` in compiler and library
Now that rust-lang/rust#137122 has landed, we can replace stuff that looks like:
```rust
let a: &[T];
let b: &[T];
let eq = a.len() == b.len() && a.iter().zip(b).all(|(a,b)| a == b)
```
with the much simpler `a.iter().eq(b)`, without losing the perf benefit of the different-length-fast-path.
Also dogfooded `Iterator::eq_by` (cc rust-lang/rust#64295 ) while I'm at it.
First commit (4d1b6fad230f8a5ccceccc7562eadc4ea50059da) should be very straightforward to review, second one (049a4606cb3906787aedf508ee8eea09c2bb3b9a) is slightly more creative, but IMHO a nice cleanup.
impl Ord for params and use unstable sort
AFAICT we are only sorting to find duplicates, so unstable sort should work fine, and maybe is a tiny bit faster?
improve diagnostics for empty attributes
Adds a note about them not having any effect. This was previously done for `feature` attributes but no other attributes. In [converting the `feature` parser](https://github.com/rust-lang/rust/pull/146652) I removed that note. This PR adds it back in and makes it so all attributes benefit from it.
Not blocked on rust-lang/rust#146652, either can merge first
This emits the same attributes we place on allocator declarations
(and allocator definitions using `#[global_allocator]`) on the
definitions in the allocator shim as well, making sure that the
attributes are not lost if the allocator shim participates in LTO.
