-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
[release-1.10] Backports for Julia 1.10.0-x #50971
Merged
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
If two processes attempt to recursively delete a directory at the same time, then we can end up in a state where the initial `isdir` is `true`, but by the time it actually deletes the directory it is already gone. e.g. - https://buildkite.com/clima/climacore-ci/builds/2460#0189d254-76a9-474b-ad25-e5b16440d629/140-142 which is triggered by https://github.com/cjdoris/PackageExtensionCompat.jl/blob/636eb5a14ddf9134d004c93f598515903af26443/src/PackageExtensionCompat.jl#L59 - https://buildkite.com/clima/climacore-ci/builds/2457#0189c7fe-8872-40c5-9106-da2e621ff55a/139-150 which is triggered by https://github.com/JuliaGPU/GPUCompiler.jl/blob/06e670657d7ceebc1845d7c9534a8352c33490de/src/rtlib.jl#L152 I've been conservative and only applied this when `force=true`, but perhaps it should apply generally? (cherry picked from commit cbd3c89)
Without this, the task created by a `Channel` will run in the threadpool of the creating task; in the REPL, this could be the interactive threadpool. On 1.8, without threadpools: ```julia % julia +1.8 -t 8 _ _ _ _(_)_ | Documentation: https://docs.julialang.org (_) | (_) (_) | _ _ _| |_ __ _ | Type "?" for help, "]?" for Pkg help. | | | | | | |/ _` | | | | |_| | | | (_| | | Version 1.8.5 (2023-01-08) _/ |\__'_|_|_|\__'_| | Official https://julialang.org/ release |__/ | julia> for _ in 1:10 Channel{Int}(1; spawn=true) do _ Core.print("threadid=$(Threads.threadid())\n") end end threadid=2 threadid=5 threadid=2 threadid=2 threadid=1 threadid=6 threadid=7 threadid=8 threadid=3 threadid=4 ``` On 1.9, with no interactive threads: ```julia % julia +1.9 -t 8 _ _ _ _(_)_ | Documentation: https://docs.julialang.org (_) | (_) (_) | _ _ _| |_ __ _ | Type "?" for help, "]?" for Pkg help. | | | | | | |/ _` | | | | |_| | | | (_| | | Version 1.9.2 (2023-07-05) _/ |\__'_|_|_|\__'_| | Official https://julialang.org/ release |__/ | julia> for _ in 1:10 Channel{Int}(1; spawn=true) do _ Core.print("threadid=$(Threads.threadid())\n") end end threadid=4 threadid=4 threadid=4 threadid=2 threadid=3 threadid=1 threadid=7 threadid=5 threadid=8 threadid=6 ``` On 1.9, with an interactive thread: ```julia % julia +1.9 -t 7,1 _ _ _ _(_)_ | Documentation: https://docs.julialang.org (_) | (_) (_) | _ _ _| |_ __ _ | Type "?" for help, "]?" for Pkg help. | | | | | | |/ _` | | | | |_| | | | (_| | | Version 1.9.2 (2023-07-05) _/ |\__'_|_|_|\__'_| | Official https://julialang.org/ release |__/ | julia> for _ in 1:10 Channel{Int}(1; spawn=true) do _ Core.print("threadid=$(Threads.threadid())\n") end end threadid=1 threadid=1 threadid=1 threadid=1 threadid=1 threadid=1 threadid=1 threadid=1 threadid=1 threadid=1 ``` With this PR, the `:default` threadpool is used instead. ```julia % julia +master -t7,1 _ _ _ _(_)_ | Documentation: https://docs.julialang.org (_) | (_) (_) | _ _ _| |_ __ _ | Type "?" for help, "]?" for Pkg help. | | | | | | |/ _` | | | | |_| | | | (_| | | Version 1.11.0-DEV.244 (2023-08-09) _/ |\__'_|_|_|\__'_| | Commit d99f249* (0 days old master) |__/ | julia> for _ in 1:10 Channel{Int}(1; spawn=true) do _ Core.print("threadid=$(Threads.threadid())\n") end end threadid=7 threadid=6 threadid=7 threadid=7 threadid=6 threadid=3 threadid=5 threadid=2 threadid=4 threadid=8 ``` And, the behavior can be overridden. ```julia % julia +master -t7,1 _ _ _ _(_)_ | Documentation: https://docs.julialang.org (_) | (_) (_) | _ _ _| |_ __ _ | Type "?" for help, "]?" for Pkg help. | | | | | | |/ _` | | | | |_| | | | (_| | | Version 1.11.0-DEV.244 (2023-08-09) _/ |\__'_|_|_|\__'_| | Commit d99f249* (0 days old master) |__/ | julia> for _ in 1:10 Channel{Int}(1; spawn=true, threadpool=:interactive) do _ Core.print("threadid=$(Threads.threadid())\n") end end threadid=1 threadid=1 threadid=1 threadid=1 threadid=1 threadid=1 threadid=1 threadid=1 threadid=1 threadid=1 ``` --------- Co-authored-by: Nathan Daly <NHDaly@gmail.com> (cherry picked from commit 555cd23)
Ensure that `isapprox` gives correct results when comparing an integer with another integer or with a float. For comparison between integers, the fix only works when keeping default values for `rtol` and `norm`, and with `atol < 1`. It is not possible to handle the (atypical) case where `norm !== abs`, but that's OK since the user is responsible for providing a safe function. It would be possible to handle the case where `rtol > 0` or `atol >= 1`, but with complex code which would check for overflow and handle all possible corner cases; it would work only for types defined in Base and would not be extensible by packages. So I'm not sure that's worth it. At least with PR fixes the most common case. Fixes #50380. (cherry picked from commit 5f03a18)
Update the docs for `Task` to mention the fact that they default to sticky. Co-authored-by: Gabriel Baraldi <baraldigabriel@gmail.com> (cherry picked from commit 5466d3d)
* document the `order` keyword in `sort!` * list explicitly the required properties of `lt` in `sort!` * clarify the sequence of "by" transformations if both `by` and `order` are given * show default values in the signatures for `searchsorted` and related functions * note that `by` is also applied to searched value in `searchsorted` and related * add `isunordered` to the manual (it's already exported) --------- Co-authored-by: Lilith Orion Hafner <lilithhafner@gmail.com> (cherry picked from commit a660798)
Co-authored-by: Jeremie Knuesel <knuesel@gmail.com> (cherry picked from commit a134076)
We had a special case for Type that disallowed type trait recursion in favor of a pattern that almost never appears in code (only once in the compiler by accident where it doesn't matter). This was unnecessarily confusing and unexpected to predict what can infer, and made traits harder than necessary (such as Broadcast.ndims since 70fc3cd). Fix #43296 Fix #43368 (cherry picked from commit 33e3d9f)
Extend #50587 to more general `AbstractArray`s. This is mainly to disallow `Bool` as an index in `isassigned`, as this isn't supported by `getindex`. After this ```julia julia> isassigned(rand(2,2), 1, true) ERROR: ArgumentError: invalid index: true of type Bool ``` which matches the behavior on v1.9. (cherry picked from commit b991397)
(cherry picked from commit eb4416b)
…0929) This is the part of #50927 required to fix #49249. Specifically, before this change `tmerge(Tuple{Any, Int}, Nothing)` would be `Union{Nothing, Tuple{Any, Int}}` but `tmerge(Tuple{BIG_UNION, Int}, Nothing)` would be `Union{Nothing, Tuple{Any, Any}}`. This feels bad intuitively because giving the compiler more type information led it to forget type information that it already knew about, and is especially damaging because it led to unnecessary type instability when iterating tuples with complex element types (because the iterator state should be inferrable as an `Int` even if you have no idea what the tuple type is). This is tagged for backport to 1.10 since it is a relatively unobtrusive change and it fixes the string regression in a more proper way. (cherry picked from commit 6e2e6d0)
This is just a minor update fixing several small but annoying bugs people have noticed since JuliaSyntax was integrated. (cherry picked from commit 43164cf)
Co-authored-by: Mason Protter <mason.protter@icloud.com> (cherry picked from commit 02f80c6)
…7864f (#50978) Co-authored-by: Dilum Aluthge <dilum@aluthge.com>
`unsafe_trunc(UInt, -1.0)` is unspecified behavior but worked fine on apple and AMD so we didn't notice??? This has been very broken since 1.7. (cherry picked from commit 61ebaf6)
Co-authored-by: Gabriel Baraldi <baraldigabriel@gmail.com> Co-authored-by: Dilum Aluthge <dilum@aluthge.com> (cherry picked from commit 8be469e)
(cherry picked from commit 89a7c95)
For some reason we haven't updated Statistics since April. Diff: JuliaStats/Statistics.jl@a3feba2...08562cb
ELF doesn't handle WEAK symbols dynamically the way it handles them statically. Looking up overloaded WEAK symbols via a library-specific handle will often give you the empty stub (in `libc.so.7` in this case) instead of the strong implementation elsewhere (`ld-elf.so.1` here). Even after the [upstream fix](https://cgit.freebsd.org/src/commit/?id=21a52f99440c9bec7679f3b0c5c9d888901c3694), `dlsym`, `dladdr` and a ton of other symbols still have stubs with no trampoline in FreeBSD's libc: https://cgit.freebsd.org/src/tree/lib/libc/gen/dlfcn.c?id=21a52f99440c9bec7679f3b0c5c9d888901c3694 Thankfully `dl_iterate_phdr` appears to be the only function that we directly `ccall` from Julia's Libdl so we can leave this fix incomplete for now. Resolves #50846. (cherry picked from commit c659011)
This can cause segfaults when exiting julia. Co-authored-by: Valentin Churavy <vchuravy@users.noreply.github.com> (cherry picked from commit b3741c0)
This is not a legal operation outside the lock because it's not atomic Co-authored-by: Valentin Churavy <v.churavy@gmail.com> (cherry picked from commit bbbcc4f)
(cherry picked from commit 4af6be8)
(cherry picked from commit 1142759)
Fix #50709 This issue *appears* fixed on master due to #50432, which simply removed the error. This fixes the underlying cause, which is that we sometimes return typevars in the environment from intersection that have free vars in their bounds. I think it's reasonable to just widen these aggressively, since we usually cannot do much with these kinds of unknown static parameters anyway. (cherry picked from commit a3e2316)
These test were taking on the order of 5 minutes and 10-100s of GB, but they really did not need to. (cherry picked from commit bab20f4)
…ey change it back when they're done (#51029) We already check the following for mutation by a test set: 1. DEPOT_PATH 2. LOAD_PATH 3. ENV So this PR just adds the active project to the list of things we check. Changing the active project during a test set can definitely have negative effects on subsequent test sets that are run on the same worker, so we want to make sure if a test set changes the active project, that they change it back when they're done. (cherry picked from commit 106e867)
@nanosoldier |
This backports `Fixes and improvements for source builds (#51422)` PR to the `backports-release-1.10` branch to make it buildable without binary builder (we are monitoring that branch in our CI to make sure we are up to date with the upcoming 1.10 release). Co-authored-by: Tim Besard <tim.besard@gmail.com>
Let's try that again after having restarted PkgEval with @nanosoldier |
The package evaluation job you requested has completed - possible new issues were detected. |
… computed by `abstract_apply` (#51393) This commit adds special handling for `Vararg` types that may appear at the end of `argtypes`, as computed by `abstract_apply`. Even though PR within the abstract state, they can still be part of `argtypes`. As a result, this kind of special handling is still necessary. It remains an open question whether we can refactor `abstract_apply` to prevent `Vararg`s from appearing in `argtypes` in the first place.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in 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.
Backported PRs:
CyclePadding(::DataType)
#50719Base.get_extension
to docs/API #50860threadpool
parameter toChannel
constructor #50858isapprox
#50730Task
about sticky bit #50915JL_DLLIMPORT
tosmall_typeof
declaration #50892Vararg
inabstract_call_unionall
forargtypes
computed byabstract_apply
#51393Vararg
fix inabstract_call_unionall
#51403Need manual backport:
in
of tuple of Symbols #51009Contains multiple commits, manual intervention needed:
Non-merged PRs with backport label:
AbstractQ
in concatenation #51132ispath(f)
#50919