Where can std::sync::LazyLock be used already?

[EliahKagan]

8e96ed3 (#1854) changed some occurrences of std::once_cell::sync::Lazy to std::sync::LazyLock, including in src/shared.rs. The replacements only affected gitoxide and internal-tools.

LazyLock requires Rust 1.80.0, so it is not compatible with the MSRV of all gitoxide crates. So my guess is that, as in #1518, this continues not to be usable in most crates, but based on #1808 I think it is not immediately obvious what MSRV-related restrictions currently apply.

Is it okay for the gitoxide crate itself to use LazyLock? Assuming the answer is yes, are there other crates besides it and internal-tools where I can use it?

[Byron]

Thanks for bringing this up. I kind of rushed this in yesterday and relied on auto-fixes as well to the point where I barely reviewed the result.

My expectation is that the MSRV check would catch issues, and also that clippy respects the rust-version field in the Cargo manifest. Probably that's the reason it only replaced the Lazy occurrences where it did, places that aren't bound by the MSRV (to my mind).

Maybe that's something to rethink though, as we have test-utilities on the one hand and the CLI on the other. Test-utilities are usually needed to run tests of crates with a lower MSRV, so using more recent features there would mean running tests needs a more recent compiler.
Using more recent features for the binaries would mean that some distributions may have trouble compiling them.

What that in mind, maybe that LazyLock change should just be rolled back?

[NobodyXu]

Given that debian will have a new release soon with rust 1.84, that might be ok?

[Byron]

I kind of feel that it would be easiest to simply not risk it. It was an auto-conversion and I assumed things would remain compatible to the MSRV, but that wasn't really the case.

Addressed in #1861.