Update Julia to latest master #62
Merged
Conversation
This file contains 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
Updating the jl_rng_split comment after a bit more consideration of the comparison with SplitMix.
Co-authored-by: Lilith Orion Hafner <lilithhafner@gmail.com>
This should be a more reliable look-up, since this will directly report the path of the currently-executing libjulia.dll. Without this PR, `LoadLibraryW` depends on the system library search order. When the top-level executable is adjacent to `libjulia.dll` (as it is for our binary distribution usually), then that search should be OK. However, applications that use Julia as a library can end up searching the system PATH before making it to the correct `lib/julia` directory, causing us to load the wrong version of `libjulia.dll`. In many cases, that extra load is benign due to the stricter separation of libraries/symbols on Windows - However, in general it's likely to be the cause of subtle bugs.
…uliaLang#54605) Fix JuliaLang#41613. Co-authored-by: FX Coudert <fxcoudert@gmail.com>
…Lang#54616) there were random cases of two and even three spaces between sentences Co-authored-by: KristofferC <kristoffer.carlsson@juliacomputing.com>
I noticed a runtime dispatch occurring in a broadcast, because the array element is specified but not the dimensions, even though the dimensions are known. With this PR, that runtime dispatch is eliminated by explicitly passing the dimensions into the type.
--------- Co-authored-by: Sukera <11753998+Seelengrab@users.noreply.github.com> Co-authored-by: Jameson Nash <vtjnash@gmail.com> Co-authored-by: Kristoffer Carlsson <kcarlsson89@gmail.com>
…Lang#54634) This avoids a: `error: non-private labels cannot appear between .cfi_startproc / .cfi_endproc pairs` error. That error was introduced in https://reviews.llvm.org/D155245#4657075 see also llvm/llvm-project#72802
This commit makes it possible for `names` to return `using`-ed names as
well:
```julia
julia> using Base: @assume_effects
julia> Symbol("@assume_effects") in names(@__MODULE__; usings=true)
true
```
Currently, to find all names available in a module `A`, the following
steps are needed:
1. Use `names(A; all=true, imported=true)` to get the names defined by
`A` and the names explicitly `import`ed by `A`.
2. Use `jl_module_usings(A)` to get the list of modules `A` has
`using`-ed and then use `names()` to get the names `export`ed by those
modules.
This method is implemented in e.g. REPL completions, but it has a
problem: it could not get the names explicitly `using`-ed by `using B:
...` (JuliaLang#36529, JuliaLang#40356, JuliaDebug/Infiltrator.jl#106, etc.).
This commit adds a new keyword argument `usings::Bool=false` to
`names(A; ...)`, which, when `usings=true` is specified, returns all
names introduced by `using` in `A`.
In other words, `usings=true` not only returns explicitly `using`-ed
names but also incorporates step 2 above into the implementation of
`names`.
By using this new option, we can now use
`names(A; all=true, imported=true, usings=true)` to know all names
available in `A`, without implementing the two-fold steps on application
side.
As example application, this new feature will be used to simplify and
enhance the implementation of REPL completions.
- fixes JuliaLang#36529
Co-authored-by: Nathan Daly <NHDaly@gmail.com>
Co-authored-by: Sebastian Pfitzner <pfitzseb@gmail.com>
…uliaLang#54610) The new feature `usings=true` added to `names` enhances REPL completions by allowing explicitly `using`-ed names to be found. ```julia julia> using Base: @assume_effects julia> @assu| # completes to `@assume_effects` ``` As a result, the implementation of REPL completions has been simplified. Additionally, it allows completion for names that are implicitly or explicitly `using`-ed in code specifying a module explicitly, such as: ```julia julia> module A end julia> A.signi| # completes to `A.significand` ``` - fixes JuliaLang#29275 - fixes JuliaLang#40356 - fixes JuliaLang#49109 - fixes JuliaLang#53524
…ang#54635) We may use aggressive constprop in `trevc!` to eliminate branches, which makes the return type of `eigvec(::UpperTriangular)` concretely inferred. ```julia julia> @inferred eigvecs(UpperTriangular([1 0; 0 1])) 2×2 Matrix{Float32}: 1.0 -0.0 0.0 1.0 ```
This may introduce a correctness issue in the work-stealing termination loop if we're using interactive threads and GC threads simultaneously. Indeed, if we forget to add `nthreadsi` to `nthreads`, then we're checking in the mark-loop termination protocol a range `[gc_first_tid, gc_first_tid + jl_n_markthreads)` of threads which is "shifted to the left" compared to what it should be. This implies that we will not be checking whether the GC threads with higher TID actually have terminated the mark-loop.
It's part of the strided arrays API https://docs.julialang.org/en/v1/manual/interfaces/#man-interface-strided-arrays
…g#51631) The default `pairs` will iterate keys and values separately. For strings, this represents double work, since both these iterations will need to determine valid string indices. The introduced StringPairs type will, whenever possible, only compute valid indices once. Currently, this is only optimised for `String` and `SubString{String}`, and not for `AbstractString`, nor is it optimised when reversed. Simple benchmark: ```julia using BenchmarkTools a = lpad("March", 20) @Btime lstrip($a) ``` * Master: 71.6 ns * This PR: 23.9 ns Closes JuliaLang#51624 --------- Co-authored-by: Jameson Nash <vtjnash@gmail.com> Co-authored-by: Dilum Aluthge <dilum@aluthge.com>
This commit changes the signature of a bunch of methods that operate on
byte buffers, and which previously didn't take `Memory`. For example, a
method which previously took
```julia
Union{
Array{UInt8},
CodeUnits{UInt8, String},
FastContiguousSubArray{UInt8,N,<:Array{UInt8}} where N,
}
```
Now also takes `Memory{UInt8}`, and the `Memory`-backed
`FastContiguousSubArray`.
## Notes for reviewers
1. I don't think this is a particularly nice design - these large unions
are a sign we miss an abstraction. In particular, whether something is a
contiguous, memory backed Array (read or read/write). I think we should
have a trait for this, which requires an implementation of e.g.
`pointer` and `sizeof`. However, that's a larger PR for another time.
3. The functions `readbytes_some!` and `readbytes_all!` may resize its
arguments. This will not work for `Memory`. It already didn't work for
`SubArray`. Maybe we should have a different method for the arrays that
can't be resized, which doesn't attempt to.
Similar to JuliaLang#54631, this would help reduce dynamic dispatches involved in concatenating a `String` and a `LazyString`. These show up in ```julia julia> @report_opt Tridiagonal(rand(1), rand(2), rand(1)) \ rand(2) [ Info: tracking Base ┌ Warning: skipping var"#sprint#594"(context, sizehint::Integer, ::typeof(sprint), f::Function, args...) @ Base strings/io.jl:107 to avoid parsing too much code └ @ Revise ~/.julia/packages/Revise/bAgL0/src/packagedef.jl:1092 ┌ Warning: skipping (::Base.var"JuliaLang#120#121")(io) @ Base strings/lazy.jl:84 to avoid parsing too much code └ @ Revise ~/.julia/packages/Revise/bAgL0/src/packagedef.jl:1092 ═════ 1 possible error found ═════ ┌ \(A::Tridiagonal{Float64, Vector{Float64}}, B::Vector{Float64}) @ LinearAlgebra /cache/build/builder-amdci4-5/julialang/julia-release-1-dot-11/usr/share/julia/stdlib/v1.11/LinearAlgebra/src/generic.jl:1132 │┌ lu(::Tridiagonal{Float64, Vector{Float64}}) @ LinearAlgebra /cache/build/builder-amdci4-5/julialang/julia-release-1-dot-11/usr/share/julia/stdlib/v1.11/LinearAlgebra/src/lu.jl:341 ││┌ lu(::Tridiagonal{Float64, Vector{Float64}}; kwargs::@kwargs{}) @ LinearAlgebra /cache/build/builder-amdci4-5/julialang/julia-release-1-dot-11/usr/share/julia/stdlib/v1.11/LinearAlgebra/src/lu.jl:341 │││┌ _lucopy(A::Tridiagonal{Float64, Vector{Float64}}, T::Type{Float64}) @ LinearAlgebra /cache/build/builder-amdci4-5/julialang/julia-release-1-dot-11/usr/share/julia/stdlib/v1.11/LinearAlgebra/src/lu.jl:351 ││││┌ copymutable_oftype(A::Tridiagonal{Float64, Vector{Float64}}, ::Type{Float64}) @ LinearAlgebra /cache/build/builder-amdci4-5/julialang/julia-release-1-dot-11/usr/share/julia/stdlib/v1.11/LinearAlgebra/src/LinearAlgebra.jl:463 │││││┌ similar(M::Tridiagonal{Float64, Vector{Float64}}, ::Type{Float64}) @ LinearAlgebra /cache/build/builder-amdci4-5/julialang/julia-release-1-dot-11/usr/share/julia/stdlib/v1.11/LinearAlgebra/src/tridiag.jl:603 ││││││┌ Tridiagonal(dl::Vector{Float64}, d::Vector{Float64}, du::Vector{Float64}) @ LinearAlgebra /cache/build/builder-amdci4-5/julialang/julia-release-1-dot-11/usr/share/julia/stdlib/v1.11/LinearAlgebra/src/tridiag.jl:520 │││││││┌ Tridiagonal{Float64, Vector{Float64}}(dl::Vector{Float64}, d::Vector{Float64}, du::Vector{Float64}) @ LinearAlgebra /cache/build/builder-amdci4-5/julialang/julia-release-1-dot-11/usr/share/julia/stdlib/v1.11/LinearAlgebra/src/tridiag.jl:477 ││││││││┌ string(::String, ::String, ::LazyString) @ Base ./strings/io.jl:189 │││││││││┌ print_to_string(::String, ::String, ::LazyString) @ Base ./strings/io.jl:148 ││││││││││┌ print(io::IOBuffer, s::LazyString) @ Base ./strings/io.jl:195 │││││││││││┌ iterate(s::LazyString) @ Base ./strings/lazy.jl:94 ││││││││││││┌ String(l::LazyString) @ Base ./strings/lazy.jl:83 │││││││││││││┌ sprint(::Base.var"JuliaLang#120#121"{LazyString}) @ Base ./strings/io.jl:107 ││││││││││││││┌ sprint(::Base.var"JuliaLang#120#121"{LazyString}; context::Nothing, sizehint::Int64) @ Base ./strings/io.jl:114 │││││││││││││││┌ (::Base.var"JuliaLang#120#121"{LazyString})(io::IOBuffer) @ Base ./strings/lazy.jl:85 ││││││││││││││││ runtime dispatch detected: print(io::IOBuffer, %16::Any)::Any │││││││││││││││└──────────────────── ``` Co-authored-by: Shuhei Kadowaki <40514306+aviatesk@users.noreply.github.com> Co-authored-by: Dilum Aluthge <dilum@aluthge.com>
…xtension (JuliaLang#54658) in stacked environments with name collisions of extensions, this could compute the path for the wrong extension Fixes JuliaLang/Pkg.jl#3906
…#54649) On nightly, `copyto!(A::T, B::T) where {T<:UpperTriangular}` checks for the types to be identical. This is overly restrictive, as we only need to check that they are both `UpperTriangular`. This PR relaxes this, which provides a significant performance boost for mismatched types. ```julia julia> using LinearAlgebra julia> A = UpperTriangular(rand(200,200)); B = UpperTriangular(view(rand(200,200),:,:)); julia> @Btime copyto!($A, $B); 44.878 μs (0 allocations: 0 bytes) # nightly v"1.12.0-DEV.641" 5.658 μs (0 allocations: 0 bytes) # this PR ``` This PR also changes the behavior when the source and the destination don't have the same size, in which case, `copyto!` should carry out a linear copy and not a Cartesian one, as per its docstring. The previous behavior may be obtained by calling ```julia copyto!(A, CartesianIndices(B), B, CartesianIndices(B)) ``` This change would mean that certain operations that used to work would error now, e.g.: ```julia julia> A = UpperTriangular(zeros(3,3)); B = UpperTriangular(rand(2,2)); julia> copyto!(A, B) ERROR: ArgumentError: cannot set index in the upper triangular part (3, 1) of an UpperTriangular matrix to a nonzero value (0.6898709830945821) ``` whereas this used to carry out a Cartesian copy previously. --------- Co-authored-by: Dilum Aluthge <dilum@aluthge.com>
Avoids a race condition where a signal (e.g. StackOverflowError) happens while trying to initialize the rest of the frame, resulting in trying to longjmp to garbage.
Since this is not modeled by the exception logic, and it can interrupt arbitrary program state or corrupt locks (leading to hangs and other issues), as well as just frequently segfaulting afterwards, give a printed message as soon as we notice things are going badly before attempting to recover.
…#54666) Stdlib: Pkg URL: https://github.com/JuliaLang/Pkg.jl.git Stdlib branch: master Julia branch: master Old commit: ed7a8dca8 New commit: 4e43058c2 Julia version: 1.12.0-DEV Pkg version: 1.12.0 Bump invoked by: @IanButterworth Powered by: [BumpStdlibs.jl](https://github.com/JuliaLang/BumpStdlibs.jl) Diff: JuliaLang/Pkg.jl@ed7a8dc...4e43058 ``` $ git log --oneline ed7a8dca8..4e43058c2 4e43058c2 Merge pull request JuliaLang#3887 from carlobaldassi/validate_versions bc7c3207d abort querying more pacakge for hint auto complete (JuliaLang#3913) a4016aed2 precompile repl switch (JuliaLang#3910) a48c9c645 Fixed glitch in the manual (JuliaLang#3912) d875aa213 Add timeout and new tests for resolver aeb55f7f0 run artifact selection code with minimal compilation (JuliaLang#3899) 0180a0105 avoid doing some checks if the package will not be showed in status output (JuliaLang#3897) c6c7ed502 improve precompilation for `st` in the Pkg REPL (JuliaLang#3893) bffd0633c Add version validation during Graph simplification c2ad07003 Fix padding in resolve's log journal printing 3eb86d29f Revert JuliaLang#2267, with better log message acdbb727e Small extra check in Graph's check_consistency 1d446c224 Fix small bug in Graph constructor 3efc3cbff Fix show method for VersionSpecs ``` Co-authored-by: Dilum Aluthge <dilum@aluthge.com>
…uliaLang#54594) Because Pkg is now a pkgimage it can load slowly on slower machines, which is a bit frustrating in the first repl switch. This makes the repl immediately switch to a dummy prompt that looks like Pkg mode to allow the user to keep typing while Pkg loads. During which the keymap is disabled. It works best if julia has >1 thread, otherwise typing stalls during Pkg load. If Pkg takes longer to load than the user to type the command and press return, then the UX isn't great as it won't do anything. https://github.com/JuliaLang/julia/assets/1694067/1bf17323-441a-4db2-8a3b-4d571eac622f
More followup to fix issues with require. There was an accidental variable reuse (build_id) that caused it to be unable to load cache files in many cases. There was also missing check for a dependency already being loaded, resulting in trying to load it twice. Finally, the start_loading code may drop the require_lock, but the surrounding code was not prepared for that. Now integrate the necessary checks into start_loading, instead of needing to duplicate them before and afterwards. Fixes JuliaLang#53983 Fixes JuliaLang#54940 Closes JuliaLang#55064
…5037) I hit this error message and it felt someone was very angry at me
This patch adds magenta coloring for `!!! todo` admonitions in addition to the existing styling of `danger`, `warning`, `info`, `note`, `tip`, and `compat` admonitions. This is useful if you want to leave some more colorful todo notes in docstrings, for example. Accompanying PR for Documenter to render these in HTML and PDF docs: JuliaDocs/Documenter.jl#2526.
This code is quite contrived. Let's simplify it a bit.
This is useful for hot loops that perform an `invoke_latest`-like operation, such as the upcoming `TypedCallable`
The functions `toms`, `tons`, and `days` uses `sum` over a vector of
`Period`s to obtain the conversion of a `CompoundPeriod`. However, the
compiler cannot infer the return type because those functions can return
either `Int` or `Float` depending on the type of the `Period`. This PR
forces the result of those functions to be `Float64`, fixing the type
stability.
Before this PR we had:
```julia
julia> using Dates
julia> p = Dates.Second(1) + Dates.Minute(1) + Dates.Year(1)
1 year, 1 minute, 1 second
julia> @code_warntype Dates.tons(p)
MethodInstance for Dates.tons(::Dates.CompoundPeriod)
from tons(c::Dates.CompoundPeriod) @ Dates ~/.julia/juliaup/julia-nightly/share/julia/stdlib/v1.12/Dates/src/periods.jl:458
Arguments
#self#::Core.Const(Dates.tons)
c::Dates.CompoundPeriod
Body::Any
1 ─ %1 = Dates.isempty::Core.Const(isempty)
│ %2 = Base.getproperty(c, :periods)::Vector{Period}
│ %3 = (%1)(%2)::Bool
└── goto mmtk#3 if not %3
2 ─ return 0.0
3 ─ %6 = Dates.Float64::Core.Const(Float64)
│ %7 = Dates.sum::Core.Const(sum)
│ %8 = Dates.tons::Core.Const(Dates.tons)
│ %9 = Base.getproperty(c, :periods)::Vector{Period}
│ %10 = (%7)(%8, %9)::Any
│ %11 = (%6)(%10)::Any
└── return %11
julia> @code_warntype Dates.toms(p)
MethodInstance for Dates.toms(::Dates.CompoundPeriod)
from toms(c::Dates.CompoundPeriod) @ Dates ~/.julia/juliaup/julia-nightly/share/julia/stdlib/v1.12/Dates/src/periods.jl:454
Arguments
#self#::Core.Const(Dates.toms)
c::Dates.CompoundPeriod
Body::Any
1 ─ %1 = Dates.isempty::Core.Const(isempty)
│ %2 = Base.getproperty(c, :periods)::Vector{Period}
│ %3 = (%1)(%2)::Bool
└── goto mmtk#3 if not %3
2 ─ return 0.0
3 ─ %6 = Dates.Float64::Core.Const(Float64)
│ %7 = Dates.sum::Core.Const(sum)
│ %8 = Dates.toms::Core.Const(Dates.toms)
│ %9 = Base.getproperty(c, :periods)::Vector{Period}
│ %10 = (%7)(%8, %9)::Any
│ %11 = (%6)(%10)::Any
└── return %11
julia> @code_warntype Dates.days(p)
MethodInstance for Dates.days(::Dates.CompoundPeriod)
from days(c::Dates.CompoundPeriod) @ Dates ~/.julia/juliaup/julia-nightly/share/julia/stdlib/v1.12/Dates/src/periods.jl:468
Arguments
#self#::Core.Const(Dates.days)
c::Dates.CompoundPeriod
Body::Any
1 ─ %1 = Dates.isempty::Core.Const(isempty)
│ %2 = Base.getproperty(c, :periods)::Vector{Period}
│ %3 = (%1)(%2)::Bool
└── goto mmtk#3 if not %3
2 ─ return 0.0
3 ─ %6 = Dates.Float64::Core.Const(Float64)
│ %7 = Dates.sum::Core.Const(sum)
│ %8 = Dates.days::Core.Const(Dates.days)
│ %9 = Base.getproperty(c, :periods)::Vector{Period}
│ %10 = (%7)(%8, %9)::Any
│ %11 = (%6)(%10)::Any
└── return %11
```
After this PR we have:
```julia
julia> using Dates
julia> p = Dates.Second(1) + Dates.Minute(1) + Dates.Year(1)
1 year, 1 minute, 1 second
julia> @code_warntype Dates.tons(p)
MethodInstance for Dates.tons(::Dates.CompoundPeriod)
from tons(c::Dates.CompoundPeriod) @ Dates ~/.julia/juliaup/julia-nightly/share/julia/stdlib/v1.12/Dates/src/periods.jl:458
Arguments
#self#::Core.Const(Dates.tons)
c::Dates.CompoundPeriod
Body::Float64
1 ─ %1 = Dates.isempty::Core.Const(isempty)
│ %2 = Base.getproperty(c, :periods)::Vector{Period}
│ %3 = (%1)(%2)::Bool
└── goto mmtk#3 if not %3
2 ─ return 0.0
3 ─ %6 = Dates.Float64::Core.Const(Float64)
│ %7 = Dates.sum::Core.Const(sum)
│ %8 = Dates.tons::Core.Const(Dates.tons)
│ %9 = Base.getproperty(c, :periods)::Vector{Period}
│ %10 = (%7)(%8, %9)::Any
│ %11 = (%6)(%10)::Any
│ %12 = Dates.Float64::Core.Const(Float64)
│ %13 = Core.typeassert(%11, %12)::Float64
└── return %13
julia> @code_warntype Dates.toms(p)
MethodInstance for Dates.toms(::Dates.CompoundPeriod)
from toms(c::Dates.CompoundPeriod) @ Dates ~/.julia/juliaup/julia-nightly/share/julia/stdlib/v1.12/Dates/src/periods.jl:454
Arguments
#self#::Core.Const(Dates.toms)
c::Dates.CompoundPeriod
Body::Float64
1 ─ %1 = Dates.isempty::Core.Const(isempty)
│ %2 = Base.getproperty(c, :periods)::Vector{Period}
│ %3 = (%1)(%2)::Bool
└── goto mmtk#3 if not %3
2 ─ return 0.0
3 ─ %6 = Dates.Float64::Core.Const(Float64)
│ %7 = Dates.sum::Core.Const(sum)
│ %8 = Dates.toms::Core.Const(Dates.toms)
│ %9 = Base.getproperty(c, :periods)::Vector{Period}
│ %10 = (%7)(%8, %9)::Any
│ %11 = (%6)(%10)::Any
│ %12 = Dates.Float64::Core.Const(Float64)
│ %13 = Core.typeassert(%11, %12)::Float64
└── return %13
julia> @code_warntype Dates.days(p)
MethodInstance for Dates.days(::Dates.CompoundPeriod)
from days(c::Dates.CompoundPeriod) @ Dates ~/.julia/juliaup/julia-nightly/share/julia/stdlib/v1.12/Dates/src/periods.jl:468
Arguments
#self#::Core.Const(Dates.days)
c::Dates.CompoundPeriod
Body::Float64
1 ─ %1 = Dates.isempty::Core.Const(isempty)
│ %2 = Base.getproperty(c, :periods)::Vector{Period}
│ %3 = (%1)(%2)::Bool
└── goto mmtk#3 if not %3
2 ─ return 0.0
3 ─ %6 = Dates.Float64::Core.Const(Float64)
│ %7 = Dates.sum::Core.Const(sum)
│ %8 = Dates.days::Core.Const(Dates.days)
│ %9 = Base.getproperty(c, :periods)::Vector{Period}
│ %10 = (%7)(%8, %9)::Any
│ %11 = (%6)(%10)::Any
│ %12 = Dates.Float64::Core.Const(Float64)
│ %13 = Core.typeassert(%11, %12)::Float64
└── return %13
```
JuliaLang#55106) This adds a new helper `jl_read_codeinst_invoke` that should help manage reading the state out of a CodeInstance correctly everywhere. Then replaces all of the places where we have optimizations in codegen where we check for this (to build a name in the JIT for it) with that call. And finally moves the `jl_codegen_lock` into `jl_ExecutionEngine->jitlock` so that it is now more clear that this is only protecting concurrent access to the JIT state it manages (which includes the invoke field of all CodeInstance objects). In a subsequent followup, that `jitlock` and `codeinst_in_flight` will be replaced with something akin to the new engine (for CodeInfo inference) which helps partition that JIT lock mechanism (for CodeInstance / JIT insertion) to correspond just to a single CodeInstance, and not globally to all of them.
udesou
added a commit
to mmtk/mmtk-julia
that referenced
this pull request
Aug 19, 2024
This commit updates our fork to a [latest version](udesou/julia@b88f64f) from the Julia repo. Needs to be merged with mmtk/julia#62. --------- Co-authored-by: Luis Eduardo de Souza Amorim <eduardo@groundhog.moma>
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
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.
This commit updates our fork to a latest version from the Julia repo.