-
-
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
Backports for 1.11.1 #56025
Backports for 1.11.1 #56025
Conversation
(cherry picked from commit 81ce6a4)
(cherry picked from commit fbb3e11)
While building the 1.11.0-rc4 in Homebrew[^1] in preparation for 1.11.0 release (and to confirm Sequoia successfully builds) I noticed some odd linkage for our Linux builds, which included of: 1. LLVM libraries were linking to `libedit.so`, e.g. ``` Dynamic Section: NEEDED libedit.so.0 NEEDED libz.so.1 NEEDED libzstd.so.1 NEEDED libstdc++.so.6 NEEDED libm.so.6 NEEDED libgcc_s.so.1 NEEDED libc.so.6 NEEDED ld-linux-x86-64.so.2 SONAME libLLVM-16jl.so ``` CMakeCache.txt showed ``` //Use libedit if available. LLVM_ENABLE_LIBEDIT:BOOL=ON ``` Which might be overriding `HAVE_LIBEDIT` at https://github.com/JuliaLang/llvm-project/blob/julia-release/16.x/llvm/cmake/config-ix.cmake#L222-L225. So just added `LLVM_ENABLE_LIBEDIT` 2. Wasn't sure if there was a reason for this but `libccalllazy*` had mismatched SONAME: ```console ❯ objdump -p lib/julia/libccalllazy* | rg '\.so' lib/julia/libccalllazybar.so: file format elf64-x86-64 NEEDED ccalllazyfoo.so SONAME ccalllazybar.so lib/julia/libccalllazyfoo.so: file format elf64-x86-64 SONAME ccalllazyfoo.so ``` Modifying this, but can drop if intentional. --- [^1]: Homebrew/homebrew-core#192116 (cherry picked from commit 77c5875)
Minor formatting fix (cherry picked from commit 42737f7)
(cherry picked from commit 3a132cf)
…0d22b (#56032) Stdlib: Pkg URL: https://github.com/JuliaLang/Pkg.jl.git Stdlib branch: release-1.11 Julia branch: backports-release-1.11 Old commit: 6ceafca8e New commit: aba90d22b Julia version: 1.11.0 Pkg version: 1.11.0 Bump invoked by: @IanButterworth Powered by: [BumpStdlibs.jl](https://github.com/JuliaLang/BumpStdlibs.jl) Diff: JuliaLang/Pkg.jl@6ceafca...aba90d2 ``` $ git log --oneline 6ceafca8e..aba90d22b aba90d22b Merge pull request #4037 from JuliaLang/backports-release-1.11 76eaa4caa Fix julia#55850 by using safe_realpath instead of abspath in projname (#4025) df38587fb warn if General is installed via the old slow methods (#4022) 1475b628a update package extension naming docs (#4000) 72dc85e80 Tweak sentence syntax in getting-started.md (#4020) 0b2397089 make `add` and `dev` on a package remove it from the set of weak dependencies (#3865) ee2d51054 collect e.g. weak deps from project even if it is not a package (#3852) ``` Co-authored-by: Dilum Aluthge <[email protected]>
This had the incorrect number of arguments to `Expr(:purity, ...)` causing it to be silently ignored.
There is a use case where you have a weak dependency (for one of your extensions) that is misbehaving and you quickly want to try debug that issue. A workflow that feels reasonable for this could be: ``` pkg> dev WeakDependency julia> using Package, WeakDependency ``` This doesn't work right now for two reasons: 1. Doing the `dev WeakDependency` will add the dependency to `[deps]` but not remove it from `[weakdeps]` which means you all of a sudden are in the scenario described in https://pkgdocs.julialang.org/v1/creating-packages/#Transition-from-normal-dependency-to-extension which is not what is desired. 2. The extension will not actually load because you can right now only trigger extensions from weak deps getting loaded, not from deps getting loaded. Point 1. is fixed by JuliaLang/Pkg.jl#3865 Point 2. is fixed by this PR. (cherry picked from commit f46cb4c)
The current way of loading extensions when precompiling an extension very easily leads to cycles. For example, if you have more than one extension and you happen to transitively depend on the triggers of one of your extensions you will immediately hit a cycle where the extensions will try to load each other indefinitely. This is an issue because you cannot directly influence your transitive dependency graph so from this p.o.v the current system of loading extension is "unsound". The test added here checks this scenario and we can now precompile and load it without any warnings or issues. Would have made #55517 a non issue. Fixes #55557 --------- Co-authored-by: KristofferC <[email protected]> (cherry picked from commit 4da0671)
Sorry, git made it seem like I was deleting a branch on my fork, not here.. |
(cherry picked from commit 243bded)
The release number with the most number of 1s unless we get to 1.11.11. |
@nanosoldier |
This was very explicitly designed such that if there was a bunch of extra space at the end of the array, we would copy rather than allocating, but by making `newmemlen` be at least `overallocation(memlen)` rather than `overallocation(len)`, this branch was never hit. found by #56026 (cherry picked from commit d4ca92c) Co-authored-by: Oscar Smith <[email protected]>
…hes (#53469) We can detect this since we set the `usingfailed` bit when the clash occurs (to avoid printing the `WARNING` multiple times). In this case, typos or missing imports (the current message) isn't quite as clear as it could be, because in fact the name is probably spelled totally right, it's just that there is a missing explicit import or the name should be qualified. This code will stop working if we change the flags in `Core.Binding`, but the test I added should catch that. However if REPL is supposed to be independent of Base and not depend on internals there, there could be an issue. In that case we should probably add an API to Base to inspect this `usingfailed` bit so we can use it in the REPL. --------- Co-authored-by: Jameson Nash <[email protected]> Co-authored-by: Alex Arslan <[email protected]> (cherry picked from commit 0f902bf)
(cherry picked from commit 1438b15)
The package evaluation job you requested has completed - possible new issues were detected. |
Many of the PkgEval failures are from JuliaSIMD/VectorizationBase.jl#114. There is no problem with https://github.com/JuliaLang/julia/pull/56061/files but I will revert it so that I can rerun PkgEval with reduced noise. |
@nanosoldier |
The package evaluation job you requested has completed - possible new issues were detected. |
72cba22
to
4cf3975
Compare
48b06fc
to
4e03986
Compare
Backported PRs:
?
docstring example #55945@time
actually fix time report commas & add tests #55982safe_realpath
instead ofabspath
inprojname
#55851stat
-ing stdlib path if it's unreadable #55992ScopedValues.@with
within a scope #56019@error
for hints #56041UndefVarError
results from name clashes #53469_growbeg!
unnecessary resizing #56029Need manual backport:
Contains multiple commits, manual intervention needed:
Non-merged PRs with backport label:
(pop-handler-list ...)
#55871promote_type
forIrrational
#55870hash
doc string:widen
not required any more #55867@ccallable
name before JIT registration #55813displaysize
to theIOContext
used by the REPL #55499isfile_casesensitive
fixes on Windows #55220propertynames
for SVD respects private argument #55169String(::Memory)
copy #54457@inbounds
andBase.@propagate_inbounds
#50157