Use of unstable pointer_cast feature

[jdm]

RtlLookupFunctionEntry(addr, &mut base, ptr::null_mut()).cast() yields:

error[E0658]: use of unstable library feature 'ptr_cast'
   --> /home/travis/.cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.42/src/backtrace/dbghelp.rs:110:74
    |
110 |                 RtlLookupFunctionEntry(addr, &mut base, ptr::null_mut()).cast()
    |                                                                          ^^^^
    |
    = note: for more information, see https://github.com/rust-lang/rust/issues/60602
    = help: add #![feature(ptr_cast)] to the crate attributes to enable

Since this was added in a semver minor release, this breaks any CI for a Rust library crate that transitively depends on backtrace 0.3.

[alexcrichton]

This function was stabilized in 1.38.0 which falls within the supported range of this crate. If you'd like to support previous versions of rustc PRs are welcome but I won't personally attempt further compatibility.

[olson-dan]

This caused backtrace as a transitive dependency to break our builds. Adding newly-stabilized features or raising the minimum-required stable rust version of a crate seems like it should always be a major version bump.

The only fix is likely to pull the release containing this code and re-release it with a major version bump.

The supported stable versions of the head revision of this crate are irrelevant. Older rust versions were correctly supported by older versions of the crate and the issue is that the versioning appears to be incorrect.

[tobias-o]

https://semver.org/#spec-item-4

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

[BurntSushi]

@olson-dan

This caused backtrace as a transitive dependency to break our builds.

Using Cargo.lock should prevent that.

raising the minimum-required stable rust version of a crate seems like it should always be a major version bump

There is no consensus on this point and most crates in the ecosystem generally do not consider it a breaking change. See also: rust-lang/api-guidelines#123

@tobias-o In the Rust ecosystem, Cargo treats the leftmost non-zero digit in the version number as if it were the major version specified by semver. e.g., Crates going from 0.x.y to 0.x.(y+1) should never introduce breaking changes. (In this case, the question is whether bumping the MSRV is a breaking change or not in the first place.)

[olson-dan]

Using Cargo.lock should prevent that.

Noted for future, we've been pretty ad-hoc with it.

raising the minimum-required stable rust version of a crate seems like it should always be a major version bump

There is no consensus on this point and most crates in the ecosystem generally do not consider it a breaking change. See also: rust-lang/api-guidelines#123

This seems like it would be worth reconsidering.

[jdm]

@BurntSushi Since Cargo's default behaviour for libs is to add a gitignore entry for Cargo.lock, I don't find that a very compelling suggestion.

[alexcrichton]

FWIW this is a pretty unproductive location to try to air concerns about Cargo, semver, etc. I'm going to mute this issue now because these sorts of discussions are rarely productive.

I'll reiterate again. I'm sorry this caused breakage, but this update is within the policy of this crate for supported rustc versions, so I'm not going to personally take action. If anyone would like to send a PR I can merge it and publish a new version.