add new const_fn_trait_bound feature gate

[RalfJung]

This (and a subsequent release of lock_api) is needed to make rust-lang/rust#84556 work.

[Amanieu]

bors r+

[bors]

Timed out.

[Amanieu]

I am hesitant to release a new version until rust-lang/rust#84538 is resolved. At the moment the new lock_api only builds on a nighly that has no rustfmt, which most people won't have.

[RalfJung]

At the moment the new lock_api only builds on a nighly that has no rustfmt

Well, only with the nightly feature flag enabled.
But since the beta cutoff is close, I also hope rustfmt won't be broken for too long...

[RalfJung]

FWIW, even if we had a release we still couldn't use it in rustc yet as the bootstrap compiler does not yet know about const_fn_trait_bound.

Using nightly-only features in external crates that the compiler uses internally leads to some "interesting" bootstrap issues. Does rustc truly need these nightly-only features?

[Amanieu]

I think rustc would work fine with the nightly feature on parking_lot disabled. It doesn't seem to use const new for mutexes which is really the only visible API .

[RalfJung]

Yeah, my experiment concluded the same.

However, the docs say that some locks become more efficient with "nightly" enabled, so maybe that's why the feature was enabled? The only place that enables the feature seems to be here and it does that ever since this particular dependency was added.

[Amanieu]

That only applies to RwLock on certain CPUs that support transactional memory extensions. Even then, it is only used under cfg(parallel_compiler), which is off by default. So I think it is fine to just drop the nightly feature from rustc.

[RalfJung]

Right now, having a new release of lock_api would unblock rustfmt updates -- see rust-lang/rust#84538 (comment).

[Amanieu]

I published lock_api 0.4.4