feat: Bump MSRV to 1.85 and replace 3rd party crates with std library APIs

[bryantbiggs]

Fixes #
Design discussion issue (if applicable) #

Changes

• By bumping the MSRV from 1.75 to 1.85 we are able to remove the following 3rd party crates for rust std library APIs:
  • once_cell
  • lazy_static
  • num-format
  • num_cpus
• Resolves 6 TODO comments in opentelemetry-sdk that were waiting for LazyLock stabilization (stable since Rust 1.80). Each OnceLock paired with a getter function is now a single LazyLock static declaration

Merge requirement checklist

• CONTRIBUTING guidelines followed
• Unit tests added/updated (if applicable)
• Appropriate CHANGELOG.md files updated for non-trivial, user-facing changes
• Changes in public API reviewed (if applicable)

[codecov]

Codecov Report

❌ Patch coverage is 79.66102% with 12 lines in your changes missing coverage. Please review.
✅ Project coverage is 80.9%. Comparing base (3c41f29) to head (78aa19a).

Files with missing lines	Patch %	Lines
opentelemetry-sdk/src/logs/logger_provider.rs	0.0%	6 Missing ⚠️
opentelemetry-prometheus/src/config.rs	0.0%	2 Missing ⚠️
opentelemetry-sdk/src/propagation/baggage.rs	0.0%	2 Missing ⚠️
opentelemetry-sdk/src/propagation/trace_context.rs	0.0%	2 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##            main   #3352     +/-   ##
=======================================
- Coverage   82.2%   80.9%   -1.4%     
=======================================
  Files        128     132      +4     
  Lines      24626   25165    +539     
=======================================
+ Hits       20266   20377    +111     
- Misses      4360    4788    +428     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[cijothomas]

lets keep the policy documented in the main readme.md

[bryantbiggs]

sure, I will re-add. I will say, its a rather odd and confusing statement though. MSRV means the min version specified is the minimum - not the minimum -3 versions

[cijothomas]

This is just listing our policy - we don't require rust version newer than the current-3.
Can use a rewrite for conveying the intent clearly, but in a separate PR.

[cijothomas]

Could we have bumped to 1.80 and still used the std library APIs?

[bryantbiggs]

Could we have bumped to 1.80 and still used the std library APIs?

that was the original intent, but opentelemetry-prometheus looks like it requires a MSRV of 1.81 https://github.com/open-telemetry/opentelemetry-rust/actions/runs/22163623736/job/64085949878?pr=3352

and given that edition 2024 requires 1.85+ I thought the jump was worthwhile. Changing to edition 2024 was not included since that will probably have a few clippy lint changes for the syntax and would be better suited for a follow up PR

[cijothomas]

Could we have bumped to 1.80 and still used the std library APIs?

that was the original intent, but opentelemetry-prometheus looks like it requires a MSRV of 1.81 https://github.com/open-telemetry/opentelemetry-rust/actions/runs/22163623736/job/64085949878?pr=3352

and given that edition 2024 requires 1.85+ I thought the jump was worthwhile. Changing to edition 2024 was not included since that will probably have a few clippy lint changes for the syntax and would be better suited for a follow up PR

Historically , this project was quite defensive about bumping rust version. Officially we only promised current/current-3, but we were quite conservative and support much older rust version.
I am okay with this bump, given it allows us to reduce external crate dependency.

[cijothomas]

@open-telemetry/rust-approvers Please comment if there are any major concerns about this bump. We can leave this open for 2-3 days to get feedbacks.

[lalitb]

@open-telemetry/rust-approvers Please comment if there are any major concerns about this bump. We can leave this open for 2-3 days to get feedbacks.

I tend to be cautious about MSRV bumps unless they’re driven by a security issue or a hard blocking dependency. This is especially important for opentelemetry since it’s a base infrastructure crate used widely by downstream libraries and instrumentation. Even a single MSRV bump ripples outward: libraries wrapping opentelemetry inherit the bump, forcing their own consumers to upgrade.

I’m supportive of the dependency cleanup overall. If possible, it would be great to scope the bump so that core crates like opentelemetry and opentelemetry-sdk remain on a lower MSRV.

[bryantbiggs]

