Skip to content

Ignore io::process tests #9342

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Sep 20, 2013

Conversation

alexcrichton
Copy link
Member

They're causing syscalls to get interrupted, and std::io doesn't correctly
handle EINTR

They're causing syscalls to get interrupted, and std::io doesn't correctly
handle EINTR
bors added a commit that referenced this pull request Sep 19, 2013
…brson

They're causing syscalls to get interrupted, and std::io doesn't correctly
handle EINTR
@bors bors closed this Sep 20, 2013
@bors bors merged commit 5165ecd into rust-lang:master Sep 20, 2013
flip1995 pushed a commit to flip1995/rust that referenced this pull request Sep 9, 2022
Suggest `Entry::or_default` for `Entry::or_insert(Default::default())`

Unlike past similar work done in rust-lang#6228, expand the existing `or_fun_call`
lint to detect `or_insert` calls with a `T::new()` or `T::default()`
argument, much like currently done for `unwrap_or` calls. In that case,
suggest the use of `or_default`, which is more idiomatic.

Note that even with this change, `or_insert_with(T::default)` calls
aren't detected as candidates for `or_default()`, in the same manner
that currently `unwrap_or_else(T::default)` calls aren't detected as
candidates for `unwrap_or_default()`.

Also, as a nearby cleanup, change `KNOW_TYPES` from `static` to `const`,
since as far as I understand it's preferred (should Clippy have a lint
for that?).

Addresses rust-lang#3812.

*Please write a short comment explaining your change (or "none" for internal only changes)*

changelog: [`or_fun_call`]: Suggest `Entry::or_default` for `Entry::or_insert(Default::default())`
flip1995 pushed a commit to flip1995/rust that referenced this pull request Jul 31, 2023
`unwrap_or_else_default` -> `unwrap_or_default` and improve resulting lint

Resolves rust-lang#10080 (though it doesn't implement exactly what's described there)

This PR does the following:
1. Merges `unwrap_or_else_default.rs`'s code into `or_fun_call.rs`
2. Extracts the code to handle `unwrap_or(/* default value */)` and similar, and moves it into `unwrap_or_else_default`
3. Implements the missing functionality from rust-lang#9342, e.g.,, to handle `or_insert_with(Default::default)`
4. Renames `unwrap_or_else_default` to `unwrap_or_default` (since the "new" lint handles both `unwrap_or` and `unwrap_or_else`, it seemed sensible to use the shortened name)

This PR is currently two commits. The first implements 1-3, the second implements 4.

A word about 2: the `or_fun_call` lint currently produces warnings like the following:
```
error: use of `unwrap_or` followed by a call to `new`
  --> $DIR/or_fun_call.rs:56:14
   |
LL |     with_new.unwrap_or(Vec::new());
   |              ^^^^^^^^^^^^^^^^^^^^^ help: try: `unwrap_or_default()`
```
To me, such warnings look like they should come from `unwrap_or_else_default`, not `or_fun_call`, especially since `or_fun_call` is [in the nursery](rust-lang/rust-clippy#9829).

---

changelog: Move: Renamed `unwrap_or_else_default` to [`unwrap_or_default`]
[rust-lang#10120](rust-lang/rust-clippy#10120)
changelog: Enhancement: [`unwrap_or_default`]: Now handles more functions, like `or_insert_with`
[rust-lang#10120](rust-lang/rust-clippy#10120)
<!-- changelog_checked-->
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants