-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
regression: tokio::test in 1.38 eats my tests #6610
Comments
After 1.38, On the other hand, the // This won't be triggered.
#[timeout]
#[test]
fn greet() {...} So, it seems that the combination of the // Before, your `greet` test will be expanded like
#[test]
#[timeout]
fn greet() {...}
// After 1.38, your `greet` test will be expanded like
#[timeout]
#[test]
fn greet() {...} |
That's unfortunate. There's a good chance we'll have to revert this, as it is a breaking change. @becheran Ignoring users of |
@Darksonn thanks for the hint. Hm... yea, the #[timeout] part in ntest seems broken now. But to be honest I don't really know how I can possibly fix this in the ntest lib. Is the #[tokio::test] macro now always putting every macro below it above the |
Yes, right now it always puts As for Looking over your |
In the case of this example from your docs: #[test]
#[timeout(10)]
#[should_panic]
fn timeout() {
loop {};
} First, the #[cfg(test)]
#[rustc_test_marker = "my_test"]
pub const timeout: test::TestDescAndFn = /* let's ignore this part */;
#[timeout(10)]
fn timeout() {
loop {};
} And then the If we consider this example: #[should_panic]
#[test]
#[timeout(10)]
fn timeout() {
loop {};
} Then the #[test]
#[timeout(10)]
#[should_panic]
fn timeout() {
loop {};
} Which in turn expands as above. Finally, this example does not work: #[timeout(10)]
#[test]
#[should_panic]
fn timeout() {
loop {};
} Because here fn timeout() {
fn ntest_callback() {
loop {};
}
let ntest_timeout_now = std::time::Instant::now();
let (sender, receiver) = std::sync::mpsc::channel();
std::thread::spawn(move || {
if let std::result::Result::Ok(()) = sender.send(ntest_callback()) {}
});
match receiver.recv_timeout(std::time::Duration::from_millis(10u64)) {
std::result::Result::Ok(t) => return t,
Err(std::sync::mpsc::RecvTimeoutError::Timeout) => {
::std::rt::panic_fmt(
format_args!(
"timeout: the function call took {0} ms. Max time {1} ms",
ntest_timeout_now.elapsed().as_millis(),
10u64,
),
);
}
Err(std::sync::mpsc::RecvTimeoutError::Disconnected) => {
::std::rt::begin_panic("explicit panic")
}
}
} The With #[test]
#[should_panic]
fn timeout() {
fn ntest_callback() {
loop {};
}
...
} |
We decided to bump minimum required version of tokio to 1.34. Currently, the newest tokio version is 1.38, but some of the integration tests are eaten when testing with this specific verstion of tokio. Which is why, as of now, we decided not to support this version. The issue with version 1.38 is related to #[tokio::test] and #[ntest::timeout] attributes. Refs: - tokio-rs/tokio#6610 - becheran/ntest#28 - tokio-rs/tokio#6497
We decided to bump minimum required version of tokio to 1.34. Currently, the newest tokio version is 1.38, but some of the integration tests are eaten when testing with this specific verstion of tokio. Which is why, as of now, we decided not to support this version. The issue with version 1.38 is related to #[tokio::test] and #[ntest::timeout] attributes. Refs: - tokio-rs/tokio#6610 - becheran/ntest#28 - tokio-rs/tokio#6497
We decided to bump minimum required version of tokio to 1.34. Currently, the newest tokio version is 1.38, but some of the integration tests are eaten when testing with this specific verstion of tokio. Which is why, as of now, we decided not to support this version. The issue with version 1.38 is related to #[tokio::test] and #[ntest::timeout] attributes. Refs: - tokio-rs/tokio#6610 - becheran/ntest#28 - tokio-rs/tokio#6497
We decided to bump minimum required version of tokio to 1.34. Currently, the newest tokio version is 1.38, but some of the integration tests are eaten when testing with this specific verstion of tokio. Which is why, as of now, we decided not to support this version. The issue with version 1.38 is related to #[tokio::test] and #[ntest::timeout] attributes. Refs: - tokio-rs/tokio#6610 - becheran/ntest#28 - tokio-rs/tokio#6497
It seems that the ntest(ntest_timeout) with a patch applied has been released, so I'll close this issue. Please open a new issue if you encounter similar problems. |
This is fine since tokio-rs/tokio#6610 is resolved via becheran/ntest#28 which has now been released in ntest 0.9.3 Also bumps the itertools + base64 versions, since they are trivial upgrades
This is fine since tokio-rs/tokio#6610 is resolved via becheran/ntest#28 which has now been released in ntest 0.9.3 Also bumps the itertools + base64 versions, since they are trivial upgrades
This is fine since tokio-rs/tokio#6610 is resolved via becheran/ntest#28 which has now been released in ntest 0.9.3 Also bumps the itertools + base64 versions, since they are trivial upgrades
This is fine since tokio-rs/tokio#6610 is resolved via becheran/ntest#28 which has now been released in ntest 0.9.3 Also bumps the itertools + base64 versions, since they are trivial upgrades
This is fine since tokio-rs/tokio#6610 is resolved via becheran/ntest#28 which has now been released in ntest 0.9.3 Also bumps the itertools + base64 versions, since they are trivial upgrades
This is fine since tokio-rs/tokio#6610 is resolved via becheran/ntest#28 which has now been released in ntest 0.9.3 Also bumps the itertools + base64 versions, since they are trivial upgrades
This is fine since tokio-rs/tokio#6610 is resolved via becheran/ntest#28 which has now been released in ntest 0.9.3
This is fine since tokio-rs/tokio#6610 is resolved via becheran/ntest#28 which has now been released in ntest 0.9.3
Version
1.38
Platform
Description
On upgrading from 1.37 to 1.38, my tests are suddenly just getting ignored. If I don't set
RUSTFLAGS=-Dwarnings
env, the tests are just not run at all (which is why the compiler is complaining about the functions being called from the tests, are unused).The text was updated successfully, but these errors were encountered: