Fix Base.StaticData renaming

[yuyichao]

Ref JuliaLang/julia#59238

[codecov]

Codecov Report

❌ Patch coverage is 0% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 82.47%. Comparing base (7821943) to head (d52d412).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
src/invalidations.jl	0.00%	2 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main      #67   +/-   ##
=======================================
  Coverage   82.47%   82.47%           
=======================================
  Files           3        3           
  Lines          97       97           
=======================================
  Hits           80       80           
  Misses         17       17           

☔ 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.

[timholy]

LGTM. The reason for the failure on nightly is not entirely clear, but it seems like the Preferences test failed on nightly. Is that related to this PR or something that has cropped up independently?

[yuyichao]

The error seems to be caused by the second try to precompile PC_D simply using the cache from the previous one with the workload disabled. I enabled some debugging printing in the test script and this is what I see.

┌ Debug: Loading object cache file /home/yuyichao/julia/julia-422226482a/share/julia/compiled/v1.13/Printf/3FQLY_vKxgG.so for Printf [de0858da-6303-5e67-8744-51eddeeeb8d7]
└ @ Base loading.jl:1270
┌ Debug: Loading object cache file /home/yuyichao/julia/julia-422226482a/share/julia/compiled/v1.13/Dates/p8See_vKxgG.so for Dates [ade2ca70-3891-5945-98fb-dc099432e06a]
└ @ Base loading.jl:1270
┌ Debug: Loading object cache file /home/yuyichao/julia/julia-422226482a/share/julia/compiled/v1.13/TOML/mjrwE_vKxgG.so for TOML [fa267f1f-6049-4f14-aa54-33bafae1ed76]
└ @ Base loading.jl:1270
┌ Debug: Loading object cache file /home/yuyichao/.julia/compiled/v1.13/Preferences/pWSk8_9HzM6.so for Preferences [21216c6a-2e73-6563-6e65-726566657250]
└ @ Base loading.jl:1270
┌ Debug: Loading object cache file /home/yuyichao/.julia/compiled/v1.13/PrecompileTools/AQ9Mk_9HzM6.so for PrecompileTools [aea7be01-6a6a-4083-8856-8a6e6704d82a]
└ @ Base loading.jl:1270
┌ Debug: Loading object cache file /home/yuyichao/.julia/compiled/v1.13/PC_D/VYo8s_9HzM6.so for PC_D [8c347477-c4a5-4b7f-b911-c68b2b9ed891]
└ @ Base loading.jl:1270

Is there supposed to be some connection between setting preferences and invalidating compiled cache? Otherwise this seems to be the correct behavior.

[yuyichao]

Is there supposed to be some connection between setting preferences and invalidating compiled cache?

Actually it seems that it is supposed to be the case, but apparently isn’t anymore

[yuyichao]

Ref JuliaLang/julia#59257

[timholy]

Thanks @yuyichao!

[vchuravy]

Actually it seems that it is supposed to be the case, but apparently isn’t anymore

The behaviour in JuliaLang/julia#59257 is consistent with previous versions (we can debate if this is what we want.) So it would be good to understand if there is a new issue.

[yuyichao]

Actually you are right. I did more test and it seems that the preferences wasn't loaded in the child process.

[vchuravy]

I did more test and it seems that the preferences wasn't loaded in the child process.

This might mean the LocalPreferences.toml wasn't copied to the project of the child process.

[yuyichao]

Sorry scratch that. The preference was loaded (I was manually running the test from the wrong directory so the preference wasn't saved to the correct file) and it still seems that the loading was ignoring the preference setting, even though other isolated test shows that cache invalidation with preferences still works.

[yuyichao]

The issue is that hash(false, UInt(0)) === UInt(0) on 1.13. This causes a hash collision in the get_preference_hash function.

It seems that the way preference dependencies is stored in the cache file is fundamentally flowed though, since a hash equal of course doesn't mean the values are the same, especially for Base.hash (for cryptographic hash I assume it's less of a problem since git relies on it as well....)

[yuyichao]

Which is caused by JuliaLang/julia#57509 (but again I don't think that change is the issue, the use of hash function for this purpose is the issue that was exposed by the change of hash function)

[yuyichao]

What's more the hash doesn't even encode the key and only the ordered values that are not nothing. This means that even on previous julia versions, the following module is susceptible to hash collision, for xyz=<something>, abc=nothing and xyz=nothing, abc=<the same somthing>

module TestModule
using Preferences
const xyz = @load_preference("xyz", nothing)
const abc = @load_preference("abc", nothing)
end

[Moelf]

new release?

[timholy]

I think it should wait for rc2: EDIT: nvm, this is safe

julia> Base.StaticData
Base.StaticData

julia> Base.VERSION
v"1.12.0-rc1"