Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Backports for 1.10.6 #55746

Merged
merged 35 commits into from
Oct 22, 2024
Merged

Backports for 1.10.6 #55746

merged 35 commits into from
Oct 22, 2024

Conversation

KristofferC
Copy link
Member

@KristofferC KristofferC commented Sep 12, 2024

Backported PRs:

Need manual backport:

Contains multiple commits, manual intervention needed:

Non-merged PRs with backport label:

mbauman and others added 9 commits September 12, 2024 10:54
More finely scope the `@inbounds` annotations to ensure neither `f` nor
`op` are erroneously `@inbounds`ed.

(cherry picked from commit 1dffd77)
Some methods were filtered out based simply on visit order, which was
not intentional, with the lim==-1 weak-edges mode.

Fix #55231

(cherry picked from commit 1db5cf7)
Currently, "API reference" is at the same level as "Dates" although it
is a subsection of it. This looks particularly weird in the PDF version
of the manual: Section 67 is "Dates" and Section 68 is "API reference".

Note that I didn't change the nesting level of the subsection
"Constants" at the end of the file. As a result, it is now at the same
level as "Dates and Time Types" and "Dates Functions". Before it was a
subsection of the latter, which appears wrong to me.

(cherry picked from commit 881be64)
fixes #55266, and use `inv(z)`
rather than `1/z` and use `muladd` in a couple places.

---------

Co-authored-by: Mosè Giordano <giordano@users.noreply.github.com>
(cherry picked from commit b7aa5e3)
This brings the docstring closer to the actual implementation. In
particular, following the current docstring and defining
```julia
symmetric(::MyMatrix, uplo=:U)
```
leads to a method ambiguity, as `LinearAlgebra` defines
`symmetric(::AbstractMatrix, uplo::Symbol=:U)`.

(cherry picked from commit 8a19b74)
This sets all `.jl` files in `$(prefix)/base` and `$(prefix)/test` to
have `0444` permissions, to better match how `Pkg` installs packages
(and sets them to be read-only).

Fixes JuliaLang/juliaup#865

---------

Co-authored-by: Mosè Giordano <765740+giordano@users.noreply.github.com>
(cherry picked from commit 62e7705)
Let's change `jl_array_to_string` so that we make the consequences of
calling it in a thread-unsafe way less disastrous (i.e. let's avoid
corrupting GC internal metrics).

Strictly speaking, this is not a bug-fix because calling
`jl_array_to_string` concurrently from two threads is UB in any case.

To see how a race here may lead to negative `live_bytes`, consider this
MWE from @NHDaly:

- 1.10:
```Julia
julia> GC.gc(true); Base.gc_live_bytes()
1842370

julia> g_vecs = Any[
                  UInt8['a' for _ in 1:1000000000]
                  for _ in 1:10
                  ];

julia> GC.gc(true); Base.gc_live_bytes()
10001774906

julia> Threads.@threads for _ in 1:1000
                  for v in g_vecs
                      String(v)
                  end
              end

julia> GC.gc(true); Base.gc_live_bytes()
-1997600207
```

- This patch:
```Julia
julia> GC.gc(true); Base.gc_live_bytes()
1862440

julia> g_vecs = Any[
                  UInt8['a' for _ in 1:1000000000]
                  for _ in 1:10
                  ];

julia> GC.gc(true); Base.gc_live_bytes()
10001796440

julia> Threads.@threads for _ in 1:1000
                  for v in g_vecs
                      String(v)
                  end
              end

julia> GC.gc(true); Base.gc_live_bytes()
10002390952
```
This fixes #54422, the code here assumes that top level exprs are always
rooted, but I don't see that referenced anywhere else, or guaranteed, so
conservatively always root objects that show up in code.
@giordano
Copy link
Contributor

The test modified by the backport of #55365 is failing on this branch:

Error in testset core:
Test Failed at /cache/build/tester-amdci5-15/julialang/julia-release-1-dot-10/julia-f21154fd2e/share/julia/test/core.jl:7545
  Expression: length(methods(foo31696)) == 2
   Evaluated: 1 == 2

)

