release-1.10: Backports for 1.10-alpha2 #50508
Conversation
(cherry picked from commit d70ee20)
Co-authored-by: Gabriel Baraldi <[email protected]> (cherry picked from commit e025877)
(cherry picked from commit 7e3c706)
(cherry picked from commit 435c1c1)
(cherry picked from commit c09a199)
(cherry picked from commit 0718995)
(cherry picked from commit 236c23b)
(cherry picked from commit 206e59a)
…50488) See #49827 (comment) (cherry picked from commit e2e34f6)
vchuravy
changed the title
`Core._svec_ref` has accepted `boundscheck`-value as the first argument since it was added in #45062. Nonetheless, `Core._svec_ref` simply calls `jl_svec_ref` in either the interpreter or the codegen, and thus the `boundscheck` value isn't utilized in any optimizations. Rather, even worse, this `boundscheck`-argument negatively influences the effect analysis (xref #50167 for details) and has caused type inference regressions as reported in #50544. For these reasons, this commit simply eliminates the `boundscheck` argument from `Core._svec_ref`. Consequently, `getindex(::SimpleVector, ::Int)` is now being concrete-eval eligible. closes #50544
…current dir is unwritable (#50476) Co-authored-by: Valentin Churavy <[email protected]> (cherry picked from commit 0f6bfd6)
(cherry picked from commit e64d201)
In the presence of `attach_after` insertions, we have to be careful to extend the basic block to include everything up to the last insertion. We were accounting for "new" nodes (before the compaction point), but not "pending" nodes (after the compaction point). Fixes #50379. (cherry picked from commit cdec4c2)
Fixes the case from #50518, but we actually have two test cases in the tests that also hit this (e.g. this one: ``` f40964(xs::Int...=1; k = 2) = (xs, k) ```), but just happened not to hit the bad codegen path. #50556, once merged would have complained on those definitions as well, without this fix. (cherry picked from commit c272236)
(cherry picked from commit e67ddaa)
At present we only record direct `innervars` (`T` -> `S<:Val{T}`). And chained `innervars` might be ignored (`T` -> `S<:Val{V<:T}`\
This commit fix it.
(cherry picked from commit cd74337)
Fixes #50532. The `read(io, Char)` method didn't correctly handle the case where the lead byte starts with too many leading ones; this fix makes it handle that case correctly, which makes `read(io, Char)` match `collect(s)` in its interpretation of what a character is in all invalid cases. Also fix and test `read(::File, Char)` which has the same bug. (cherry picked from commit ffe1a07)
* Use SparseArrays.jl updated to work with SuiteSparse 7, and with Int32 indices * SuiteSparse_jll Update to v7.2.0 (Using @Wimmerer's SuiteSparse fork for 32-bit QR) --------- Co-authored-by: Francois-Xavier Coudert <[email protected]> Co-authored-by: Will Kimmerer <[email protected]> (cherry picked from commit b26f3b2)
|
@nanosoldier |
|
FWIW, Nanosoldier defaults to using Julia + LLVM assertions now, so no need for the complicated invocation. |
|
The package evaluation job you requested has completed - possible new issues were detected. |
(cherry picked from commit 28720ff)
In #48919, the tid selection logic inside `enq_task` gained a `!GC.in_finalizer()` condition. However, this made it possible for `workqueue_at` to be reached with `tid==0`, which would attempt and out-of-bounds write under `@inbounds`, corrupting memory. This was not caught in the test suite despite `--check-bounds=yes`, because our `--check-bounds=yes` is currently best effort. That would be fixed by #50239, which exposed this bug. This PR attempts to fix this by marking any tasks launched inside a finalizer as not sticky. Finalizers don't have any thread they run on semantically, so i don't think there's a meaningful sense in which tasks launched inside finalizers could be sticky. (cherry picked from commit bd8350b)
Trying for cross-compile and disabling CSL and realized both of those configurations were broken now. (cherry picked from commit 9dc1380)
Optimizes invalid object lookup in conservative GC by just looking at the page metadata and GC bits. (cherry picked from commit c82656d)
Stdlib: SparseArrays URL: https://github.com/JuliaSparse/SparseArrays.jl.git Stdlib branch: main Julia branch: master Old commit: b4b0e72 New commit: 99c99b4 Julia version: 1.11.0-DEV SparseArrays version: 1.10.0 (Does not match) Bump invoked by: @dkarrasch Powered by: [BumpStdlibs.jl](https://github.com/JuliaLang/BumpStdlibs.jl) Diff: JuliaSparse/SparseArrays.jl@b4b0e72...99c99b4 ``` $ git log --oneline b4b0e72..99c99b4 99c99b4 Specialize 3-arg `dot` for sparse self-adjoint matrices (#398) cb10c1e use unwrapping mechanism for triangular matrices (#396) b3872c8 added warning for iterating while mutating a sparse matrix (#415) f8f0f40 bring coverage of fixed SparseMatrixCSC to 100% (#392) 0eb9c04 fix typos (#414) ``` Co-authored-by: Dilum Aluthge <[email protected]> (cherry picked from commit 6691a75)
- llvm/llvm-project@af39acd closing #50448 - https://reviews.llvm.org/D139078 closing #49907 (cherry picked from commit 092231c)
(cherry picked from commit e23e116)
This fixes certain possible regressions in `isassigned` for ranges to restore the 1.9-like behavior. On v1.9 ```julia julia> r = 1:big(2)^65 1:36893488147419103232 julia> isassigned(r, lastindex(r)) true julia> isassigned(r, true) ERROR: ArgumentError: invalid index: true of type Bool ``` On v1.10.0-alpha1 ```julia julia> isassigned(r, lastindex(r)) ERROR: InexactError: Int64(36893488147419103232) julia> isassigned(r, true) # Bool is converted to Int true julia> r[true] # but indexing with Bool doesn't work ERROR: ArgumentError: invalid index: true of type Bool ``` This PR ```julia julia> isassigned(r, lastindex(r)) true julia> isassigned(r, true) ERROR: ArgumentError: invalid index: true of type Bool ``` This still leaves ```julia julia> isassigned(collect(1:3), true) true ``` so that should perhaps be changed as well. (cherry picked from commit d270a71)
This PR implements GC heuristics based on the amount of pages allocated instead of live objects like was done before. The heuristic for new heap target is based on https://dl.acm.org/doi/10.1145/3563323 (in summary it argues that the heap target should have square root behaviour). From my testing this fixes #49545 and #49761 (cherry picked from commit 32aa29f)
This comment was marked as outdated.
This comment was marked as outdated.
(cherry picked from commit b99f251)
|
@nanosoldier |
This comment was marked as outdated.
This comment was marked as outdated.
|
The package evaluation job you requested has completed - possible new issues were detected. |
|
#50578 is wrecking havoc but I guess that we just have to get through it... |
Backported PRs:
!!! notewhich was miscapitalized #50474Base.isassignedwithTridiagonal#50488take_heap_snapshotand handling if current dir is unwritable #50476innervars#50551generic_lufactwhencheck=true#50525Need manual backport:
JULIA_USE_NEW_PARSER->JULIA_USE_FLISP_PARSER#50595Non-merged PRs with backport label:
Array(::AbstractRange)should return anArray#50568