Backports for 1.13.0-rc2#61987
Merged
Merged
Conversation
previously: ```julia # WRONG. output should be length 5, not 6. the last value here is junk from `similar` julia> map(&, rand(6) .> 0.5, rand(5) .> 0.5) 6-element BitVector: 0 0 0 1 0 0 julia> dest = falses(64); julia> map!(&, dest, trues(65), trues(64)); # what on earth?? should be 64 julia> count(dest) 1 ``` the `and_iteratorsize` change is slightly drive-by but it makes the implementation nicer (and more parallel to `Array`, so if one changes they'll stay in sync). incidentally, it actually helps performance for some `collect(zip(..))` calls too ```julia julia> using BenchmarkTools julia> @Btime collect(z) setup=z=zip(1:10000, rand(100, 100)); 15.875 μs (16 allocations: 437.53 KiB) # master 3.344 μs (3 allocations: 160.06 KiB) # PR ``` codeveloped (mostly tests) with codex 5.5 --------- Co-authored-by: Nathan Zimmerberg <39104088+nhz2@users.noreply.github.com> (cherry picked from commit 8cb3325)
Improves stacktraces and `methods(...)` queries for any Methods defined through @enum: ```julia julia> @enum Fruit Apple=1 Banana=2 julia> methods(Fruit) [1] Fruit(x::Integer) @ REPL[6]:1 ``` versus before: ```julia julia> methods(Fruit) [1] Fruit(x::Integer) @ Enums.jl:211 ``` (cherry picked from commit d2456dc)
) Claude Opus 4.7 xhigh spotted this one when I was making some unrelated changes (I'm impressed!). #57252/378a42508d4 introduced this bug when extracting the code for `jl_gc_wb_genericmemory_copy_boxed` from `jl_genericmemory_copyto`: the caller assumes `src_p` and `dest_p` will be updated to point to the remaining elements `memmove_refs` must copy, but we no longer mutate them. I had Claude turn them into pointers, so they are updated like before. Nifty PoC: ```julia dest = Any[nothing for i=1:16] for i in 1:2 GC.gc(true) GC.gc(false) end src = vcat(Any[nothing], Any[Ref(100 * i) for i=1:15]) copyto!(dest, src) for (i, (x, y)) in enumerate(zip(dest, src)) if x !== y println("dest[$i] = $x, expected src[$i] = $y") end end ``` (cherry picked from commit e092315)
Improves stacktraces and `methods(...)` queries for any Methods defined through `@deprecate`: ```julia julia> @deprecate foo(x::Int) rand(x) foo (generic function with 1 method) julia> methods(foo) [1] foo(x::Int64) @ REPL[3]:1 ``` versus before: ```julia julia> methods(foo) [1] foo(x::Int64) @ deprecated.jl:215 ``` (cherry picked from commit 10e3e21)
KristofferC
changed the title
… speed up GC (#61474) (#62009) This is a backport of #61474 and part of #61937, to restore the old heap snapshot behavior. The snapshot implementation is now quite awkward, since the image remset expects to mark its objects quite early. However for the snapshot, we want to ignore any reachability from the image remset. That means the remset must not be marked until very late, so that we can fully collect the reachable object graph for the other "normal" roots. Nonetheless this seems like a good compromise on 1.13. I have locally verified that a snapshot with the 1.13 RC1 sysimage gives a ~nearly identical heap (~200 objects differ, out of 1.6M) --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Member
|
The hang in https://buildkite.com/julialang/julia-release-1-dot-13/builds/192#019e8930-35bd-4ba3-b7a4-dcfd0e8f38da/L1479 looks like it might be a new regression
|
Member
|
Looks like the second failure should be cleaned up by 65d2f85 (already in the backports here). The hang also looks like it might just be a slow CI job terminating I think both failures may be OK after all 👍 |
These inline statements would fix the issue with juliaC JuliaLang/JuliaC.jl#146. (cherry picked from commit 7b9dfc8)
`add_one_edge!` previously deduplicated by `MethodInstance` alone, dropping any subsequent `CodeInstance` whose `def` matched an existing edge. When two const-prop'd pseudo `CodeInstance`s for the same method record different forward edges (e.g. distinct `Binding` edges produced by const-prop'ing the same callee with different constant arguments), the second one was silently discarded, breaking invalidation of the caller when its bindings were redefined. Only dedup when the existing entry is the same object or its forward edges are identical and its world range covers the new one; otherwise keep both. This was found by Claude looking at #61745, but is a distinct issue AFAICT. Co-authored-by: Keno Fischer <Keno@users.noreply.github.com> Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com> (cherry picked from commit 829b43f)
From the `unw_init_local(3)` man page: > If the unw_context_t is known to be a signal frame (i.e., from the > third argument in a sigaction handler on linux), unw_init_local2() > should be used for correct initialization on some platforms, > passing the UNW_INIT_SIGNAL_FRAME flag. Only tested briefly but this appears to resolve #61658 on AArch64 Linux for me. (cherry picked from commit bfbe2b5)
Fixes #61914, using the suggestion by Opus 4.6. (Thanks to @JeffBezanson for confirmation that the original issue was real) Here's a simpler example I used to understand the problem: ``` T = TypeVar(:T) a = UnionAll(T, Union{Vector{T}, Int64}) ``` Now, when we do `Union{a, T}`, we get `Union{Int64, Vector, T}` like expected, since the `T` on the RHS is not bound by the UnionAll, and the UnionAll of Union was rewritten to Union of UnionAll, leaving us with `UnionAll(T, Vector{T}) == Vector`. `Union{T, a}` gave us the wrong answer because `flatten_type_union`, when doing the UnionAll of Union transform, would re-wrap every Union component from the beginning of the `out` with the UnionAll's variable, even if those components were not originally under the UnionAll. The `out` array would go from `T, Vector{T}, Int64` to `UnionAll(T, T) => Any, UnionAll(T, Vector{T}) => Vector, UnionAll(T, Int64) => Int64`, leaving us with `Any`. (cherry picked from commit f5586d6)
We already have a trim-compatible TOML parser, so just a bit of a touch-up is required here. (cherry picked from commit fd1b66a)
`emit_globalref` resolves `getglobal(::Module, ::Symbol)`-style calls into a constant load whenever the binding's leaf partitions are consistent across the `CodeInstance`'s world range. This optimization is only safe under binding redefinition if the `CodeInstance` has a forward edge to the binding, since invalidation otherwise has no way to reach the cached code. Inference records such edges via `GlobalAccessInfo` for accesses it sees directly, but accesses that only appear after inlining (e.g. when a `Module`-typed slot is substituted with a literal `Module`) leave no edge behind. Plumb the `CodeInstance` through `jl_emit_code` / `emit_function` and fall back to the runtime binding load when the binding is not among the CI's forward edges. Fixes #61745. Co-authored-by: Keno Fischer <Keno@users.noreply.github.com> Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com> (cherry picked from commit ea54e8d)
Member
Author
|
On Mac sigh |
Member
|
That looks like the worker being torn down after hitting the timeout limit Not sure what is causing it to hit the timeout though |
Member
Author
|
Yes, the point was used to show that many different workers are timing out. |
Co-authored-by: Ian Butterworth <i.r.butterworth@gmail.com> (cherry picked from commit e7d85ea)
Otherwise `muladd` doesn't respect the "strong zero property" of `false`. Fixes JuliaSparse/SparseArrays.jl#724 (cherry picked from commit dc9142e)
KristofferC
force-pushed
the
backports-release-1.13
branch
from
4ab92a8 to
faa8842
Compare
Member
Author
Concerning |
Xcode 26's clang (clang 21) folds the new `-Wc++-keyword` diagnostic into `-Wc++-compat`, which the `src/`, `src/support/`, and `src/flisp/` Makefiles enable for C code. Uses of C++ keywords as ordinary identifiers in C — e.g. the `wchar_t` typedef in `src/support/utf8.c` — then fail to compile under `-Werror` (as used on CI). Co-authored-by: Claude Fable 5 <noreply@anthropic.com> (cherry picked from commit c8851d0)
Since this function has not appeared in a released version of Julia, this is not breaking. I don't think we should promise an actual `String` when the input type is generic. This means the function cannot be used for other `AbstractString`- returning objects. Also, add compat note and update return type notation to the modern form. `takestring!` was introduced in github.com//pull/54372 Co-authored-by: Chengyu Han <git@wo-class.cn> (cherry picked from commit 5287577)
When we enabled `-dead_strip` on macOS in #60248, we started stripping out the fasttls definitions in the julia loader binary (ld64, unlike BFD ld or lld, considers only symbols reachable from the entrypoint of an executable, rather than everything reachable from symbols with "default" visibility). Restore this by marking those symbols as exported on the linker command line. After: ``` $ nm --extern-only -U usr/bin/julia 0000000100000668 T _jl_get_pgcstack_static 000000010000068c T _jl_pgcstack_addr_static 0000000100008038 S _jl_pgcstack_static_semaphore 00000001000006ac T _main ``` (cherry picked from commit 5e1d4a9)
Seems like we've been force-compiling pkgimages to `-O3` when the default is `-O2`, although the effect seems quite small. (cherry picked from commit 66d0911)
(cherry picked from commit 3eee834)
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
13 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:
map(f, ::BitArray...)#61895@enum#61932@deprecate#61931zipanditerate) to new definitions oftail#62002merge(::Callable ..)#60027muladdwithBoolarguments #61961Need manual backport:
libunwindinit in signal handler context #61969Base.get_preferences()--trim-compatible #61971Contains multiple commits, manual intervention needed:
@spawn#61826Non-merged PRs with backport label:
Backport process completed in 12.2s