I thought these sort of problems had been addressed by d60f92c, but it
seems some were missed. Specifically, `t.a` and `t.b` from `t::Union`
could be `TypeVar`, and if they are passed to a subroutine or recursed
without being unwrapped or rewrapped, errors like #55882
could occur.

This commit resolves the issue by calling `unwraptv` in the `Union`
handling within `instanceof_tfunc`. I also found a similar issue inside
`nfields_tfunc`, so that has also been fixed, and test cases have been
added. While I haven't been able to make up a test case specifically for
the fix in `instanceof_tfunc`, I have confirmed that this commit
certainly fixes the issue reported in #55882.

- fixes #55882
@giordano giordano added the release Release management and versioning. label Oct 1, 2024
@IanButterworth
Copy link
Member

Pkg backports which should fix CI incoming JuliaLang/Pkg.jl#4036

DilumAluthgeBot and others added 15 commits October 4, 2024 20:03
For the `sigsetjmp` bypass; looks like glibc removed the
`__libc_siglongjmp` symbol in glibc 2.34, so change to using the
approach taking by our `dlopen` wrapper instead.

Adopts topolarity's fixes from #50170
Resolves #47698

Co-authored-by: Jameson Nash <vtjnash@gmail.com>
(cherry picked from commit 5cb0e51)
root cause:
if current dir has been deleted, then pwd() will throw an IOError:
pwd(): no such file or directory (ENOENT)

---------

Co-authored-by: Ian Butterworth <i.r.butterworth@gmail.com>
(cherry picked from commit 48ddd2d)
`%M` is the format specifier for the minutes, not the month (which
should be `%m`), and it was used twice.

Also, on macOS `Libc.strptime` internally calls `mktime` which depends
on the local timezone. We now temporarily set `TZ=UTC` to avoid
depending on the local timezone.

Fix #55827.

(cherry picked from commit d6fa66f)
Fixes #54203
Requires #55641

Based on
#55641 (comment)
cc. @JakeZw @ronisbr

---------

Co-authored-by: Jameson Nash <vtjnash@gmail.com>
(cherry picked from commit b0db75d)
Currently, these are inferred as a 2-Tuple of possible return types
depending on `jobz`, but since `jobz` is usually a constant, we may
propagate it aggressively and have the return types inferred concretely.

(cherry picked from commit 686804d)
…55342)

This fixes the error message if the matrix is uninitialized. This is
because a `Bidiagonal` with `uplo == 'L'` may still be `istriu` if the
subdiaognal is zero. We only care about the band index in the error
message, and not the values.

(cherry picked from commit f2f188d)
jishnub and others added 6 commits October 9, 2024 14:06
Since `Symmetric` and `Hermitian` symmetrize the diagonal elements of
the parent, we can't forward `tr` to the parent unless it is already
symmetric. This limits the existing `tr` methods to matrices of
`Number`s, which is the common use-case. `tr` for `Symmetric` block
matrices would now use the fallback implementation that explicitly
computes the `diag`.
This resolves the following discrepancy:
```julia
julia> S = Symmetric(fill([1 2; 3 4], 3, 3))
3×3 Symmetric{AbstractMatrix, Matrix{Matrix{Int64}}}:
 [1 2; 2 4]  [1 2; 3 4]  [1 2; 3 4]
 [1 3; 2 4]  [1 2; 2 4]  [1 2; 3 4]
 [1 3; 2 4]  [1 3; 2 4]  [1 2; 2 4]

julia> tr(S)
2×2 Matrix{Int64}:
 3   6
 9  12

julia> sum(diag(S))
2×2 Symmetric{Int64, Matrix{Int64}}:
 3   6
 6  12
```

