Skip to content

Ignore io::process tests #9342

New issue

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

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

Already on GitHub? # 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-->
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants