Bump ahash to 0.8.7 for -Zminimal-versions

[ppentchev]

Hi,

Thanks a lot for writing and maintaining inferno!

What do you think about this trivial patch that will fix the build with nightly Cargo's -Zminimal-versions mode? I routinely try to do this for my own projects, and an ahash -> inferno -> tracing-subscriber dependency chain led me here :) Of course, it is entirely up to you whether you want to support such whims.

Now, in theory one might say that a nightly-toolchain -Zminimal-versions build might even be added to the GitHub workflows or some such; let me know if you want me to try to do that, although I have to admit I am not overly familiar with GitHub workflows.

Thanks in advance, and keep up the great work!

G'luck,
Peter

[jonhoo]

Absolutely! I'm horrified that I'm one of the offenders here. Happy to add this, although I'm somewhat curious about how we're relying on ahash 0.8.7? What is the feature we're using that isn't present in 0.8.0?

[jonhoo]

Also worth pointing out that we do actually have a CI job that checks minimal versions:
https://github.com/jonhoo/inferno/actions/runs/16089142824/job/45403920395?pr=343

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.77%. Comparing base (3aaf771) to head (789a64f).
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #343      +/-   ##
==========================================
+ Coverage   90.67%   90.77%   +0.09%     
==========================================
  Files          21       21              
  Lines        4719     4293     -426     
==========================================
- Hits         4279     3897     -382     
+ Misses        440      396      -44     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[jonhoo]

Releasing in #346

[ppentchev]

Absolutely! I'm horrified that I'm one of the offenders here. Happy to add this, although I'm somewhat curious about how we're relying on ahash 0.8.7? What is the feature we're using that isn't present in 0.8.0?

It's not a feature of ahash, but a bugfix there, the problem is yet another level of dependencies down: 0.8.7 is the first version that contains the tkaitchuck/aHash@53c08e4 commit which fixes the build of the once-cell dependency.

Thanks for the kind words!

[ppentchev]

Also worth pointing out that we do actually have a CI job that checks minimal versions: https://github.com/jonhoo/inferno/actions/runs/16089142824/job/45403920395?pr=343

Hm, ICBW, but it seems to me that that job only checks that the crate builds with the minimum supported Rust version; it will still pull the latest (compatible) versions of the crates it depends on, and so it will use all the bugfixes in those latest versions. What I'm talking about is using the -Zminimal-versions option to cargo that is only available in, well, Rust nightly :) It looks at the version requirements in Cargo.toml and it picks the earliest compatible versions, not the latest ones. Its main goal is, as you surmised, to make sure you don't accidentally start depending on a feature that was introduced in ahash 0.8.7 while declaring a dependency on ahash 0.8.0, but sometimes it may also catch incompatibilities caused by behavior changes in Rust itself, or, as in this case, it may uncover dependency specifications that were too lax to begin with: the commit that bumped the ahash dependency to 0.8 - 7f14ad7 - does not build with cargo build -Zminimal-versions either, since ahash 0.8.0 itself fails to build.

[ppentchev]

And just one more comment: the truth is that testing with cargo build -Zminimal-versions is not, like, mandatory or something. It is an additional layer of checks that may catch such weird cases, but since it is not done by everyone, sometimes it may fail because of a dependency issue three levels deep that you have no control over and you cannot fix in your own crate. It also aims to catch problems that very, very rarely arise in the real world - it is not all that often that somebody actually tries to build a crate with the oldest possible dependencies, even with packaging systems that ship old versions.
I guess what I'm saying is, it's not such a big deal that inferno failed to build with -Zminimal-versions, although it's great that you accepted the fix, thanks again! :)

[jonhoo]

The job I linked specifically builds with -Zminimal-versions. We have a separate job that does MSRV checking :) And yes, I know well both how painful maintaining minimal versions is as I have that check in pretty much all my projects.

[ppentchev]

The job I linked specifically builds with -Zminimal-versions. We have a separate job that does MSRV checking :) And yes, I know well both how painful maintaining minimal versions is as I have that check in pretty much all my projects.

OK, so now I feel a bit dumb... also, I see why this job did not fail, and I just learned something new today :)

• I looked briefly at the job output, I did not really examine the steps it took, because I decided to try to figure out why it had not failed for previous commits...
• ...so instead of checking the jobs that ran for a previous commit, I decided I'd go check out the job definitions themselves...
• ...and I came across the MSRV job and I mistakenly thought that was the same one (even though, of course, the name was not the same)
• Now that I know what I'm looking for, I realize why this job did not fail for the previous commits: it only runs cargo update -Zminimal-versions using the nightly version of Rust/Cargo, then it builds inferno using stable Rust. Come to think of it, that is actually reasonable....... but the ahash / once-cell failure only happens on nightly because of an unstable feature that once-cell activates only on nightly :)
• ...and about TIL: I hadn't realized you could do that :) I hadn't realized I could only run nightly Cargo to update the dependencies, and then run stable Cargo to build my crate. I'll have to think about this a bit, maybe I will do both just to make sure things work on nightly, too, but I won't treat failures on nightly as very serious ones... and since the failure that prompted this very PR only happens on nightly, erm, oops :) I'm sorry :)

...and thanks for bearing with me on my journey of discovery :)

[jonhoo]

All good! Thank you for reporting back on what you found :)