opentelemetry: fix broken build with default-features = false
#1949
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This should ensure that all its feature combinations actually get tested.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
hawkw
changed the title
default-features = falsedefault-features = false
davidbarsky
approved these changes
Feb 21, 2022
hawkw
added a commit
that referenced
this pull request
Feb 21, 2022
## Motivation Currently, `tracing-opentelemetry` v0.17.1 fails to compile with `default-features = false`. This is because there's a `let` binding for `normalized_metadata` with a `None` where the `Some` type can't be inferred. This managed to slip past CI and get released because we were never actually building the crate with its default features disabled, an oversight in our CI configuration. ## Solution This branch fixes the issue by adding an explicit type annotation to the `let` binding, so the `Option`'s type is known and the type error no longer occurs. I also removed a feature-flagged import that was not actually used. I also added `tracing-opentelemetry` to the `cargo hack` CI job. This way, we will now ensure that all its feature combinations are built on CI (including no features), which should prevent this kind of thing from occurring in the future. Without the fix, we can confirm that this job does fail: https://github.com/tokio-rs/tracing/runs/5279139893?check_suite_focus=true Fixes #1944
hawkw
added a commit
that referenced
this pull request
Feb 21, 2022
## Motivation Currently, `tracing-opentelemetry` v0.17.1 fails to compile with `default-features = false`. This is because there's a `let` binding for `normalized_metadata` with a `None` where the `Some` type can't be inferred. This managed to slip past CI and get released because we were never actually building the crate with its default features disabled, an oversight in our CI configuration. ## Solution This branch fixes the issue by adding an explicit type annotation to the `let` binding, so the `Option`'s type is known and the type error no longer occurs. I also removed a feature-flagged import that was not actually used. I also added `tracing-opentelemetry` to the `cargo hack` CI job. This way, we will now ensure that all its feature combinations are built on CI (including no features), which should prevent this kind of thing from occurring in the future. Without the fix, we can confirm that this job does fail: https://github.com/tokio-rs/tracing/runs/5279139893?check_suite_focus=true Fixes #1944
kaffarell
pushed a commit
to kaffarell/tracing
that referenced
this pull request
May 22, 2024
…o-rs#1949) ## Motivation Currently, `tracing-opentelemetry` v0.17.1 fails to compile with `default-features = false`. This is because there's a `let` binding for `normalized_metadata` with a `None` where the `Some` type can't be inferred. This managed to slip past CI and get released because we were never actually building the crate with its default features disabled, an oversight in our CI configuration. ## Solution This branch fixes the issue by adding an explicit type annotation to the `let` binding, so the `Option`'s type is known and the type error no longer occurs. I also removed a feature-flagged import that was not actually used. I also added `tracing-opentelemetry` to the `cargo hack` CI job. This way, we will now ensure that all its feature combinations are built on CI (including no features), which should prevent this kind of thing from occurring in the future. Without the fix, we can confirm that this job does fail: https://github.com/tokio-rs/tracing/runs/5279139893?check_suite_focus=true Fixes tokio-rs#1944
kaffarell
pushed a commit
to kaffarell/tracing
that referenced
this pull request
May 22, 2024
# 0.17.2 (February 21, 2022) This release fixes [an issue][tokio-rs#1944] introduced in v0.17.1 where `tracing-opentelemetry` could not be compiled with `default-features = false`. ### Fixed - Compilation failure with `tracing-log` feature disabled ([tokio-rs#1949]) [tokio-rs#1949]: tokio-rs#1917 [tokio-rs#1944]: tokio-rs#1944
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
Currently,
tracing-opentelemetryv0.17.1 fails to compile withdefault-features = false. This is because there's aletbinding fornormalized_metadatawith aNonewhere theSometype can't beinferred. This managed to slip past CI and get released because we were
never actually building the crate with its default features disabled, an
oversight in our CI configuration.
Solution
This branch fixes the issue by adding an explicit type annotation to the
letbinding, so theOption's type is known and the type error nolonger occurs. I also removed a feature-flagged import that was not
actually used.
I also added
tracing-opentelemetryto thecargo hackCI job. Thisway, we will now ensure that all its feature combinations are built on
CI (including no features), which should prevent this kind of thing from
occurring in the future. Without the fix, we can confirm that this job does
fail: https://github.com/tokio-rs/tracing/runs/5279139893?check_suite_focus=true
Fixes #1944