Rollup of 9 pull requests #101032
Closed
Rollup of 9 pull requests #101032
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We have `File::create` for creating a file or opening an existing file, but the secure way to guarantee creating a new file requires a longhand invocation via `OpenOptions`. Add `File::create_new` to handle this case, to make it easier for people to do secure file creation.
I refactored the code: - Removed handling of methods, as it felt entirely unnecessary - Removed clippy utils (obviously...) - Used some shiny compiler features (let-else is very handy for lints 👀) - I also renamed the lint to `for_loop_over_fallibles` (note: no `s`). I'm not sure what's the naming convention here, so maybe I'm wrong.
if the iterator is used after the loop, we need to use `.by_ref()`
The loop could contain `break;` that won't work with an `if let`
…nitialized Scalar
Continuation of rust-lang#100938 and rust-lang#101010. This rule was added to support the old, table-based style for displaying enum variants, which are now displayed using headers and paragraphs.
Add a `File::create_new` constructor We have `File::create` for creating a file or opening an existing file, but the secure way to guarantee creating a new file requires a longhand invocation via `OpenOptions`. Add `File::create_new` to handle this case, to make it easier for people to do secure file creation.
Uplift `clippy::for_loops_over_fallibles` lint into rustc
This PR, as the title suggests, uplifts [`clippy::for_loops_over_fallibles`] lint into rustc. This lint warns for code like this:
```rust
for _ in Some(1) {}
for _ in Ok::<_, ()>(1) {}
```
i.e. directly iterating over `Option` and `Result` using `for` loop.
There are a number of suggestions that this PR adds (on top of what clippy suggested):
1. If the argument (? is there a better name for that expression) of a `for` loop is a `.next()` call, then we can suggest removing it (or rather replacing with `.by_ref()` to allow iterator being used later)
```rust
for _ in iter.next() {}
// turns into
for _ in iter.by_ref() {}
```
2. (otherwise) We can suggest using `while let`, this is useful for non-iterator, iterator-like things like [async] channels
```rust
for _ in rx.recv() {}
// turns into
while let Some(_) = rx.recv() {}
```
3. If the argument type is `Result<impl IntoIterator, _>` and the body has a `Result<_, _>` type, we can suggest using `?`
```rust
for _ in f() {}
// turns into
for _ in f()? {}
```
4. To preserve the original behavior and clear intent, we can suggest using `if let`
```rust
for _ in f() {}
// turns into
if let Some(_) = f() {}
```
(P.S. `Some` and `Ok` are interchangeable depending on the type)
I still feel that the lint wording/look is somewhat off, so I'll be happy to hear suggestions (on how to improve suggestions :D)!
Resolves rust-lang#99272
[`clippy::for_loops_over_fallibles`]: https://rust-lang.github.io/rust-clippy/master/index.html#for_loops_over_fallibles
Add comments about stdout locking This is the source of some confusion regarding the `println!` macro: * https://llogiq.github.io/2017/06/01/perf-pitfalls.html#unbuffered-io * https://news.ycombinator.com/item?id=18794930 * https://reddit.com/r/rust/comments/5puyx2/why_is_println_so_slow/dcua5g5/ * https://reddit.com/r/rust/comments/ab7hsi/comparing_pythagorean_triples_in_c_d_and_rust/ecy7ql8/ In some of these cases it's not the locking behavior where the bottleneck lies, but it's still mentioned as a surprise when, eg, benchmarking a million `println!`'s in a very tight loop. If there's any stylistic problems please feel free to correct me! This is my first contribution and I want to get it right 🦀
…-obk interpret: remove support for uninitialized scalars With Miri no longer supporting `-Zmiri-allow-uninit-numbers`, we no longer need to support storing uninit data in a `Scalar`. We anyway already only use this representation for types with *initialized* `Scalar` layout (and we have to, due to partial initialization), so let's get rid of the `ScalarMaybeUninit` type entirely. I tried to stage this into meaningful commits, but the one that changes `read_immediate` to always trigger UB on uninit is the largest chunk of the PR and I don't see how it could be subdivided. Fixes rust-lang/miri#2187 r? ```@oli-obk```
…tch-err, r=oli-obk Improve const mismatch `FulfillmentError` Fixes rust-lang#100414
…, r=thomcc Use `DisplayBuffer` for socket addresses. Continuation of rust-lang#100625 for socket addresses. Renames `net::addr` to `net::addr::socket`, `net::ip` to `net::addr::ip` and `net::ip::display_buffer::IpDisplayBuffer` to `net::addr::display_buffer::DisplayBuffer`.
…-session-diagnostic, r=davidtwco Migrate ast lowering to session diagnostic I migrated the whole rustc_ast_lowering crate to session diagnostic *except* the for the use of `span_fatal` at /compiler/rustc_ast_lowering/src/expr.rs#L1268 because `#[fatal(...)]` is not yet supported (see rust-lang#100694).
extra sanity check against consts pointing to mutable memory This should be both unreachable and redundant (since we already ensure that validation only reads from read-only memory, when validating consts), but I feel like we cannot be paranoid enough here, and also if this ever fails it'll be a nicer error than the "cannot read from mutable memory" error.
…, r=jsha rustdoc: remove unused CSS for `.variants_table` Continuation of rust-lang#100938 and rust-lang#101010. This rule was added to support the old, table-based style for displaying enum variants, which are now displayed using headers and paragraphs.
rustbot
added
A-translation
|
The job Click to see the possible cause of the failure (guessed by this bot) |
davidtwco
removed
the
A-translation
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
File::create_newconstructor #98801 (Add aFile::create_newconstructor)clippy::for_loops_over_fallibleslint into rustc #99696 (Upliftclippy::for_loops_over_fallibleslint into rustc)FulfillmentError#100437 (Improve const mismatchFulfillmentError)DisplayBufferfor socket addresses. #100640 (UseDisplayBufferfor socket addresses.).variants_table#101012 (rustdoc: remove unused CSS for.variants_table)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup