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 5 pull requests #102586

Merged
merged 11 commits into from
Oct 2, 2022
Merged

Rollup of 5 pull requests #102586

merged 11 commits into from
Oct 2, 2022

Conversation

Dylan-DPC
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

hovinenb and others added 11 commits September 16, 2022 14:36
Rust's test library allows test functions to return a Result, so that the test is deemed to have failed if the function returns a Result::Err variant. Currently, this works by having Result implement the Termination trait and asserting in assert_test_result that Termination::report() indicates successful completion. This turns a Result::Err into a panic, which is caught and unwound in the test library.

This approach is problematic in certain environments where one wishes to save on both binary size and compute resources when running tests by:

 * Compiling all code with --panic=abort to avoid having to generate unwinding tables, and
 * Running most tests in-process to avoid the overhead of spawning new processes.

This change removes the intermediate panic step and passes a Result::Err directly through to the test runner.

To do this, it modifies assert_test_result to return a Result<(), String> where the Err variant holds what was previously the panic message. It changes the types in the TestFn enum to return Result<(), String>.

This tries to minimise the changes to benchmark tests, so it calls unwrap() on the Result returned by assert_test_result, effectively keeping the same behaviour as before.
…test, r=Mark-Simulacrum

Do not panic when a test function returns Result::Err.

Rust's test library allows test functions to return a `Result`, so that the test is deemed to have failed if the function returns a `Result::Err` variant. Currently, this works by having `Result` implement the `Termination` trait and asserting in assert_test_result that `Termination::report()` indicates successful completion. This turns a `Result::Err` into a panic, which is caught and unwound in the test library.

This approach is problematic in certain environments where one wishes to save on both binary size and compute resources when running tests by:

 * Compiling all code with `--panic=abort` to avoid having to generate unwinding tables, and
 * Running most tests in-process to avoid the overhead of spawning new processes.

This change removes the intermediate panic step and passes a `Result::Err` directly through to the test runner.

To do this, it modifies `assert_test_result` to return a `Result<(), String>` where the `Err` variant holds what was previously the panic message. It changes the types in the `TestFn` enum to return `Result<(), String>`.

This tries to minimise the changes to benchmark tests, so it calls `unwrap()` on the `Result` returned by `assert_test_result`, effectively keeping the same behaviour as before.

Some questions for reviewers:

 * Does the change to the return types in the enum `TestFn` constitute a breaking change for the library API? Namely, the enum definition is public but the test library indicates that "Currently, not much of this is meant for users" and most of the library API appears to be marked unstable.
 * Is there a way to test this change, i.e., to test that no panic occurs if a test returns `Result::Err`?
 * Is there a shorter, more idiomatic way to fold `Result<Result<T,E>,E>` into a `Result<T,E>` than the `fold_err` function I added?
…Mark-Simulacrum

Use fetch_update in sync::Weak::upgrade

Using `fetch_update` makes it more clear that it's CAS loop then manually implementing one.
Give `def_span` the same SyntaxContext as `span_with_body`.

rust-lang#102217

I'm not sure how to add a test, since the erroneous span was crafted using a proc macro.
The debug assertion in `def_span` will ensure we have the correct behaviour.
… r=Mark-Simulacrum

Make `feature(const_btree_len)` implied by `feature(const_btree_new)`

...this should fix code that used the old feature that was changed in rust-lang#102197

cc ```@davidtwco``` it seems like tidy doesn't check `implied_by`, should it?
…k-Simulacrum

Add a known-bug test for rust-lang#102498

Self-explanatory
@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. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Oct 2, 2022
@Dylan-DPC
Copy link
Member Author

@bors r+ rollup=never p=5

@bors
Copy link
Contributor

bors commented Oct 2, 2022

📌 Commit 0b25967 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 2, 2022
@klensy
Copy link
Contributor

klensy commented Oct 2, 2022

3 mostly equal your rollups. #102584 #102585 #102586

@Dylan-DPC
Copy link
Member Author

ye i know i hit esc for the other 2 because i needed to change something but it was too late :P

@bors
Copy link
Contributor

bors commented Oct 2, 2022

⌛ Testing commit 0b25967 with merge 39323a5...

@bors
Copy link
Contributor

bors commented Oct 2, 2022

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

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

📌 Perf builds for each rolled up PR:

PR# Perf Build Sha
#102566 81b651fe06e45f877d206a3e5b86a5acb82f818d
#102556 8b975d1a40ee6510d57d9dd981ec96f54f9b443b
#102538 02b4e3891b7d25516d6ef366fe789f27b1244a7d
#102098 73e12136bf55154ffa8dba2a877f5ef9b7fa78cf
#100451 baca1c12f45c79d781fe98a2a643f4b9660a392a

previous master: 91931ec2fc

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 (39323a5): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

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)
2.4% [2.4%, 2.4%] 1
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-4.6% [-4.6%, -4.6%] 1
Improvements ✅
(secondary)
-4.0% [-4.8%, -3.3%] 2
All ❌✅ (primary) -1.1% [-4.6%, 2.4%] 2

Cycles

This benchmark run did not return any relevant results for this metric.

Footnotes

  1. the arithmetic mean of the percent change

  2. number of relevant changes

@Dylan-DPC Dylan-DPC deleted the rollup-g107h6z branch October 3, 2022 05:53
Aaron1011 pushed a commit to Aaron1011/rust that referenced this pull request Jan 6, 2023
Rollup of 5 pull requests

Successful merges:

 - rust-lang#100451 (Do not panic when a test function returns Result::Err.)
 - rust-lang#102098 (Use fetch_update in sync::Weak::upgrade)
 - rust-lang#102538 (Give `def_span` the same SyntaxContext as `span_with_body`.)
 - rust-lang#102556 (Make `feature(const_btree_len)` implied by `feature(const_btree_new)`)
 - rust-lang#102566 (Add a known-bug test for rust-lang#102498)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
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. 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. T-rustdoc Relevant to the rustdoc 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