-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Rollup of 6 pull requests #102875
Conversation
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)
@bors r+ rollup=never p=5 |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR: previous master: 8dfb40722d In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (691aeaa): comparison URL. Overall result: ❌✅ regressions and improvements - ACTION NEEDEDNext Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis 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.
CyclesResultsThis 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.
Footnotes |
This is neutral enough that I don't believe it warrants investigation. @rustbot labels: perf-regression-triaged |
Successful merges:
clippy::for_loops_over_fallibles
lint into rustc #99696 (Upliftclippy::for_loops_over_fallibles
lint into rustc)AssocItemKind::TyAlias
toAssocItemKind::Type
#102868 (RenameAssocItemKind::TyAlias
toAssocItemKind::Type
)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup