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

[nielx]

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

[BurntSushi]

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.

[alexcrichton]

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.

[philipc]

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

[alexcrichton]

I've sent https://github.com/BurntSushi/memchr/pull/89 for memchr, and https://github.com/gimli-rs/object/pull/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.

[alexcrichton]

Updated now!

[nielx]

Thank you!