don't enable parking_lot nightly features

[RalfJung]

Having the compiler itself depend on external libraries that use nightly features can lead to "fun" bootstrap situations. Within the rustc repo we use cfg(bootstrap) to resolve those, but that is not a reasonable option for external dependencies.

So I propose we stop enabling the "nightly" feature of parking_lot here. In my experiments, this then indeed leads to the feature not being enabled (i.e., nothing else enables it), and everything still builds. However, this means parking_lot's RwLock will no longer have hardware lock elision for readers -- I hope that is okay to lose in exchange for less bootstrap brain twisting. ;)

Cc @Amanieu

[rust-highfive]

r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

[jyn514]

Having the compiler itself depend on external libraries that use nightly features can lead to "fun" bootstrap situations. Within the rustc repo we use cfg(bootstrap) to resolve those, but that is not a reasonable option for external dependencies.

However, this means parking_lot's RwLock will no longer have hardware lock elision for readers -- I hope that is okay to lose in exchange for less bootstrap brain twisting. ;)

Hmm, has this caused trouble in practice? Maybe it sense to wait until this breaks things before turning it off, with the intention of re-enabling it once the breakage is fixed?

[RalfJung]

This is causing trouble right now in #84556. A few rabbit holes down, I found myself opening this PR. ;)

[Mark-Simulacrum]

@bors try @rust-timer queue

I suspect this'll likely be a minor-ish performance hit, in which case we'll want to re-add it after we fix parking_lot on nightly, but if it isn't then we can just keep it non-nightly I suspect.

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit 170a10b with merge 8e137b1d29b0369e5c35127a5b3c13c786ab6487...

[bors]

☀️ Try build successful - checks-actions
Build commit: 8e137b1d29b0369e5c35127a5b3c13c786ab6487 (8e137b1d29b0369e5c35127a5b3c13c786ab6487)

[rust-timer]

Queued 8e137b1d29b0369e5c35127a5b3c13c786ab6487 with parent da43ee8, future comparison URL.

[rust-timer]

Finished benchmarking try commit (8e137b1d29b0369e5c35127a5b3c13c786ab6487): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

@bors rollup=never
@rustbot label: +S-waiting-on-review -S-waiting-on-perf

[Mark-Simulacrum]

Seems to not actually matter much for performance, if at all, so we can probably not re-enable it. Alternatively, this is not the only place nightly is actually enabled, and this PR does nothing.

@bors r+

[bors]

📌 Commit 170a10b has been approved by Mark-Simulacrum

[bors]

⌛ Testing commit 170a10b with merge ada1024...

[bors]

☀️ Test successful - checks-actions
Approved by: Mark-Simulacrum
Pushing ada1024 to master...

[RalfJung]

Alternatively, this is not the only place nightly is actually enabled, and this PR does nothing.

I did try to exclude this by using patch and making builds with that feature fail -- but I might have screwed that up.

FWIW, the issue with re-enabling this is that we might end up in a situation where we actually rely on the nightly-only feature, so the next recursive bootstrap problem might be harder to resolve (since just using stable parking_lot might not be an option).