Backports for 1.12.6#61154
Merged
Merged
Conversation
Because `TOML` is used in the tests: https://github.com/JuliaLang/julia/blob/b51d41ac753f46a3529f47fe3c6638895cf97c6d/stdlib/Artifacts/test/runtests.jl#L6-L6 Noticed in PkgEval ([log](https://s3.amazonaws.com/julialang-reports/nanosoldier/pkgeval/by_hash/a6a3237_vs_63406df/Artifacts.primary.log)) (cherry picked from commit ed71c10)
This allows `--trim` to safely* prune bindings without dropping the root required for the generated machine code. The (significantly more complex) alternative will be to examine the bindings (back)edges during `--trim` serialization and reconstruct the relevant binding dependency edges at that time but that does not seem worth it compared to the 23.6 KB overhead in the sysimage to track these roots explicitly. Resolves #60846. \* As a caveat, uninferred GlobalRefs can lead to missing bindings at runtime, but this is out-of-scope for --trim. (cherry picked from commit 484e7b1)
The officially supported argument is --sdk, not -sdk, though it seems the later also works in practice. But with BinaryBuilder, we use a 'fake' xcrun script which only supports the officially documented argument name. I've also submitted a [PR to let BinaryBuilderBase.jl accept this](JuliaPackaging/BinaryBuilderBase.jl#464); but I think it's wise for us to stick to the officially documented options. (cherry picked from commit 4820747)
`thrash_counter` is initialized to `0` but only ever incremented under
this branch, which was checking `!(thrash_counter < 4)`, making the
entire mechanism effectively dead code
here was something that can demonstrate the difference but I don't know
how to add a unit test
```
# gc_thrash_mwe.jl
mutable struct Node; l::Any; r::Any; d::Vector{UInt8}; end
tree(n) = n <= 0 ? Node(nothing,nothing,rand(UInt8,64)) : Node(tree(n-1),tree(n-1),rand(UInt8,64))
const SHED = Ref(false)
const CB = @cfunction(() -> (SHED[] = true; nothing), Cvoid, ())
ccall(:jl_gc_set_cb_notify_gc_pressure, Cvoid, (Ptr{Cvoid}, Cint), CB, 1)
trees = Any[tree(18) for _ in 1:8] # ~640 MB scattered pointers
cache = Ref{Any}([rand(UInt8, 200) for _ in 1:1_000_000]) # ~200 MB droppable cache
GC.gc()
@time for i in 1:200
if SHED[]; cache[] = nothing; SHED[] = false; end
[rand(UInt8, 48) for _ in 1:50_000]
end
println(cache[] === nothing ? "PASS: cache shed under pressure" : "FAIL: pressure callback never fired")
```
```
➜ (adienes) ./julia --heap-size-hint=1500M gc_thrash_mwe.jl
0.449891 seconds (20.03 M allocations: 1.121 GiB, 64.03% gc time, 4.14% compilation time)
PASS: cache shed under pressure
➜ (adienes) julia +nightly --heap-size-hint=1500M gc_thrash_mwe.jl
0.619595 seconds (20.03 M allocations: 1.121 GiB, 75.61% gc time, 2.99% compilation time)
FAIL: pressure callback never fired
```
Discovered via automated Claude audit for typos and other minor /
obvious bugs.
(cherry picked from commit e98d248)
Replace manual insertion point save/restore operations with RAII-based InsertPointGuard. This ensures insertion points properly restore debug information too. With credit to abraemer for diagnosing and suggesting the fix. Fix: #61095 Co-authored-by: Adrian Braemer <adrian.braemer@tngtech.com> Co-authored-by: Claude Sonnet 4.5 <noreply@anthropic.com> (cherry picked from commit 1003b8d)
…61120) discovered via automated Claude audit for typos and other minor / obvious bugs. I manually reviewed each result I was less sure about this one but robot seems confident so I'm pasting the message it gave as-is Add a `jl_gc_wb` in `jl_update_loaded_bpart` after storing `resolution.binding_or_const` into an existing (potentially old-generation) binding partition's restriction field, matching every other non-fresh store to this field. Add a `jl_gc_wb_fresh` in `jl_replace_binding_locked2`'s `IMPLICIT_RECOMPUTE` path, where `jl_resolve_implicit_import` can trigger GC between the allocation of `new_bpart` and the store, potentially promoting the fresh partition to an older generation. The else branch already had the corresponding `jl_gc_wb_fresh`. Neither bug is currently triggerable because the stored values are always independently rooted through the module binding table, but the barriers are needed to maintain GC invariants and guard against future code changes. Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com> (cherry picked from commit f6fd24c)
Backports #61062 (Fix extra linenode added to non-block function body)
We only support a few built-in versions of this call (due to #57830), but those should at least be working now with this small tweak. This required a fix-up for built-in functions to be included in the method table for `--trim`'d executables, so that we can dynamically dispatch to them, as the verifier expects.
These lead to 10-20x speedups in Revise's fieldtype-caching
(cherry picked from commit ce747fe)
`ismalformed()` is not exported from `Base`, so we need to qualify it when calling. Detected by JET. (cherry picked from commit 1cd77b5)
Keeping this a ccall before adding a julia level API so we can back out if wanted later (cherry picked from commit 370a2a0)
topolarity
force-pushed
the
backports-release-1.12
branch
from
de798fb to
4c74b14
Compare
Member
Author
|
The revise error is purely testing preference handling: It creates a preference file, runs Revise and checks that it picks up the new preference. But that doesn't happen here for some reason? |
These `@assert`s are not directly problematic for `--trim` (thanks to an overload / monkey patch it does), but they can cause false positives for dynamic dispatches in JET and similar tools so it's probably best to replace them with the 2-arg variant (which just needs to print a String, rather than an `Expr` containing arbitrary Julia objects)
…emoryrefnew` (#61137) The Serialization stdlib has the following function: https://github.com/JuliaLang/julia/blob/e46125f569f43e28261d1b55a0d85aacceee499a/stdlib/Serialization/src/Serialization.jl#L1445-L1450 As far as I can tell, there is no method matching `Core.memoryref(x::MemoryRef, i::Int, true::Bool)` (called on line 1448).[^1] [^1]: This issue was detected by JET. I think this should be a call to `Core.memoryrefnew(x::MemoryRef, i::Int, true::Bool)` instead, which is what this PR does. (cherry picked from commit acd9708)
(cherry picked from commit 3ff8e7b)
The sret parameter's alignment attribute was set to LLVM's preferred type alignment (getPrefTypeAlign), which can exceed julia_alignment. This caused misaligned memory accesses on strict-alignment targets like NVPTX, since the caller's alloca uses julia_alignment. Fix by setting the sret alignment to julia_alignment and not overriding it in the function definition, so that caller and callee agree on the same alignment. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
When a custom method table is defined in one package and imported by another, jl_foreach_reachable_mtable visits the same table twice (once per module binding). This causes extext methods to be collected and serialized twice, and on loading, jl_method_table_activate asserts because dispatch_status was already set by the first activation. Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
…61220) Methods created with custom source data (e.g. via CompilerCaching's add_method which stores domain-specific IR) are neither CodeInfo nor compressed String. Return 0 instead of asserting, since such methods cannot have image globalrefs. Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com> Co-authored-by: Cody Tapscott <84105208+topolarity@users.noreply.github.com>
Co-authored-by: Codex <codex@openai.com> (cherry picked from commit 18827b7)
As the documentation mentions it explicitly and e.g. suggest using [FileWatching.Pidfile.mkpidfile](https://docs.julialang.org/en/v1.12/stdlib/FileWatching/#FileWatching.Pidfile.mkpidlock) among other things. Without this, [ExplicitImports](https://github.com/JuliaTesting/ExplicitImports.jl) complains (CC @ericphanson) (cherry picked from commit cb4cc11)
This was referenced Mar 12, 2026
Member
Author
|
@nanosoldier |
Member
|
Can #61290 still be included here? |
Collaborator
|
The package evaluation job you requested has completed - possible new issues were detected. Report summary❗ Packages that crashed3 packages crashed only on the current version.
40 packages crashed on the previous version too. ✖ Packages that failed29 packages failed only on the current version.
3577 packages failed on the previous version too. ✔ Packages that passed tests42 packages passed tests only on the current version.
6468 packages passed tests on the previous version too. ➖ Packages that were skipped altogether3 packages were skipped only on the current version.
1397 packages were skipped on the previous version too. |
Member
Author
|
@nanosoldier |
Member
Author
Technically yes, but since it is a change to the precompile code I feel maybe it is better it gets tested out on master a bit before getting into a release... Not sure though, it's a good improvement for workspaces.. |
Member
|
Honestly that issue has made my experience with workspaces fairly poor, having to spend lots of time during development precompiling packages unnecessarily (and I believe other people had the same) |
…tion (#61264) When a const-prop frame encounters a cycle and gets poisoned, `finishinfer!` marks the result as tombstoned and sets `cache_mode = CACHE_MODE_NULL`, which prevents `promotecache!` from pushing the result to the local inference cache. Meanwhile, `constprop_cache_lookup` (added in #57545) skips tombstoned entries entirely. This combination means the same const-prop is re-attempted on every cycle iteration, causing inference to never terminate when `aggressive_constant_propagation = true`. Fix this by: - In `const_prop_call`, explicitly pushing tombstoned results to the inference cache after a successful but limited `typeinf`, and returning `nothing` to fall back to the regular inference result. - In `constprop_cache_lookup`, no longer skipping tombstoned entries so they can be found on subsequent lookups, preventing re-attempts. - In `const_prop_call` cache-hit path, checking `inf_result.tombstone` and returning `nothing` (same as the existing cycle-hit handling). - Removing the now-unnecessary tombstone check from `OverlayCodeCache.get`, where the subsequent `overridden_by_const` and `isdefined` checks already filter out such entries. Note that #57545 added `tombstone && continue` to `cache_lookup` to prevent `LimitedAccuracy` results from propagating to callers via `const_prop_result`. This change removes that skip but achieves the same protection by explicitly checking `inf_result.tombstone` in `const_prop_call` and returning `nothing` instead of using the result. Fixes #61257 Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
Collaborator
|
The package evaluation job you requested has completed - possible new issues were detected. Report summary✖ Packages that failed1 packages failed only on the current version.
2 packages failed on the previous version too. ✔ Packages that passed tests21 packages passed tests on the previous version too. |
division (unlike the other intrinsics) can have table-maker dilema problems since the true result has infinite bits. Bumping the slop for it by 1 reduces failures from 80 in 10^10 to <1 in 10^11. I think accepting an extra bit of inaccuracy is reasonable here (the alternative would be to make the division do an extra loop and do some extra extended precision, which seems unlikely to be worth it. fixes #23497 Co-authored-by: oscarddssmith <oscar.smith@juliacomputing.com> (cherry picked from commit 884c5e3)
Member
Author
|
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
18 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Backported PRs:
jl_exit_threaded_regionexecuted whenthreading_runfinished or be interrupted #60822TOMLandPkgas test dependencies #60891--depwarn=error#60892constGlobalRefas method root #60945Base.show(io::IO, b::Binding)for e.g.:(:)or:(==)#61043@testset#59321fieldtypesandInteractiveUtils._subtypes_in!#61156Need manual backport:
show(::IOBuffer, ::StackFrame)#60645jl_method_lookup_by_ttfor custom method tables. #60718@invokelatest#60727Core._apply_iterate#60062@asserts with 2-arg #61230Contains multiple commits, manual intervention needed:
Base.donotdeletepublic #55774Non-merged PRs with backport label:
Base.ismalformedwhen calling it #61140issimpleenoughtypefor PartialStruct duringissimplertype#61130Memoryin heap snapshot #60930inline_cost_threshold == typemax(Int)#60121