Enable backtrace support for >= 1.65 stable compilers #293
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
LukasKalbertodt
commented
Jan 18, 2023
| /// | ||
| /// On stable compilers, this function is only available if the crate's | ||
| /// Standard library backtraces are only available when using Rust ≥ 1.65. | ||
| /// On older compilers, this function is only available if the crate's | ||
| /// "backtrace" feature is enabled, and will use the `backtrace` crate as | ||
| /// the underlying backtrace implementation. | ||
| /// |
There was a problem hiding this comment.
A few lines down there is:
#[cfg_attr(doc_cfg, doc(cfg(any(nightly, feature = "backtrace"))))]I don't know how to replace that :/
any(>=1.65, feature = "backtrace") surely won't work.
There was a problem hiding this comment.
I suppose an alternative would be bumping the MSRV? (And maybe bumping the Rust edition as well)
The `std::backtrace` APIs relevant for this crate were stabilized in 1.65. This commit makes anyhow use those API if possible. `std::backtrace` is preferred over the `backtrace` crate, so for 1.65+ compilers, enabling the `backtrace` crate feature does nothing essentially. Previously, when a nightly compiler was used, use of `std::backtrace` as well as the Provider API was enabled. This commit separates those two APIs such that `std::backtrace` is used for nightly OR 1.65+ stable compilers; and the Provider API is used for nightly compilers only.
LukasKalbertodt
force-pushed
the
use-stable-backtrace
branch
from
4a1868c
to
49eeec1
Compare
|
@dtolnay any chance of getting this merged? |
|
This crate in unusable for stable Rust in debug mode, but works in stable Rust release mode. Can we just finally make it possible? |
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.
Fixes #284
The
std::backtraceAPIs relevant for this crate were stabilized in 1.65. This commit makes anyhow use those API if possible.std::backtraceis preferred over thebacktracecrate, so for 1.65+ compilers, enabling thebacktracecrate feature does nothing essentially (except downloading the dependency, so don't do that).Previously, when a nightly compiler was used, use of
std::backtraceas well as the Provider API was enabled. This PR separates those two APIs such thatstd::backtraceis used for nightly OR 1.65+ stable compilers; and the Provider API is used for nightly compilers only.I tested this for 1.64, 1.65, the current stable and the current nightly. For all,
cargo testandcargo test --features=backtraceruns fine. I also wanted to test for older nightlies (which do not support the various APIs yet) but I couldn't get it to work as dependencies did not compile. It seems like everyone seems to only support the latest nightly. Which makes sense. So I assumed I could do the same here.This also means that in my doc changes I simply say "for Rust >= 1.65" and don't mention nightly anymore, as that's "implied" if only the latest nightly is supported anyway.
I am not sure if this is the best approach. There are lots of options how to fix #284 I think. I like my approach as it results in a fairly small diff, does not bump the MSRV to 1.65, and still works for nightly (also enabling the
provideAPI then). But I'm curious if you'd like this to use a different approach.