Open kentfredric opened 4 years ago
Thanks for the reports, this is very helpful --- I'd definitely like all our tests to work even in edge cases, so we'll try to fix these!
cargo test
fails due to nosupport/mod.rs
I'm guessing that your vendorization process involves building crates outside of the upstream repo? This failure is due to using a #[path="..."]
attribute to include shared test-support code: f you are building out-of-tree, the test support code will not be present at the expected location.
Some options for fixing this:
tracing-futures
to include the tracing/tests/support/
directory
tracing-futures
to depend on it from crates.io rather than by including a pathBut a residual problem occurs with:
cargo test --all-features
Which to me, suggests some combination of features is unsupported, and warrants a compile time assertion to refuse this ( as its possible to accidentally have 2 different dependencies with 2 different 'features=[ ]' specifications, which cargo will unify and give spooky action at a distance ).
It appears the broken combination is:
cargo test --no-default-features --features "futures-01 tokio"
It looks like the issue here is that the --no-default-features
is disabling the std
feature as well as futures
0.3 support, which adds a #![no_std]
flag and therefore breaks compilation with futures
0.1, which requires std
. I think we should be able to fix this by changing the futures
0.1 and tokio
features to require the std
feature flag. We have a CI step that tests the full powerset of feature combinations for this crate, so I'm honestly pretty surprised this wasn't caught on CI...I wonder what's different between your environment and the CI test.
We have a CI step that tests the full powerset of feature combinations for this crate, so I'm honestly pretty surprised this wasn't caught on CI...I wonder what's different between your environment and the CI test.
Oh, I see what's the matter! CI only runs cargo check
against the feature powerset:
https://github.com/tokio-rs/tracing/blob/12fde2dd52308b3abf363256444aedfa74433171/.github/workflows/CI.yml#L86
This means that we only check if the main crate code compiles with those feature combinations. All these issues are only when compiling tests, and CI isn't currently checking that tests compile across feature combinations. We should fix this.
I'm guessing that your vendorization process involves building crates outside of the upstream repo? This failure is due to using a
#[path="..."]
attribute to include shared test-support code: f you are building out-of-tree, the test support code will not be present at the expected location.
Indeed. We prefer to use "published sources" as they're predictable and immutable, and more mirror friendly, and given the "published sources" are what everyone actually uses, it makes more sense to test the published content works as expected ( which can in some cases vary from upstreams repo at the time of publish ).
Just unfortunately, rust ecosystem norms don't tend to prioritize the ability to test this scenario (which weakens the ability to verify the published sources are reliable).
So anything that improves this norm is welcome :)
633 should fix the issue with feature flags. We'll try to find a better solution for sharing the test-support code, but that may take a little time, especially since it's going to take some effort to clean that up so it can be a published API rather than internal. Thanks again for bringing this up!
Given https://github.com/tokio-rs/tracing/pull/633#discussion_r392459073, should (could?) we publish an unstable, use-at-your own risk version of tracing-test? If we need to make a breaking change to tracing-test
, we can do a minor version bump of crates that depend on it. Its useful as-is, even if its not the most polished code.
Hi, I'm working on a Linux Vendorization project working with rust crates, and as part of the QA of the vendorization process, we run tests (and the more tests we can run, the better).
However, I've been hitting a few failure that's non-trivial to patch out downstream, and can only be seen once other failures have been patched, so I've opted to put this all in one bug for now.
Some of my test scenarios may seem weird to you, so I don't want to pester if they're intrinsically unsupported situations, (though documentation of this could be a fix, or compile-time assertion-failures when the combination is used).
``` Compiling tracing-futures v0.2.3 (/home/kent/.cpanm/work/1583993665.25298/tracing-futures-0.2.3) error: couldn't read src/../../tracing/tests/support/mod.rs: No such file or directory (os error 2) --> src/lib.rs:485:16 | 485 | pub(crate) mod support; | ^^^^^^^ error: aborting due to previous error error: could not compile `tracing-futures`. To learn more, run the command again with --verbose. ```cargo test
fails due to nosupport/mod.rs
Applying the most obvious workaround for that with this hackish patch:
Disable broken tests without --cfg broken_tests
```diff diff --git a/src/lib.rs b/src/lib.rs index 4b4cc4b..d8994ba 100644 --- a/src/lib.rs +++ b/src/lib.rs @@ -442,19 +442,20 @@ implIs enough to make a rudimentary test pass.
But a residual problem occurs with:
``` Compiling tracing-futures v0.2.3 (/home/kent/.cpanm/work/1583993665.25298/tracing-futures-0.2.3) error[E0407]: method `execute` is not a member of trait `Executor` --> src/executor/futures_01.rs:46:9 | 46 | / fn execute(&self, future: F) -> Result<(), ExecuteErrorcargo test --all-features
Which to me, suggests some combination of features is unsupported, and warrants a compile time assertion to refuse this ( as its possible to accidentally have 2 different dependencies with 2 different 'features=[ ]' specifications, which cargo will unify and give spooky action at a distance ).
It appears the broken combination is:
``` Compiling tracing-futures v0.2.3 (/home/kent/.cpanm/work/1583993665.25298/tracing-futures-0.2.3) error[E0432]: unresolved import `crate::WithDispatch` --> src/executor/futures_01.rs:34:43 | 34 | use crate::{Instrument, Instrumented, WithDispatch}; | ^^^^^^^^^^^^ | | | no `WithDispatch` in the root | help: a similar name exists in the module: `Dispatch` error[E0407]: method `execute` is not a member of trait `Executor` --> src/executor/futures_01.rs:46:9 | 46 | / fn execute(&self, future: F) -> Result<(), ExecuteErrorcargo test --no-default-features --features "futures-01 tokio"