(cherry picked from commit 9738bc7)
Stdlib: Downloads
URL: https://github.com/JuliaLang/Downloads.jl.git
Stdlib branch: master
Julia branch: master
Old commit: 1061ecc
New commit: 89d3c7d
Julia version: 1.12.0-DEV
Downloads version: 1.6.0(It's okay that it doesn't match)
Bump invoked by: @KristofferC
Powered by:
[BumpStdlibs.jl](https://github.com/JuliaLang/BumpStdlibs.jl)

Diff:
JuliaLang/Downloads.jl@1061ecc...89d3c7d

```
$ git log --oneline 1061ecc..89d3c7d
89d3c7d fix cancelling upload requests (#259)
df33406 gracefully cancel a request (#256)
```

Co-authored-by: Dilum Aluthge <dilum@aluthge.com>
(cherry picked from commit c3af4fc)
Since #49110, which is included in 1.10 and 1.11, spawning a task no
longer advances the parent task's RNG state, so this statement in the
docs was incorrect.

(cherry picked from commit c601b11)
I made a mistake with which threadpool was which.

(cherry picked from commit d5bbcc5)
The destination array was being indexed incorrectly if it had offset
indices. This led to the following on nightly:
```julia
julia> using OffsetArrays

julia> r = 5:100;

julia> a = OffsetVector(r, 2);

julia> sum(a, dims=1)
1-element OffsetArray(::Vector{Int64}, 3:3) with eltype Int64 with indices 3:3:
 0

julia> sum(a)
5040
```
The indexing was marked `@inbounds`, so this was not throwing an error.
This PR also follows #55329 and only marks the indexing operations as
`@inbounds`, omitting the function calls.

---------

Co-authored-by: Matt Bauman <mbauman@juliahub.com>
(cherry picked from commit 3d20a92)
These are often badly inferred, e.g. in:
```julia
julia> @report_opt 2//2
┌ Warning: skipping (::Base.var"#show_bound#661")(io::IO, b) @ Base show.jl:2777 to avoid parsing too much code
└ @ Revise ~/.julia/packages/Revise/bAgL0/src/packagedef.jl:1092
┌ Warning: skipping (::Base.var"#show_bound#661")(io::IO, b) @ Base show.jl:2777 to avoid parsing too much code
└ @ Revise ~/.julia/packages/Revise/bAgL0/src/packagedef.jl:1092
═════ 32 possible errors found ═════
┌ //(n::Int64, d::Int64) @ Base ./rational.jl:84
│┌ Rational(n::Int64, d::Int64) @ Base ./rational.jl:48
││┌ Rational{Int64}(num::Int64, den::Int64) @ Base ./rational.jl:32
│││┌ __throw_rational_argerror_zero(T::Type{Int64}) @ Base ./rational.jl:30
││││┌ string(::String, ::Type{Int64}, ::String, ::Type{Int64}, ::String) @ Base ./strings/io.jl:189
│││││┌ print_to_string(::String, ::Type{Int64}, ::String, ::Type{Int64}, ::String) @ Base ./strings/io.jl:148
││││││┌ print(io::IOBuffer, x::DataType) @ Base ./strings/io.jl:35
│││││││┌ show(io::IOBuffer, x::DataType) @ Base ./show.jl:970
││││││││┌ _show_type(io::IOBuffer, x::Type) @ Base ./show.jl:975
│││││││││┌ show_typealias(io::IOBuffer, x::Type) @ Base ./show.jl:810
││││││││││┌ make_typealias(x::Type) @ Base ./show.jl:620
│││││││││││┌ modulesof!(s::Set{Module}, x::Type) @ Base ./show.jl:595
││││││││││││ runtime dispatch detected: Base.modulesof!(s::Set{Module}, %20::Any)::Any
│││││││││││└────────────────────
│││││││││││┌ modulesof!(s::Set{Module}, x::Type) @ Base ./show.jl:596
││││││││││││ runtime dispatch detected: Base.modulesof!(s::Set{Module}, %34::Any)::Any
│││││││││││└────────────────────
│││││││││││┌ modulesof!(s::Set{Module}, x::TypeVar) @ Base ./show.jl:589
││││││││││││ runtime dispatch detected: Base.modulesof!(s::Set{Module}, %1::Any)::Set{Module}
│││││││││││└────────────────────
│││││││││┌ show_typealias(io::IOBuffer, x::Type) @ Base ./show.jl:813
││││││││││┌ show_typealias(io::IOBuffer, name::GlobalRef, x::Type, env::Core.SimpleVector, wheres::Vector{TypeVar}) @ Base ./show.jl:760
│││││││││││┌ show_typeparams(io::IOContext{IOBuffer}, env::Core.SimpleVector, orig::Core.SimpleVector, wheres::Vector{TypeVar}) @ Base ./show.jl:724
││││││││││││┌ show(io::IOContext{IOBuffer}, tv::TypeVar) @ Base ./show.jl:2788
│││││││││││││┌ (::Base.var"#show_bound#661")(io::IOContext{IOBuffer}, b::Any) @ Base ./show.jl:2780
││││││││││││││ runtime dispatch detected: show(io::IOContext{IOBuffer}, b::Any)::Any
│││││││││││││└────────────────────
│││││││││││┌ show_typeparams(io::IOContext{IOBuffer}, env::Core.SimpleVector, orig::Core.SimpleVector, wheres::Vector{TypeVar}) @ Base ./show.jl:719
││││││││││││ runtime dispatch detected: show(io::IOContext{IOBuffer}, %252::Any)::Any
│││││││││││└────────────────────
│││││││││││┌ show_typeparams(io::IOContext{IOBuffer}, env::Core.SimpleVector, orig::Core.SimpleVector, wheres::Vector{TypeVar}) @ Base ./show.jl:722
││││││││││││ runtime dispatch detected: show(io::IOContext{IOBuffer}, %313::Any)::Any
│││││││││││└────────────────────
│││││││││││┌ show_typeparams(io::IOContext{IOBuffer}, env::Core.SimpleVector, orig::Core.SimpleVector, wheres::Vector{TypeVar}) @ Base ./show.jl:727
││││││││││││ runtime dispatch detected: show(io::IOContext{IOBuffer}, %191::Any)::Any
│││││││││││└────────────────────
││││││││┌ _show_type(io::IOBuffer, x::Type) @ Base ./show.jl:978
│││││││││┌ show_datatype(io::IOBuffer, x::DataType) @ Base ./show.jl:1094
││││││││││┌ show_datatype(io::IOBuffer, x::DataType, wheres::Vector{TypeVar}) @ Base ./show.jl:1097
│││││││││││┌ maybe_kws_nt(x::DataType) @ Base ./show.jl:1085
││││││││││││ runtime dispatch detected: eltype(%76::DataType)::Any
│││││││││││└────────────────────
││││││││││┌ show_datatype(io::IOBuffer, x::DataType, wheres::Vector{TypeVar}) @ Base ./show.jl:1186
│││││││││││┌ show_typeparams(io::IOBuffer, env::Core.SimpleVector, orig::Core.SimpleVector, wheres::Vector{TypeVar}) @ Base ./show.jl:724
││││││││││││┌ show(io::IOBuffer, tv::TypeVar) @ Base ./show.jl:2788
│││││││││││││┌ (::Base.var"#show_bound#661")(io::IOBuffer, b::Any) @ Base ./show.jl:2780
││││││││││││││ runtime dispatch detected: show(io::IOBuffer, b::Any)::Any
│││││││││││││└────────────────────
│││││││││││┌ show_typeparams(io::IOBuffer, env::Core.SimpleVector, orig::Core.SimpleVector, wheres::Vector{TypeVar}) @ Base ./show.jl:719
││││││││││││ runtime dispatch detected: show(io::IOBuffer, %250::Any)::Any
│││││││││││└────────────────────
│││││││││││┌ show_typeparams(io::IOBuffer, env::Core.SimpleVector, orig::Core.SimpleVector, wheres::Vector{TypeVar}) @ Base ./show.jl:722
││││││││││││ runtime dispatch detected: show(io::IOBuffer, %310::Any)::Any
│││││││││││└────────────────────
│││││││││││┌ show_typeparams(io::IOBuffer, env::Core.SimpleVector, orig::Core.SimpleVector, wheres::Vector{TypeVar}) @ Base ./show.jl:727
││││││││││││ runtime dispatch detected: show(io::IOBuffer, %190::Any)::Any
│││││││││││└────────────────────
││││││││││┌ show_datatype(io::IOBuffer, x::DataType, wheres::Vector{TypeVar}) @ Base ./show.jl:1157
│││││││││││ runtime dispatch detected: show(io::IOBuffer, %224::Any)::Any
││││││││││└────────────────────
││││││││││┌ show_datatype(io::IOBuffer, x::DataType, wheres::Vector{TypeVar}) @ Base ./show.jl:1162
│││││││││││ runtime dispatch detected: show(io::IOBuffer, %54::Any)::Any
││││││││││└────────────────────
││││││││││┌ show_datatype(io::IOBuffer, x::DataType, wheres::Vector{TypeVar}) @ Base ./show.jl:1148
│││││││││││ runtime dispatch detected: show(io::IOBuffer, %57::Any)::Any
││││││││││└────────────────────
││││││││││┌ show_datatype(io::IOBuffer, x::DataType, wheres::Vector{TypeVar}) @ Base ./show.jl:1150
│││││││││││ runtime dispatch detected: show(io::IOBuffer, %54::Any)::Any
││││││││││└────────────────────
││││││││││┌ show_datatype(io::IOBuffer, x::DataType, wheres::Vector{TypeVar}) @ Base ./show.jl:1172
│││││││││││ runtime dispatch detected: Base.show_at_namedtuple(io::IOBuffer, %329::Tuple, %328::DataType)::Any
││││││││││└────────────────────
││││││││┌ _show_type(io::IOBuffer, x::Type) @ Base ./show.jl:981
│││││││││┌ show_unionaliases(io::IOBuffer, x::Union) @ Base ./show.jl:901
││││││││││┌ make_typealiases(x::Union) @ Base ./show.jl:822
│││││││││││┌ modulesof!(s::Set{Module}, x::Union) @ Base ./show.jl:595
││││││││││││ runtime dispatch detected: Base.modulesof!(s::Set{Module}, %3::Any)::Any
│││││││││││└────────────────────
│││││││││││┌ modulesof!(s::Set{Module}, x::Union) @ Base ./show.jl:596
││││││││││││ runtime dispatch detected: Base.modulesof!(s::Set{Module}, %17::Any)::Any
│││││││││││└────────────────────
│││││││││┌ show_unionaliases(io::IOBuffer, x::Union) @ Base ./show.jl:914
││││││││││ runtime dispatch detected: show(io::IOBuffer, %89::Any)::Any
│││││││││└────────────────────
│││││││││┌ show_unionaliases(io::IOBuffer, x::Union) @ Base ./show.jl:920
││││││││││ runtime dispatch detected: Base.show_typealias(io::IOBuffer, %206::Any, x::Union, %204::Core.SimpleVector, %205::Vector{TypeVar})::Any
│││││││││└────────────────────
│││││││││┌ show_unionaliases(io::IOBuffer, x::Union) @ Base ./show.jl:928
││││││││││ runtime dispatch detected: Base.show_typealias(io::IOBuffer, %269::Any, x::Union, %267::Core.SimpleVector, %268::Vector{TypeVar})::Any
│││││││││└────────────────────
││││││││┌ _show_type(io::IOBuffer, x::Type) @ Base ./show.jl:985
│││││││││┌ show_delim_array(io::IOBuffer, itr::Vector{Any}, op::Char, delim::Char, cl::Char, delim_one::Bool) @ Base ./show.jl:1392
││││││││││┌ show_delim_array(io::IOBuffer, itr::Vector{Any}, op::Char, delim::Char, cl::Char, delim_one::Bool, i1::Int64, l::Int64) @ Base ./show.jl:1403
│││││││││││ runtime dispatch detected: show(%3::IOContext{IOBuffer}, %52::Any)::Any
││││││││││└────────────────────
││││││││┌ _show_type(io::IOBuffer, x::Type) @ Base ./show.jl:1012
│││││││││┌ show_datatype(io::IOContext{IOBuffer}, x::DataType, wheres::Vector{TypeVar}) @ Base ./show.jl:1185
││││││││││┌ show_type_name(io::IOContext{IOBuffer}, tn::Core.TypeName) @ Base ./show.jl:1059
│││││││││││ runtime dispatch detected: Base.isvisible(%29::Symbol, %86::Module, %80::Any)::Bool
││││││││││└────────────────────
│││││││││┌ show_datatype(io::IOContext{IOBuffer}, x::DataType, wheres::Vector{TypeVar}) @ Base ./show.jl:1157
││││││││││ runtime dispatch detected: show(io::IOContext{IOBuffer}, %227::Any)::Any
│││││││││└────────────────────
│││││││││┌ show_datatype(io::IOContext{IOBuffer}, x::DataType, wheres::Vector{TypeVar}) @ Base ./show.jl:1162
││││││││││ runtime dispatch detected: show(io::IOContext{IOBuffer}, %55::Any)::Any
│││││││││└────────────────────
│││││││││┌ show_datatype(io::IOContext{IOBuffer}, x::DataType, wheres::Vector{TypeVar}) @ Base ./show.jl:1148
││││││││││ runtime dispatch detected: show(io::IOContext{IOBuffer}, %58::Any)::Any
│││││││││└────────────────────
│││││││││┌ show_datatype(io::IOContext{IOBuffer}, x::DataType, wheres::Vector{TypeVar}) @ Base ./show.jl:1150
││││││││││ runtime dispatch detected: show(io::IOContext{IOBuffer}, %55::Any)::Any
│││││││││└────────────────────
│││││││││┌ show_datatype(io::IOContext{IOBuffer}, x::DataType, wheres::Vector{TypeVar}) @ Base ./show.jl:1172
││││││││││ runtime dispatch detected: Base.show_at_namedtuple(io::IOContext{IOBuffer}, %338::Tuple, %337::DataType)::Any
│││││││││└────────────────────
│││││││││┌ show_datatype(io::IOContext{IOBuffer}, x::DataType, wheres::Vector{TypeVar}) @ Base ./show.jl:1180
││││││││││ runtime dispatch detected: Base.show_at_namedtuple(io::IOContext{IOBuffer}, %387::Tuple, %391::DataType)::Any
│││││││││└────────────────────
││││││││┌ _show_type(io::IOBuffer, x::Type) @ Base ./show.jl:1014
│││││││││ runtime dispatch detected: show(%98::IOContext{IOBuffer}, %99::Any)::Any
││││││││└────────────────────
│││││││┌ show(io::IOBuffer, x::DataType) @ Base ./show.jl:970
││││││││ runtime dispatch detected: Base._show_type(io::IOBuffer, %1::Any)::Nothing
│││││││└────────────────────
```

I haven't looked through all instances thoroughly, just a quick `grep`.
However, this PR should address several common cases.

(cherry picked from commit 2230f79)
@KristofferC
Copy link
Member Author

@nanosoldier runtests()

The exact textual representation of the output of these doctests depend
on the specific kernel used by the BLAS backend, and can vary between
versions of OpenBLAS (as it did in #41973), or between different CPUs,
which makes these doctests unreliable.

Fix #55998.

(cherry picked from commit c2a2e38)
@nanosoldier
Copy link
Collaborator

The package evaluation job you requested has completed - possible new issues were detected.
The full report is available.

@KristofferC
Copy link
Member Author

@nanosoldier runtests(["JuliaInterpreter", "KissMCMC", "ParallelStencil", "BenchmarkProfiles", "SmoQyHankelCorrCleaner", "Boscia", "ReducedComplexityModeling", "GMT", "FSimBase", "RealTimeAudioDiffEq", "SurfaceReactions", "JointSurvivalModels", "ControlBarrierFunctions", "GeophysicalModelGenerator", "ReactionSensitivity", "HarmonicBalance"])

@nanosoldier
Copy link
Collaborator

The package evaluation job you requested has completed - possible new issues were detected.
The full report is available.

@KristofferC
Copy link
Member Author

@nanosoldier runbenchmarks(ALL, vs = ":release-1.10")

@nanosoldier
Copy link
Collaborator

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here.

@KristofferC KristofferC merged commit 262daad into release-1.10 Oct 22, 2024
6 of 7 checks passed
@KristofferC KristofferC deleted the backports-release-1.10 branch October 22, 2024 08:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
release Release management and versioning.
Projects
None yet
Development

Successfully merging this pull request may close these issues.