Backports for 1.7.3 #44189
Merged
Backports for 1.7.3 #44189
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
We could also consider adding `defalg(v::AbstractArray{<:Number}) = DEFAULT_UNSTABLE`,
but it is unlikely that someone will want to do `Union` of `<:Number`
and something other than `Missing` that still would support comparison.
Relevant for JuliaStrings/InlineStrings.jl#21
(and other custom types that will want to add `defalg` support allowing
for `Union` with `Missing`).
(cherry picked from commit eb724e0)
(cherry picked from commit c3235cd)
(cherry picked from commit 1edafa0)
(cherry picked from commit 4c101a1)
* fix UndefRefError for documentation system * add a test Co-authored-by: Jameson Nash <jameson@juliacomputing.com> (cherry picked from commit 4842007)
(cherry picked from commit 2db86f2)
(cherry picked from commit c839221)
(cherry picked from commit 76dc379)
On Windows, we observed occasional issues where an error within the function callback to the `open(::Function, ::Cmd)` method would cause problems due to assuming that the opened process had finished by the time the `open()` call was finished. In most cases this was true, however on Windows, it was found that we need to explicitly `wait()` upon the process object to ensure that all file handles held by the subprocess were properly closed by the time `open()` is finished. Co-authored-by: Dilum Aluthge <dilum@aluthge.com> (cherry picked from commit 623ceb7)
* [CPUID] Rework how current ISA is determined * [CPUID] Add ISA entry for A64FX * [CPUID] Add ISA entry for Apple Silicon M1 * [CPUID] Simplify collection of full set of features for architecture * [CPUID] Remove AES from A64FX ISA, not all chips appear to have it (cherry picked from commit f45b6ad)
Co-authored-by: Jameson Nash <vtjnash@gmail.com> Co-authored-by: Fredrik Ekre <ekrefredrik@gmail.com> (cherry picked from commit f5d9b86)
vtjnash
force-pushed
the
backports-release-1.7
branch
from
7ff34c1 to
713a5b1
Compare
(cherry picked from commit f20d5de)
Because we're starting to distribute macOS tarballs as well, let's codesign them by default, when possible. (cherry picked from commit 6b29ebd)
…et (#44262) We collect the relocations (i.e. the GOT slots that is used in the code) for each target in `tgt.relocs`. Needing a relocation, however, does not imply that the function is cloned for this target within the group (It does mean that at least one target in the group has it cloned). The previous version would miss the relocation in this case. This was triggerred with the following cloning situation caller: clone_1 callee: clone_1, clone_1.clone_3 Since caller.clone_1 may call either callee.clone_1 or callee.clone_1.clone_3 a relocation for callee will be used and is required to be initialized. In addition to target 1, target 2 (and in fact target 3) within group 1 will also use caller.clone_1. However, since callee isn't cloned for target 2 the previous version wouldn't have saved this slot in the relocation array. (cherry picked from commit 76fc067)
Co-authored-by: Simeon David Schaub <schaub@mit.edu> (cherry picked from commit 2338f5d)
(cherry picked from commit 610fc20)
If a user runs the tests with a `~/.gitconfig` that provides an `init.defaultBranch` that is not `master`, our tests fail. Let's adjust to the user's configuration as appropriate. We'll also rename this to `default_branch` to signify that it may not be called `master` anymore. (cherry picked from commit ac1d693)
Discovered while running the syntax tests with lines 25-28 of `jlfrontend.scm` commented out. Turned out we didn't handle `.op` correctly in neither `check-dotop` nor in `deparse`. This meant we just got `error: malformed expression` instead of an actually useful error message. (cherry picked from commit 9112135)
(cherry picked from commit c589e0d)
(cherry picked from commit b405562)
Note: this is the first build of the real upstream version 1.2.12 which was released a few days ago. (cherry picked from commit 81e7cfc)
The event might have triggered on another thread before we observed it here, or it might have gotten finalized before it got triggered. Either outcome can result in a lost event. (I observed the later situation occurring locally during the Dates test once). (cherry picked from commit 8cc00ff)
KristofferC
force-pushed
the
backports-release-1.7
branch
from
ea86a62 to
6e5b031
Compare
|
@nanosoldier |
|
@nanosoldier |
|
Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. |
|
Your package evaluation job has completed - possible new issues were detected. A full report can be found here. |
This comment was marked as outdated.
This comment was marked as outdated.
(cherry picked from commit 4170090)
|
Can #44671 also be included here? 🙂 |
* avoid using `@sync_add` on remotecalls It seems like @sync_add adds the Futures to a queue (Channel) for @sync, which in turn calls wait() for all the futures synchronously. Not only that is slightly detrimental for network operations (latencies add up), but in case of Distributed the call to wait() may actually cause some compilation on remote processes, which is also wait()ed for. In result, some operations took a great amount of "serial" processing time if executed on many workers at once. For me, this closes #44645. The major change can be illustrated as follows: First add some workers: ``` using Distributed addprocs(10) ``` and then trigger something that, for example, causes package imports on the workers: ``` using SomeTinyPackage ``` In my case (importing UnicodePlots on 10 workers), this improves the loading time over 10 workers from ~11s to ~5.5s. This is a far bigger issue when worker count gets high. The time of the processing on each worker is usually around 0.3s, so triggering this problem even on a relatively small cluster (64 workers) causes a really annoying delay, and running `@everywhere` for the first time on reasonable clusters (I tested with 1024 workers, see #44645) usually takes more than 5 minutes. Which sucks. Anyway, on 64 workers this reduces the "first import" time from ~30s to ~6s, and on 1024 workers this seems to reduce the time from over 5 minutes (I didn't bother to measure that precisely now, sorry) to ~11s. Related issues: - Probably fixes #39291. - #42156 is a kinda complementary -- it removes the most painful source of slowness (the 0.3s precompilation on the workers), but the fact that the wait()ing is serial remains a problem if the network latencies are high. May help with #38931 Co-authored-by: Valentin Churavy <vchuravy@users.noreply.github.com> (cherry picked from commit 62e0729)
|
@nanosoldier |
|
Your package evaluation job has completed - possible new issues were detected. A full report can be found here. |
|
Failure for BestApproximation is a bugfix from #44676 which makes the package test fail. |
|
@nanosoldier |
|
Your package evaluation job has completed - possible new issues were detected. A full report can be found here. |
|
@staticfloat Will we need to turn on all of the buildbots for Kristoffer and Alex to be able to get binaries for this release? |
|
Yes, I believe so. |
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:
throw InexactErrorfromtryparsenext#44004generate_precompile_statements#44196hvncatimplementation #43940addenvfor environment entries with embedded=#44212open(::Function, ::Cmd)waits for termination #44078NamedTuplecan be bitstype more often #44311init.defaultBranch#44629round(Integer, big(Inf))#44676.opin lowering #44770(::typeof(x))() = ...#43993Need manual backport:
Contains multiple commits, manual intervention needed:
svdandeigenofDiagonals #43856Non-merged PRs with backport label: