Skip to content
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

Rollup of 6 pull requests #102875

Merged
merged 30 commits into from
Oct 10, 2022
Merged

Rollup of 6 pull requests #102875

merged 30 commits into from
Oct 10, 2022

Conversation

Dylan-DPC
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

c410-f3r and others added 30 commits September 20, 2022 12:31
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`
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
Move some tests to more reasonable directories

r? ``@petrochenkov``
…, r=lcnr

Remove tuple candidate, nothing special about it

r? `@lcnr` you mentioned this during the talk you gave i think
Make tests capture the error printed by a Result return

An error returned by tests previously would get written directly to stderr, instead of to the capture buffer set up by the test harness. This PR makes it write to the capture buffer so that it can be integrated as part of the test output by build tools such as `buck test`, since being able to read the error message returned by a test is pretty critical to debugging why the test failed.

<br>

**Before:**

```rust
// tests/test.rs

#[test]
fn test() -> Result<(), &'static str> {
    println!("STDOUT");
    eprintln!("STDERR");
    Err("RESULT")
}
```

```console
$ cargo build --test test
$ target/debug/deps/test-???????????????? -Z unstable-options --format=json
{ "type": "suite", "event": "started", "test_count": 1 }
{ "type": "test", "event": "started", "name": "test" }
Error: "RESULT"
{ "type": "test", "name": "test", "event": "failed", "stdout": "STDOUT\nSTDERR\n" }
{ "type": "suite", "event": "failed", "passed": 0, "failed": 1, "ignored": 0, "measured": 0, "filtered_out": 0, "exec_time": 0.00040313 }
```

**After:**

```console
$ target/debug/deps/test-???????????????? -Z unstable-options --format=json
{ "type": "suite", "event": "started", "test_count": 1 }
{ "type": "test", "event": "started", "name": "test" }
{ "type": "test", "name": "test", "event": "failed", "stdout": "STDOUT\nSTDERR\nError: \"RESULT\"" }
{ "type": "suite", "event": "failed", "passed": 0, "failed": 1, "ignored": 0, "measured": 0, "filtered_out": 0, "exec_time": 0.000261894 }
```
Skip chained OpaqueCast when building captures.

Fixes rust-lang#102089
…as-to-ty, r=TaKO8Ki

Rename `AssocItemKind::TyAlias` to `AssocItemKind::Type`

Thanks `@camsteffen` for catching this in ast too, cc rust-lang#102829 (comment)
@rustbot rustbot added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Oct 10, 2022
@Dylan-DPC
Copy link
Member Author

@bors r+ rollup=never p=5

@bors
Copy link
Contributor

bors commented Oct 10, 2022

📌 Commit 81b9d0b has been approved by Dylan-DPC

It is now in the queue for this repository.

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Oct 10, 2022
@bors
Copy link
Contributor

bors commented Oct 10, 2022

⌛ Testing commit 81b9d0b with merge 691aeaa...

@bors
Copy link
Contributor

bors commented Oct 10, 2022

☀️ Test successful - checks-actions
Approved by: Dylan-DPC
Pushing 691aeaa to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Oct 10, 2022
@bors bors merged commit 691aeaa into rust-lang:master Oct 10, 2022
@rustbot rustbot added this to the 1.66.0 milestone Oct 10, 2022
@rust-timer
Copy link
Collaborator

📌 Perf builds for each rolled up PR:

PR# Perf Build Sha
#102868 77968c2c5444be2bcf32c5e4529b7962713a579b
#102853 7152181380352ff84e4bcabf295beaeb95539015
#102794 33f73e7c508e9566367360ff6d90952ec3ba277b
#102786 66144726b2dc3a3911bd842d8a7dfebe88a4258e
#102055 634e240eabac938e81b55807b73bd70cfc3f83a9
#99696 4e875eacee4ed4a665c72e14faacf5288580c7d9

previous master: 8dfb40722d

In the case of a perf regression, run the following command for each PR you suspect might be the cause: @rust-timer build $SHA

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (691aeaa): comparison URL.

Overall result: ❌✅ regressions and improvements - ACTION NEEDED

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

mean1 range count2
Regressions ❌
(primary)
0.2% [0.2%, 0.2%] 2
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-5.0% [-6.6%, -1.8%] 5
All ❌✅ (primary) 0.2% [0.2%, 0.2%] 2

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean1 range count2
Regressions ❌
(primary)
3.1% [2.7%, 4.0%] 3
Regressions ❌
(secondary)
2.6% [0.8%, 5.5%] 34
Improvements ✅
(primary)
-2.4% [-2.4%, -2.4%] 1
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 1.8% [-2.4%, 4.0%] 4

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean1 range count2
Regressions ❌
(primary)
3.5% [2.5%, 4.5%] 2
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-5.3% [-7.6%, -1.8%] 6
All ❌✅ (primary) 3.5% [2.5%, 4.5%] 2

Footnotes

  1. the arithmetic mean of the percent change 2 3

  2. number of relevant changes 2 3

@rustbot rustbot added the perf-regression Performance regression. label Oct 10, 2022
@rylev
Copy link
Member

rylev commented Oct 11, 2022

This is neutral enough that I don't believe it warrants investigation.

@rustbot labels: perf-regression-triaged

@rustbot rustbot added the perf-regression-triaged The performance regression has been triaged. label Oct 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. perf-regression Performance regression. perf-regression-triaged The performance regression has been triaged. rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants