Rollup of 7 pull requests #79317
Closed
Rollup of 7 pull requests #79317
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
This commit also makes fields of `Take` private. I have no idea why they were `pub(super)` before.
Some UI tests started failing after moving iterator adapters to different modules.
libtest: Print the total time taken to execute a test suite Print the total time taken to execute a test suite by default, without any kind of flag. Closes rust-lang#75660 # Example ``` anon@anon:~/code/rust/example$ cargo test Compiling example v0.1.0 (/home/anon/code/rust/example) Finished test [unoptimized + debuginfo] target(s) in 0.18s Running target/debug/deps/example-745b64d3885c3565 running 3 tests test tests::foo ... ok test tests::bar ... ok test tests::baz ... ok test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; 1.2s Doc-tests example running 3 tests test src/lib.rs - foo (line 3) ... ok test src/lib.rs - bar (line 11) ... ok test src/lib.rs - baz (line 19) ... ok test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; 1.3s ``` ``` anon@anon:~/code/rust/example$ cargo test -- --format terse Finished test [unoptimized + debuginfo] target(s) in 0.08s Running target/debug/deps/example-745b64d3885c3565 running 3 tests ... test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; 1.2s Doc-tests example running 3 tests ... test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; 1.3s ``` ``` anon@anon:~/code/rust/example$ cargo test -- --format json -Z unstable-options Compiling example v0.1.0 (/home/anon/code/rust/example) Finished test [unoptimized + debuginfo] target(s) in 0.25s Running target/debug/deps/example-745b64d3885c3565 { "type": "suite", "event": "started", "test_count": 3 } { "type": "test", "event": "started", "name": "tests::bar" } { "type": "test", "event": "started", "name": "tests::baz" } { "type": "test", "event": "started", "name": "tests::foo" } { "type": "test", "name": "tests::foo", "event": "ok" } { "type": "test", "name": "tests::bar", "event": "ok" } { "type": "test", "name": "tests::baz", "event": "ok" } { "type": "suite", "event": "ok", "passed": 3, "failed": 0, "allowed_fail": 0, "ignored": 0, "measured": 0, "filtered_out": 0, "exec_time": "1.2s" } Doc-tests example { "type": "suite", "event": "started", "test_count": 3 } { "type": "test", "event": "started", "name": "src/lib.rs - bar (line 11)" } { "type": "test", "event": "started", "name": "src/lib.rs - baz (line 19)" } { "type": "test", "event": "started", "name": "src/lib.rs - foo (line 3)" } { "type": "test", "name": "src/lib.rs - foo (line 3)", "event": "ok" } { "type": "test", "name": "src/lib.rs - bar (line 11)", "event": "ok" } { "type": "test", "name": "src/lib.rs - baz (line 19)", "event": "ok" } { "type": "suite", "event": "ok", "passed": 3, "failed": 0, "allowed_fail": 0, "ignored": 0, "measured": 0, "filtered_out": 0, "exec_time": "1.3s" } ```
…=m-ou-se Split each iterator adapter and source into individual modules This PR creates individual modules for each iterator adapter and iterator source. This is done to enhance the readability of corresponding modules (`adapters/mod.rs` and `sources.rs`) which were hard to navigate and read because of lots of repeated lines (e.g.: `adapters/mod.rs` was 3k lines long). This is also in line with some adapters which already had their own modules (`Flatten`, `FlatMap`, `Chain`, `Zip`, `Fuse`). This PR also makes `Take`s adapter fields private (I have no idea why they were `pub(super)` before). r? `@LukasKalbertodt`
…r=m-ou-se Stabilize refcell_take Tracking Issue: rust-lang#71395 `@KodrAus` nominated this for FCP, so here's a PR! I've never made a stabilization PR, so please mention if there's anything I can improve, thanks.
Clean up `StructuralEq` docs
…=oli-obk Allow using generic trait methods in `const fn` Next step for rust-lang#67792, this now also allows code like the following: ```rust struct S; impl const PartialEq for S { fn eq(&self, _: &S) -> bool { true } } const fn equals_self<T: PartialEq>(t: &T) -> bool { *t == *t } pub const EQ: bool = equals_self(&S); ``` This works by threading const-ness of trait predicates through trait selection, in particular through `ParamCandidate`, and exposing it in the resulting `ImplSource`. Since this change makes two bounds `T: Trait` and `T: ?const Trait` that only differ in their const-ness be treated like different bounds, candidate winnowing has been changed to drop the `?const` candidate in favor of the const candidate, to avoid ambiguities when both a const and a non-const bound is present.
resolve: Do not put macros into `module.unexpanded_invocations` unless necessary
Macro invocations in modules <sup>(*)</sup> need to be tracked because they can produce named items when expanded.
We cannot give definite answer to queries like "does this module declare name `n`?" until all macro calls in that module are expanded.
Previously we marked too many macros as potentially producing named items.
E.g. in this example
```rust
mod m {
const C: u32 = line!();
}
```
`line!()` cannot emit any items into module `m`, but it was still marked.
This PR fixes that and marks macro calls as "unexpanded in module" only if they can actually emit named items into that module.
Diagnostics in UI test outputs have different order now because this change affects macro expansion order.
<sup>*</sup> Any containers for named items are called modules in resolve (that includes blocks, traits and enums in addition to `mod` items).
Stabilise `then` Stabilises the lazy variant of rust-lang#64260 now that the FCP [has ended](rust-lang#64260 (comment)). I've kept the original feature gate `bool_to_option` for the strict variant (`then_some`), and created a new insta-stable feature gate `lazy_bool_to_option` for `then`.
|
@bors r+ p=7 rollup=never |
|
📌 Commit 4ed2694 has been approved by |
bors
added
the
S-waiting-on-bors
|
⌛ Testing commit 4ed2694 with merge a8a70080c803cc34670e3fc6822936f1687b4415... |
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
bors
added a commit
to rust-lang/cargo
that referenced
this pull request
Nov 23, 2020
…ichton Relaxes expectation of `cargo test` tests to accept test execution time rust-lang/rust#75752 changes the output of libtest. For example, output before: ``` test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out ``` Output after: ``` test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.01s ``` This breaks some cargo tests: https://github.com/rust-lang-ci/rust/runs/1439245145 As a preparation for the merge, this PR relaxes the test expectations of `cargo test` tests to accept both outputs. I'm using the existing pattern feature of `Execs::with_stdout`: ``` test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out[..] ``` I made this change for the following tests: - `test::can_not_mix_doc_tests_and_regular_tests` - `test::cargo_test_quiet_with_harness` - `test::test_filtered_excludes_compiling_examples` - `test::cargo_test_doctest_xcompile_ignores` (didn't fail in rust-lang/rust#79317, but failed locally) - `test::cargo_test_doctest_xcompile` (doesn't run locally, I changed it just to be safe) - `test::cargo_test_doctest_xcompile_runner` (doesn't run locally, I changed it just to be safe) - `test::cargo_test_doctest_xcompile_no_runner` (doesn't run locally, I changed it just to be safe) If requested, I will open another PR later to change the expectation to: ``` test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in [..]s ``` However, I don't know how to handle WASM targets because WASM doesn't support time measuring, therefore the libtest output didn't change for WASM. Is WASM even relevant here?
ehuss
pushed a commit
to ehuss/cargo
that referenced
this pull request
Nov 30, 2020
… r=alexcrichton Relaxes expectation of `cargo test` tests to accept test execution time rust-lang/rust#75752 changes the output of libtest. For example, output before: ``` test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out ``` Output after: ``` test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.01s ``` This breaks some cargo tests: https://github.com/rust-lang-ci/rust/runs/1439245145 As a preparation for the merge, this PR relaxes the test expectations of `cargo test` tests to accept both outputs. I'm using the existing pattern feature of `Execs::with_stdout`: ``` test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out[..] ``` I made this change for the following tests: - `test::can_not_mix_doc_tests_and_regular_tests` - `test::cargo_test_quiet_with_harness` - `test::test_filtered_excludes_compiling_examples` - `test::cargo_test_doctest_xcompile_ignores` (didn't fail in rust-lang/rust#79317, but failed locally) - `test::cargo_test_doctest_xcompile` (doesn't run locally, I changed it just to be safe) - `test::cargo_test_doctest_xcompile_runner` (doesn't run locally, I changed it just to be safe) - `test::cargo_test_doctest_xcompile_no_runner` (doesn't run locally, I changed it just to be safe) If requested, I will open another PR later to change the expectation to: ``` test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in [..]s ``` However, I don't know how to handle WASM targets because WASM doesn't support time measuring, therefore the libtest output didn't change for WASM. Is WASM even relevant here?
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:
StructuralEqdocs #78793 (Clean upStructuralEqdocs)const fn#79287 (Allow using generic trait methods inconst fn)module.unexpanded_invocationsunless necessary #79294 (resolve: Do not put macros intomodule.unexpanded_invocationsunless necessary)then#79299 (Stabilisethen)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup