-
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
BTree: share panicky test code & test panic during clear, clone #81300
Conversation
619493c
to
64362d0
Compare
@@ -0,0 +1,67 @@ | |||
#[doc(hidden)] | |||
#[macro_export] | |||
macro_rules! crash_test_dummy_def { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think instead of a macro we can move CLONES and DROPS to Arc fields inside the CrashTestDummy struct and then just have a regular module.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand. How can such fields be initialized and point to something particular for each test case, without a macro? I could do it by explicitly passing an instance of some manager to every CrashTestDummy instance, just like in ord_chaos.rs, but then a simple reference is fine.
Note that all of these tests, including the ones I pilfered the code template from, are totally single threaded. They just use atomics to avoid scary unsafe blocks accessing globals.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A reference would also be fine.
64362d0
to
058b8f3
Compare
@rustbot label: +S-waiting-on-review -S-waiting-on-author |
058b8f3
to
10e0f1c
Compare
|
||
#[derive(Debug)] | ||
pub struct Scene { | ||
bits_per_id: usize, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we add some kind of comment explaining this struct?
In particular it's not clear what value should be passed for bits_per_id or what that means, but more broadly a top-level comment here describing usage would be helpful.
991bf7d
to
440d869
Compare
☔ The latest upstream changes (presumably #81257) made this pull request unmergeable. Please resolve the merge conflicts. |
440d869
to
b54172b
Compare
@rustbot label: +S-waiting-on-review -S-waiting-on-author |
} | ||
|
||
/// Returns how many times a dummy has been queried. If set up by `new`, | ||
/// this is a hexadecimal composition of the count for each dummy id. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we add an example or documentation on what a hexadecimal composition means to the CrashTest struct? It sounds like what this is doing is splitting the u64 into 16 "sections", each 4 bits large, which enables us to track the number for each of those sections (up to 15, I guess). But I'm a bit confused as to why we need something so complicated over a vector of atomics, for example, or even a Mutex<Vec<u64>>
- I don't think we care about performance here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see the complication, but I'm also familiar with binary coded decimal registers. Instead I think involving a mutex complicates matters. Involving a vector probably simplifies, but it is (another) dependency of the btree test code on a cousin in the crate - to some degree, testing the branch you're sitting on. Given the simple use case, I prefer to pull the counters apart in individual local variables and leave the mapping over to the compiler.
The way you comment "up to 15, I guess" suggest to me you didn't notice that I tried to document that same point in the CrashTest::new
member, and neither of us noticed I incorrectly said it's limited to 16, so I'm strengthened in my belief there's already too much documentation here.
Anyway, I think the next iteration away from the original is substantially better.
b54172b
to
3e1d602
Compare
@rustbot label: +S-waiting-on-review -S-waiting-on-author |
Agreed that this looks much better, thanks. @bors r+ rollup |
📌 Commit 3e1d602 has been approved by |
…=Mark-Simulacrum BTree: share panicky test code & test panic during clear, clone Bases almost all tests of panic on the same, richer definition, and extends it to cloning to test panic during clone. r? `@Mark-Simulacrum`
…=Mark-Simulacrum BTree: share panicky test code & test panic during clear, clone Bases almost all tests of panic on the same, richer definition, and extends it to cloning to test panic during clone. r? ``@Mark-Simulacrum``
Rollup of 11 pull requests Successful merges: - rust-lang#81300 (BTree: share panicky test code & test panic during clear, clone) - rust-lang#81706 (Document BinaryHeap unsafe functions) - rust-lang#81833 (parallelize x.py test tidy) - rust-lang#81966 (Add new `rustc` target for Arm64 machines that can target the iphonesimulator) - rust-lang#82154 (Update RELEASES.md 1.50 to include methods stabilized in rust-lang#79342) - rust-lang#82177 (Do not delete bootstrap.exe on Windows during clean) - rust-lang#82181 (Add check for ES5 in CI) - rust-lang#82229 (Add [A-diagnostics] bug report template) - rust-lang#82233 (try-back-block-type test: Use TryFromSliceError for From test) - rust-lang#82302 (Remove unsafe impl Send for CompletedTest & TestResult) - rust-lang#82349 (test: Print test name only once on timeout) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Bases almost all tests of panic on the same, richer definition, and extends it to cloning to test panic during clone.
r? @Mark-Simulacrum