rust-lang / backtrace-rs

Backtraces in Rust

Home Page:https://docs.rs/backtrace

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

libbacktrace cannot be updated in Rust's libstd because of memchr dependency

nielx opened this issue · comments

I suppose that this is more a tracking issue for a downstream problem, but it seems to make sense to raise it here.

In libbacktrace 0.2.60, the dependency on object has been raised to 0.25.0. This release contains an unconditional dependency on memchr. This crate does not support the rustc-std-workspace-core workaround.

If the backtrace version shipped with rustc needs to be set higher than 0.3.59, this problem needs to be solved.

CC: @BurntSushi CC: @philipc @fitzgen

rustc-std-workspace-core

I'm not sure what this is, but if there's a non-invasive patch for memchr, I would be happy to accept a PR and get a release out quickly.

Of course, without looking carefully, it's likely that memchr could be made optional since all of its public APIs have corresponding simple and naive implementations.

I'll work on sending a PR to memchr for this soon. @BurntSushi for reference the changes should be entirely isolated to Cargo.toml and look of this shape:

[dependencies]
# Internal feature, only used when building as part of libstd, not part of the
# stable interface of this crate.
core = { version = '1.0.0', optional = true, package = 'rustc-std-workspace-core' }
alloc = { version = '1.0.0', optional = true, package = 'rustc-std-workspace-alloc' }
compiler_builtins = { version = '0.1.2', optional = true }

[features]
# Internal feature, only used when building as part of libstd, not part of the
# stable interface of this crate.
rustc-dep-of-std = ['core', 'alloc', 'compiler_builtins']

The fix at that point would be to add a line here enabling the rustc-dep-of-std feature for memchr when object's own rustc-dep-of-std feature is active.

@nagisa added the memchr dependency for better performance when used in rustc, so updating the memchr crate seems best.

I've sent BurntSushi/memchr#89 for memchr, and gimli-rs/object#356 for object. When those are merged/published then this crate will likely need an update for the new object version, and then the submodule should be good to go to update in rust-lang/rust again.

Updated now!

Thank you!