Skip to content
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.

Sign up for GitHub

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

Jump to bottom

tracing-opentelemetry 0.17.1 does not compile with default-features = false #1944

Closed
yusdacra opened this issue Feb 20, 2022 · 2 comments · Fixed by #1949
Closed

tracing-opentelemetry 0.17.1 does not compile with default-features = false #1944

yusdacra opened this issue Feb 20, 2022 · 2 comments · Fixed by #1949

Comments

@yusdacra
Copy link

Bug Report

Version

tracing 0.1
tracing-opentelemetry 0.17.1
opentelemetry 0.17

Platform

Linux lungmen 5.16.7 #1-NixOS SMP PREEMPT Sat Feb 5 18:22:06 UTC 2022 x86_64 GNU/Linux

Crates

tracing-opentelemetry is affected.

Description

tracing-opentelemetry 0.17.1 with default-features = false fails to compile with:

error[E0282]: type annotations needed for `Option<T>`
   --> /home/patriot/.cargo/registry/src/git.luolix.top-1ecc6299db9ec823/tracing-opentelemetry-0.17.1/src/layer.rs:590:25
    |
588 |                     let normalized_meta = None;
    |                         --------------- consider giving `normalized_meta` the explicit type `Option<T>`, where the type parameter `T` is specified
589 |                     let (file, module) = match &normalized_meta {
590 |                         Some(meta) => (
    |                         ^^^^^^^^^^ cannot infer type for type parameter `T` declared on the enum `Option`
    |
    = note: type must be known at this point
@Yatekii
Copy link
Contributor

Yatekii commented Feb 21, 2022

I am having the same issue. It's obvious why it wont work, but it's absolutely not obvious to me how cargo publish worked with this in.

@hawkw
Copy link
Member

hawkw commented Feb 21, 2022

I am also kind of surprised that cargo publish allowed this to happen. I think we should make sure that there's a CI job that builds with default features.

@hawkw hawkw mentioned this issue Feb 21, 2022
Merged
hawkw added a commit that referenced this issue Feb 21, 2022
@hawkw
chore: add --no-default-features check to bin/publish
33a4766 
This adds a check to the `bin/publish` script that the crate being
published builds successfully with its default feature flags disabled.
This would have prevented #1944.

In the future, we may want to extend this to running a whole `cargo
hack` feature powerset check prior to releasing a crate...
@hawkw hawkw mentioned this issue Feb 21, 2022
Merged
hawkw added a commit that referenced this issue Feb 21, 2022
@hawkw
opentelemetry: fix broken build with default-features = false (#1949)
f74b229 
## 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 hawkw mentioned this issue Feb 21, 2022
Merged
hawkw added a commit that referenced this issue Feb 21, 2022
@hawkw
opentelemetry: fix broken build with default-features = false (#1949)
71e8084 
## 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 issue Feb 21, 2022
@hawkw
opentelemetry: prepare to release v0.17.2
ee55018 
# 0.17.2 (February 21, 2022)

This release fixes [an issue][#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 ([#1949])

[#1949]: #1917
[#1944]: #1944
@hawkw hawkw mentioned this issue Feb 21, 2022
Merged
hawkw added a commit that referenced this issue Feb 21, 2022
@hawkw
opentelemetry: prepare to release v0.17.2 (#1952)
009dde2 
# 0.17.2 (February 21, 2022)

This release fixes [an issue][#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 ([#1949])

[#1949]: #1917
[#1944]: #1944
hawkw added a commit that referenced this issue Feb 21, 2022
@hawkw
chore: add cargo hack check to bin/publish (#1950)
2586b73 
This adds a check to the `bin/publish` script that the crate being
published builds successfully with all possible feature combinations,
using `cargo hack --feature-powerset`.

This would have prevented #1944.

We test this on CI for most crates in the repo, but it's disabled for some
crates because the powerset is very large, making the check too slow
to run on CI. However, adding it to the publish script will ensure that it's
at least always run before publishing a crate.
hawkw added a commit that referenced this issue Feb 21, 2022
@hawkw
chore: add cargo hack check to bin/publish (#1950)
7c00d76 
This adds a check to the `bin/publish` script that the crate being
published builds successfully with all possible feature combinations,
using `cargo hack --feature-powerset`.

This would have prevented #1944.

We test this on CI for most crates in the repo, but it's disabled for some
crates because the powerset is very large, making the check too slow
to run on CI. However, adding it to the publish script will ensure that it's
at least always run before publishing a crate.
liuhaozhan added a commit to liuhaozhan/tracing that referenced this issue Nov 17, 2022
@liuhaozhan
chore: add cargo hack check to bin/publish (#1950)
db53ea3 
This adds a check to the `bin/publish` script that the crate being
published builds successfully with all possible feature combinations,
using `cargo hack --feature-powerset`.

This would have prevented tokio-rs/tracing#1944.

We test this on CI for most crates in the repo, but it's disabled for some
crates because the powerset is very large, making the check too slow
to run on CI. However, adding it to the publish script will ensure that it's
at least always run before publishing a crate.
davidbarsky pushed a commit to tokio-rs/tracing-opentelemetry that referenced this issue Mar 21, 2023
@hawkw
opentelemetry: prepare to release v0.17.2 (#1952)
03f0aa1 
# 0.17.2 (February 21, 2022)

This release fixes [an issue][#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 ([#1949])

[#1949]: tokio-rs/tracing#1917
[#1944]: tokio-rs/tracing#1944
kaffarell pushed a commit to kaffarell/tracing that referenced this issue May 22, 2024
@hawkw @kaffarell
opentelemetry: fix broken build with default-features = false (toki…
1067a7a 
…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 issue May 22, 2024
@hawkw @kaffarell
opentelemetry: prepare to release v0.17.2 (tokio-rs#1952)
d4bdd7c 
# 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
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

opentelemetry: fix broken build with default-features = false tokio-rs/tracing
3 participants
@Yatekii @hawkw @yusdacra