Backports for 1.12.1 #59705
Merged
Backports for 1.12.1 #59705
Conversation
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
KristofferC
force-pushed
the
backports-release-1.12
branch
from
2e71e44 to
2907ebd
Compare
|
Can #59063 be added to this list? The changes made in the PR are minimal and fix a rounding bug when converting |
|
I think we can backport it, if there are no particular objections from cc @adienes @oscardssmith. |
|
none here |
|
none |
aviatesk
force-pushed
the
backports-release-1.12
branch
from
acdc210 to
3c7e88b
Compare
vchuravy
reviewed
Oct 9, 2025
|
Since #59165 is marked as a "minor change" and it seems to break some packages in practice (like CxxWrap and a few other ones mentioned in #59165 (comment)), I don't think this should be backported to 1.12. |
vchuravy
pushed a commit
that referenced
this pull request
Oct 10, 2025
KristofferC
force-pushed
the
backports-release-1.12
branch
from
91de0a1 to
420d5a2
Compare
This was referenced Oct 12, 2025
|
Try to not put merge commits on here. If you want to rebase it, just rebase. |
…59631) Setting world bounds on the created `CodeInfo` allows us to interpret opaque closures faster. Taking the following example: ```julia julia> f(x, y) = x + y f (generic function with 1 method) julia> ir = Base.code_ircode_by_type(Tuple{typeof(f), Int, Int})[1][1] 1 1 ─ %1 = intrinsic Base.add_int(_2, _3)::Int64 │╻ + └── return %1 ││ julia> ir.argtypes[1] = Tuple{} Tuple{} julia> oc = Core.OpaqueClosure(ir; do_compile=true) (::Int64, ::Int64)->◌::Int64 ``` this is what we emitted before ```julia julia> @code_typed oc(1, 2) Pair{Core.CodeInfo, Any}(CodeInfo( @ REPL[8]:1 within `f` ┌ @ int.jl:87 within `+` 1 ─│ %1 = dynamic Base.add_int(none@_2, none@_3)::Int64 └──│ return %1 └ ), Int64) julia> using BenchmarkTools; @Btime $oc(1, 2) 39.765 ns (0 allocations: 0 bytes) ``` and now: ```julia julia> @code_typed oc(1, 2) Pair{Core.CodeInfo, Any}(CodeInfo( @ REPL[93]:1 within `f` ┌ @ int.jl:87 within `+` 1 ─│ %1 = intrinsic Base.add_int(none@_2, none@_3)::Int64 └──│ return %1 └ ), Int64) julia> using BenchmarkTools; @Btime $oc(1, 2) 2.678 ns (0 allocations: 0 bytes) ``` The overhead notably adds more and more with every statement, which for ~20 statements led to > 1 µs of overhead, and multiple allocations. This overhead is observed on 1.12+ only (1.11 evaluates as fast as with this change), which may have been surfaced by the partitioned bindings feature. (cherry picked from commit a5576b4)
Add `gcdx(a::Signed, b::Unsigned)` and `gcdx(a::Unsigned, b::Signed)` methods to fix #58025: ```julia julia> gcdx(UInt16(100), Int8(-101)) # pr (0x0001, 0xffff, 0xffff) julia> gcdx(UInt16(100), Int8(-101)) # master, incorrect result (0x0005, 0xf855, 0x0003) ``` Also add the equivalent methods for `lcm` to fix the systematic `InexactError` when one argument is a negative `Signed` and the other is any `Unsigned`: ```julia julia> lcm(UInt16(100), Int8(-101)) # pr 0x2774 julia> lcm(UInt16(100), Int8(-101)) # master, error ERROR: InexactError: trunc(UInt16, -101) Stacktrace: [1] throw_inexacterror(func::Symbol, to::Type, val::Int8) @ Core ./boot.jl:866 [2] check_sign_bit @ ./boot.jl:872 [inlined] [3] toUInt16 @ ./boot.jl:958 [inlined] [4] UInt16 @ ./boot.jl:1011 [inlined] [5] convert @ ./number.jl:7 [inlined] [6] _promote @ ./promotion.jl:379 [inlined] [7] promote @ ./promotion.jl:404 [inlined] [8] lcm(a::UInt16, b::Int8) @ Base ./intfuncs.jl:152 [9] top-level scope @ REPL[62]:1 ``` Inspired by #59487 (comment). The difference is that the solution proposed in this PR keeps the current correct result type for inputs such as `(::Int16, ::UInt8)`. (cherry picked from commit 4f1e471)
Previously, add_ptr and sub_ptr intrinsics were incorrectly inferred as potentially throwing because they fell through to the general primitive type check, which was incorrect after #53687 changed them. This adds explicit handling in intrinsic_exct to return Union{} (nothrow) when given correct argument types (Ptr and UInt), similar to #57398. Fixes #57557 Written by Claude
the comment claims: > When the concrete type of p is signed and has the lowest value, > `p != 0 && p == -p` is equivalent to `p == typemin(typeof(p))` this is true, but fails to consider that `p == -p` is also true when `p = div(typemax(UInt), 2) + 1`, and that `p` is not necessarily signed leading to incorrect results on inputs like ``` julia> powermod(0x03, 0x80, 0x07) 0x01 ``` which should be `0x02` (cherry picked from commit bb3be0d)
Fixes #44679 Co-authored-by: KristofferC <[email protected]> (cherry picked from commit 65ef689)
maxsize is usually typemax, so need to be careful to not do comparisons after adding to it. Substracting from it should normally be perfectly fine. At worst we should compute a negative amount of space remaining. (cherry picked from commit 85687b5)
(cherry picked from commit 47908c8)
KristofferC
force-pushed
the
backports-release-1.12
branch
from
e571437 to
8acdf9c
Compare
…50874)" (#59736) This reverts commit eb4416b. As of LLVM 16, we automatically emit: ``` .drectve `-exclude-symbols:"<symbol>"` ``` which mitigates this issue where it is supported by the linker (GCC 11+ and LLD 14+ are tested working) PackageCompiler on Windows now ships GCC 14 (JuliaLang/PackageCompiler.jl#1012), so we should no longer need this workaround that can make a 15-minute sysimage compilation take an hour+ (cherry picked from commit 1cba9c2)
Fixes #59222. This issue was caused by a mismatch with `jl_new_opaque_closure_from_code_info_in_world` filling in the unnormalized method instance, and `new_opaque_closure` getting its `spec_ptr` from the normalized one via `jl_compile_method_internal`. For example, `g(xs...)` specialized as `g(:a, :b)` resulted in a different method instance than the corresponding normalized one: ```julia Tuple{Tuple{typeof(Main.g)}, Symbol, Symbol} # unnormalized Tuple{Tuple{typeof(Main.g)}, Symbol, Vararg{Symbol}} # normalized ``` Here I chose to align on using the unnormalized one from the `CodeInfo` at `OpaqueClosure` construction (the fix being a single-line change in that case), but we could also choose the normalized one if that is deemed preferable, so long as we use the same when storing the inferred code and when retrieving the `spec_ptr`. --- 🤖 Generated with some assistance from Claude Code. (cherry picked from commit e8667fb)
Fix #59008. `globalref`s are OK to assign to. This check isn't actually necessary since we check the lhs again when re-expanding the assignment, and most of the forms allowed through aren't valid with a non-dotted `op=`, but deleting it makes some error messages worse. (cherry picked from commit 5ddcea7)
(cherry picked from commit 9534147)
I also noticed that the standard Base.show_type_name appears to be trimmable so we don't need the override. We might still want it for code size, but probably not a big deal. (cherry picked from commit 12f7bb5)
When a macro expands to `:toplevel` expression, it seems reasonable (as would be if the expression were not wrapped in `:toplevel`) that any contained struct definitions be available thereafter. For example, this applies to `@enum`, which countrly causes world age erros when attempting to define a method on an enum within the same expression. Fix this by having lowering insert and explicit `latestworld` after toplevel. Fixes #59429 Written by Claude (cherry picked from commit 0c8768f)
This uses inferred element types to make the iterator state type-stable, enabling inlining, which can enable the runtime to see the real types. This is essentially the transform that we want inference to infer and codegen to implement, except made explicit so that we can rely on it actually happening. Fix #56607 ``` julia> @Btime f() 574.500 ns (2 allocations: 272 bytes) # non-const op 253.878 ns (2 allocations: 272 bytes) # const op ``` (cherry picked from commit 498d982)
(cherry picked from commit b76c189)
#59766) Currently this is an ErrorException in the runtime/interpreter, but a TypeError in codegen. This is not permitted - which error is thrown is semantically observable and codegen is not permitted to change it. Worse, inference is also inconsistent about whether this is TypeError or ErrorException, so this could actually lead to type confusion and crashes. Fix all that by having the runtime also emit a TypeError here. However, in order to not lose the binding name in the error message, adjust the TypeError context field to permit a binding. (cherry picked from commit 17e0df5)
… in-use DLL (#59635) On Windows, during precompilation of package `A`, a DLL file is generated and may replace the existing one. If `A` is already loaded in the julia session however, the corresponding soon-to-be-obsolete DLL cannot be removed while julia is running. Currently, this problem is solved by moving the old DLL in a special "julia_delayed_deletes" folder, which will be cleaned in a later julia session by `Pkg.gc()`. However, moving an in-use DLL is only permitted on the same drive, and the "julia_delayed_deletes" is located in the `tempdir`, a.k.a. on a fixed drive, say `C:`. Thus, if the `DEPOT_PATH` points to a ".julia" in another drive, say `D:`, any precompilation occuring on an already loaded package will fail. This is what happens in #59589, actually resulting in an infinite loop that bloats up both memory and disk. @staticfloat had actually predicted that such an issue could occur in #53456 (comment). This PR fixes #59589 by changing the "delayed deleting" mechanism: instead of moving the old DLLs to a fixed folder, they are renamed in their initial folder and recorded in a list stored at a fixed location. Upon `Pkg.gc()`, the listed obsolete files will be deleted (JuliaLang/Pkg.jl#4392). It also prevents any similar infinite loops by cutting the `rm -> mv -> rm` cycle into `rm -> rename`. ~I also removed the private argument `allow_delayed_delete` from `rm`, which is only called in by [Pkg](https://github.com/JuliaLang/Pkg.jl/blob/7344e2656475261a83a6bd37d9d4cc1e7dcf5f0d/src/API.jl#L1127) but does not appear to be useful.~ EDIT: current state is #59635 (comment) --------- Co-authored-by: Jameson Nash <[email protected]> Co-authored-by: Elliot Saba <[email protected]> (cherry picked from commit 3e2a4ed)
Add some concrete `typeassert`s to increase the resistance of the sysimage to invalidation by helping inference within the method body. (cherry picked from commit bb51d56)
(cherry picked from commit 0635285)
Add back support for -debug builds and define ability to use shared library builds more places in the file. Fix #57675 (cherry picked from commit 51da540) Fixes #57675 (comment) and #57758 (comment) Co-authored-by: Jameson Nash <[email protected]>
This points to the [`release-julia-1.12` branch](https://github.com/JuliaCI/julia-buildkite/tree/release-julia-1.12) in the https://github.com/JuliaCI/julia-buildkite repo.
(cherry picked from commit 9808816)
(cherry picked from commit e4a3a2a)
(cherry picked from commit a817940)
KristofferC
force-pushed
the
backports-release-1.12
branch
from
1160209 to
971c4af
Compare
|
@nanosoldier |
(cherry picked from commit c171ddb)
|
|
|
as noted in #59668 (comment), it's |
|
The package evaluation job you requested has completed - possible new issues were detected. Report summary❗ Packages that crashed1 packages crashed only on the current version.
✖ Packages that failed2 packages failed only on the current version.
✔ Packages that passed tests11 packages passed tests on the previous version too. |
KristofferC
force-pushed
the
backports-release-1.12
branch
from
2d37b16 to
4f05d8d
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
22 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:
CodeInfocreated forOpaqueClosure(::IRCode)#59631Core._svec_len#59706abstract_eval_nonlinearized_foreigncall_name#59722powermodcorrectness on unsigned power of half typemax #59680prevfloatwith unsigned stepcount #59668Need manual backport:
:to makereshapetrimmable #59598Contains multiple commits, manual intervention needed:
CoreLogging: prevent someAnnotated*-related instability #59467Non-merged PRs with backport label:
@threadsthreadpool #59802maxthreadidfromThreads#57490