looks like I missed some TODOs that were waiting for LAZYLOCK support - addressed in last commit.

I understand the resistance to disrupt users, theres always a natural tension between staying current and the least friction for users. I used CLAUDE to summarize the additional gains that could be realized if 1.85 and rust edition 2024 were supported (again, edition 2024 would be a separate PR)

What MSRV 1.85 unlocks next

#[expect(lint)] (1.81)

Works like #[allow] but warns you when the suppressed lint stops firing. We
have 60+ #[allow] attributes — converting the temporary ones (dead_code,
unused) to #[expect] means stale suppressions surface automatically instead
of accumulating silently.

use<> precise capturing (1.82)

opentelemetry-appender-tracing currently has:

#[allow(impl_trait_overcaptures)] // can only be fixed with Rust 1.82+

This can now be properly fixed instead of suppressed.

core::error::Error (1.81)

The Error trait is available in core, not just std. We already use
thiserror v2 with default-features = false for no_std error types — an
MSRV of 1.85 guarantees all downstream consumers have core::error::Error
available, which strengthens the no_std story.

Stable cfg(target_has_atomic) (1.80)

PR #3345 added 32-bit platform support using cfg(target_has_atomic = "64")
with portable-atomic. This cfg was stabilized in 1.80 — bumping MSRV means it
works on stable without question.

async-trait removal (evaluation)

The only first-party trait still using the async-trait proc-macro is
HttpClient. The SDK exporter traits (SpanExporter, LogExporter,
PushMetricExporter) already moved away from it. HttpClient is used as
Arc<dyn HttpClient>, so native async fn in traits doesn't work directly, but
the proc-macro can be replaced with explicit Pin<Box<dyn Future>> return
types — which is what #[async_trait] generates anyway, minus the compile-time
cost.

What edition 2024 adds

MSRV-aware cargo resolver (resolver v3)

This is the biggest practical win.

Edition 2024 defaults to resolver v3, which is MSRV-aware. When resolving
dependencies, cargo prefers versions whose rust-version is compatible with
ours. If a transitive dependency publishes a version requiring a newer Rust than
our MSRV, cargo picks the older compatible version instead of breaking the build.

For maintainers: No more surprise CI breakages from cargo update pulling in
a dependency that bumped its own MSRV. Less time spent pinning versions.

For users: Anyone using resolver v3 themselves gets correct resolution against
our declared rust-version. The field is already in our Cargo.toml files —
resolver v3 makes it actually meaningful during resolution.

Stricter compiler defaults

• unsafe_op_in_unsafe_fn changes from allow to warn — requires
  explicit unsafe {} blocks inside unsafe fn bodies. We have one unsafe fn
  in the stress tests; it already has inner unsafe blocks.
• Lifetime capture rules — -> impl Trait return types now capture all
  in-scope lifetimes by default, preventing accidental lifetime escapes.
  cargo fix --edition handles the migration automatically.
• Tail expression scoping — temporaries in tail expressions drop sooner.
  Our .lock().unwrap().clone() patterns all produce owned values, so no
  breakage, but the stricter scoping is safer by default.
• Never type ! fallback — changes from () to !, preventing a class of
  subtle type inference bugs.

Cleanup

• #![warn(rust_2018_idioms)] in 7 crate roots becomes redundant (edition 2024
  enforces these by default) and can be removed.
• edition can move to [workspace.package] — one source of truth instead of 22
  individual Cargo.toml entries.

[utpilla]

@open-telemetry/rust-approvers Please comment if there are any major concerns about this bump. We can leave this open for 2-3 days to get feedbacks.

I appreciate the dependency cleanup, but I have a timing concern.

Traces and the OTLP exporters are still Beta/RC. If we bump MSRV now, users pinned to older toolchains will be stranded on a release that isn't yet a complete solution across all signals. I'd suggest we stabilize those first, so anyone who can't follow the toolchain bump at least has something solid to stay on.

Can we revisit this after the Traces/OTLP stabilization milestone?

[bryantbiggs]

I am using and most interested in the OTLP exporter, so if there are areas where I might be able to help

@open-telemetry/rust-approvers Please comment if there are any major concerns about this bump. We can leave this open for 2-3 days to get feedbacks.

