Closed ggutoski closed 3 years ago
Weird indeed. When I run from vscode it fails. Still, If I use the command vscode produced in the terminal it works
cargo test --package tofn --lib -- fillvec2::tests::override_enumerate --exact --nocapture
I can reproduce weirdness that's independent of vscode:
$ cargo clippy --tests
warning: unused attribute
--> src/fillvec2.rs:182:5
|
182 | #[should_panic]
| ^^^^^^^^^^^^^^^
|
= note: `#[warn(unused_attributes)]` on by default
warning: 1 warning emitted
Let's just skip #[traced_test
for that test (it doesn't even use logs 😆). I think it's more essential to have all tests running at the pipeline.
Maddeningly, the test still fails when executed manually in vscode: https://github.com/axelarnetwork/tofn/blob/c19f53721844417c8e58211f5e1421101fa31985/src/fillvec2.rs#L180-L189 Seems like a bug in the rust-analyzer vscode extension.
Mine runs fine:
running 1 test
thread 'fillvec2::tests::override_enumerate' panicked at 'use HoleVec::enumerate instead', src/fillvec2.rs:88:9
stack backtrace:
0: std::panicking::begin_panic
at /private/tmp/rust-20210301-17735-1i94w2q/rustc-1.50.0-src/library/std/src/panicking.rs:519:12
1: <tofn::fillvec2::HoleVecIter<T> as core::iter::traits::iterator::Iterator>::enumerate
at ./src/fillvec2.rs:88:9
2: tofn::fillvec2::tests::override_enumerate
at ./src/fillvec2.rs:187:23
3: tofn::fillvec2::tests::override_enumerate::{{closure}}
at ./src/fillvec2.rs:183:5
4: core::ops::function::FnOnce::call_once
at /private/tmp/rust-20210301-17735-1i94w2q/rustc-1.50.0-src/library/core/src/ops/function.rs:227:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
test fillvec2::tests::override_enumerate ... ok
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 29 filtered out; finished in 0.07s
Oops. I got confused by the backtrace. Mine runs fine, too. 😳
Should we close this?
Something funny is happening here. This test passes when executed via
cargo test
andcargo test --all-features
, yet fails when I execute it manually in vscode. For some reason the#[should_panic]
attribute is ignored in some cases, which explains this github warning. Could it be affected by the order of these attributes in the code?_Originally posted by @ggutoski in https://github.com/axelarnetwork/tofn/pull/33#discussion_r618540157_