I appreciate the dependency cleanup, but I have a timing concern.

Traces and the OTLP exporters are still Beta/RC. If we bump MSRV now, users pinned to older toolchains will be stranded on a release that isn't yet a complete solution across all signals. I'd suggest we stabilize those first, so anyone who can't follow the toolchain bump at least has something solid to stay on.

Can we revisit this after the Traces/OTLP stabilization milestone?

I can certainly try to help with the stabilization since the OTLP exporter is what I am using and most interested in improving

• fix(sdk): resolve OTLP exporter deadlock on single-threaded tokio runtimes #3356

[cijothomas]

Could we have bumped to 1.80 and still used the std library APIs?

that was the original intent, but opentelemetry-prometheus looks like it requires a MSRV of 1.81 https://github.com/open-telemetry/opentelemetry-rust/actions/runs/22163623736/job/64085949878?pr=3352
and given that edition 2024 requires 1.85+ I thought the jump was worthwhile. Changing to edition 2024 was not included since that will probably have a few clippy lint changes for the syntax and would be better suited for a follow up PR

Historically , this project was quite defensive about bumping rust version. Officially we only promised current/current-3, but we were quite conservative and support much older rust version. I am okay with this bump, given it allows us to reduce external crate dependency.

opentelemetry-prometheus is 1.75 currently, so wondering why it needs 1.81... If this is just for prometheus crate, we can exclude it (it was excluded from main toml due to planned discontinuation of that, but that is being revisited to be included as part of core crates). There are plans to rewrite it to avoid its external dependencies.

https://github.com/open-telemetry/opentelemetry-rust/blob/main/opentelemetry-prometheus/Cargo.toml#L16C1-L16C24

[scottgerring]

I haven't reviewed this, but wanted to share my high level thoughts:

• I think it is great idea to use std where we can over third party crates
• In my opinion any changes to our MSRV policy should be discussed on an RFC and feedback solicited so the community can weigh in; it is always going to feel convenient for us to advance the MSRV, but what do our users need?
• It is very difficult to review PRs of this size meaningfully; changes like this could be decomposed (MSRV advance if we're happy with it, removal of library X, etc.)

[bryantbiggs]

Following up on the feedback here — I've drafted an ADR proposing a formal MSRV policy in #3361. It proposes a 12-month trailing window (twice as conservative as tokio/hyper/tower's 6-month policy) and includes ecosystem research across both the Rust ecosystem and other OTel language SDKs. Would appreciate any feedback there before revisiting the MSRV bump itself.

[bryantbiggs]

Could we have bumped to 1.80 and still used the std library APIs?

that was the original intent, but opentelemetry-prometheus looks like it requires a MSRV of 1.81 open-telemetry/opentelemetry-rust/actions/runs/22163623736/job/64085949878?pr=3352
and given that edition 2024 requires 1.85+ I thought the jump was worthwhile. Changing to edition 2024 was not included since that will probably have a few clippy lint changes for the syntax and would be better suited for a follow up PR

Historically , this project was quite defensive about bumping rust version. Officially we only promised current/current-3, but we were quite conservative and support much older rust version. I am okay with this bump, given it allows us to reduce external crate dependency.

opentelemetry-prometheus is 1.75 currently, so wondering why it needs 1.81... If this is just for prometheus crate, we can exclude it (it was excluded from main toml due to planned discontinuation of that, but that is being revisited to be included as part of core crates). There are plans to rewrite it to avoid its external dependencies.

main/opentelemetry-prometheus/Cargo.toml#L16C1-L16C24

apologies, its the prometheus crate that requires 1.81

I guess this wasn't shown because of the Cargo resolution changes on edition 2024 (not certain). So the current version of the promtheus crate that opentelemetry-prometheus uses, its MSRV is 1.81.0 which is ahead of what the opentelemetry-prometheus MSRV is (1.75.0 currently on main). If we were on edititon 2024, I believe the behavior of Cargo would either surface this or pull a lower version of the prometheus crate in order to satisfy the MSRV of the openetelemetry-prometheus crate (its new for me too so I am not intimately familiar with the behavior other than what is documented)