Backports 1.12 #57408
Backports 1.12 #57408
Conversation
This was noted in the original review of that PR by the PR author, but was for some reason not fixed at that time: #46693 (comment) (cherry picked from commit db874ff)
Before: ``` :($(Expr(:thunk, CodeInfo( 1 ─ $(Expr(:thunk, CodeInfo( 1 ─ return $(Expr(:method, :(Main.f))) ))) │ $(Expr(:method, :(Main.f))) │ %3 = Main.f │ %4 = dynamic Core.Typeof(%3) │ %5 = builtin Core.svec(%4, Core.Any) │ %6 = builtin Core.svec() │ %7 = builtin Core.svec(%5, %6, $(QuoteNode(:(#= REPL[2]:1 =#)))) │ $(Expr(:method, :(Main.f), :(%7), CodeInfo( 1 ─ return 1 ))) │ $(Expr(:latestworld)) │ %10 = Main.f └── return %10 )))) ``` After: ``` julia> @Meta.lower f(x)=1 :($(Expr(:thunk, CodeInfo( 1 ─ $(Expr(:method, :(Main.f))) │ $(Expr(:latestworld)) │ Main.f │ $(Expr(:latestworld)) │ %5 = Main.f │ %6 = dynamic Core.Typeof(%5) │ %7 = builtin Core.svec(%6, Core.Any) │ %8 = builtin Core.svec() │ %9 = builtin Core.svec(%7, %8, $(QuoteNode(:(#= REPL[1]:1 =#)))) │ $(Expr(:method, :(Main.f), :(%9), CodeInfo( 1 ─ return 1 ))) │ $(Expr(:latestworld)) │ %12 = Main.f └── return %12 )))) ``` This doesn't really make a semantic difference, but if `f` is a type, we may now give a warning, so the prior definition would give the warning twice (#57311 (comment)). We may want to consider rate-limiting the warning independently, but for now at least give the correct number of warnings. (cherry picked from commit 512eb5e)
Rather than rewriting the `restriction` of the bparts. With this, I believe this removes that last point where `restriction` is overwritten after construction, hopefully allowing us to go back to the original design where `restriction` is `const` after construction. (cherry picked from commit 90046a0)
When we have implicit binding edges from literal GlobalRefs, these edges imply a implicit minimum world age of jl_require_age (which is what all bindings loaded from pkgimages get their definition age set to). In #57318, the `cpuid_llvm` minimum world age got set to `1` rather than `jl_require_world`, so codegen would refuse to perform the llvmcall special codegen, since it couldn't guarantee that the binding would actually resolve to `llvmcall` in all worlds. Fix that by adjusting staticdata.jl to set the appropriate minworld. That said, there are a few complicating factors here: 1. In general, most of our code doesn't handle world ranges with more than one partition. But for example, codegen could have checked the current world age and implicitly partitioned the binding at codegen time (in practice just adding an appropraite error check). 2. The included test case uses a cached inference. However, in the original issue it appeared that inlining was also creating new references to this replaced binding, which should not have been permitted. I have not fully investigated this behavior yet and this might be another bug. 3. In the original issue, the specialization had its max_world terminated a few ages past jl_require_world. I do not understand this behavior yet. Still, fixes #57318. (cherry picked from commit c6805e2)
Inspired by the question in #57311 (comment), I want to revisit the basic setup where every module `using`s both `Core` and `Base`. In general, I think we mostly expect users to inferface with `Base`, not `Core`, so this PR changes things to only have new modules `using` Base (while re-exporting all `Core` names from `Base`). There should be little user-visible impact from these changes. The only situation I can think of where it makes a difference is if somebody were to make their own Base/toplevel module that does not re-export Core. However, we don't really support that situation in the first place, and I actually think it's a feature that such toplevel modules can more closely control the set of implicitly exposed names. (cherry picked from commit 20162ea)
The original design for the BindingPartition datastructure had ->restriction and ->kind as separate non-atomic fields. However, to support the old semantics, we created an intermediate state where both the restriciton and the kind were placed into ->restriction as a pointer-int-union (i.e. using the low three bits of the pointer to store an int). In #57341, I removed that last semantic place that needed to update these both atomically. This PR removes all the remaining non-semantic places and changes the datastructure back to its indended design. This is a necessary prerequisitve to be able to use more than three ->kind bits, which will be required for export invalidation (#57377), as well as some nicer error messages in failure cases. (cherry picked from commit 40fbc88)
Stdlib: Statistics URL: https://github.com/JuliaStats/Statistics.jl.git Stdlib branch: master Julia branch: master Old commit: d49c2bf New commit: 77bd570 Julia version: 1.13.0-DEV Statistics version: 1.11.2(Does not match) Bump invoked by: @nalimilan Powered by: [BumpStdlibs.jl](https://github.com/JuliaLang/BumpStdlibs.jl) Diff: JuliaStats/Statistics.jl@d49c2bf...77bd570 ``` $ git log --oneline d49c2bf..77bd570 77bd570 Fix `quantile` doctest (#188) bfa5c6b Merge pull request #184 from JuliaStats/an/quantilemuladd 6bd1531 Update src/Statistics.jl 44d51c7 Use muladd in aleph calculation in _quantile to avoid some rounding errors. 793733e Bump codecov/codecov-action from 4 to 5 (#181) ``` Co-authored-by: nalimilan <[email protected]> (cherry picked from commit 504cbc3)
See also: Triage request for this: #57067 (comment) Similar PR for `lcm`: #56992 (cherry picked from commit 41a4dfa)
Deferring this part of defining the ctor code allows it to do some
value-based optimizations, without the awkwardness previously of needing
to do conditional lowering of all of the possible versions that might be
useful just from syntax transforms. This feels very like a generated
function: how it expands just the function body, except it is flipped so
that then we wrap the result in a single Method instead of being created
from a Method!
Avoids lowering inaccuracies where a variable appears but is not used.
These warnings are now prevented:
```julia
julia> struct Foo{T}
x::(T; Any)
end
WARNING: method definition for Foo at REPL[1]:2 declares type variable T but does not use it.
julia> struct Foo{T}
x::Union{Any, T}
end
WARNING: method definition for Foo at REPL[1]:2 declares type variable T but does not use it.
```
Avoids hitting #31542. This
lowering mistake is now avoided:
```julia
julia> struct Foo{T}
x::(Val{T} where T)
end
ERROR: syntax: invalid variable expression in "where" around REPL[1]:2
```
As a minor optimization, this avoids generating a `convert` call when
the user declares explicit `::Any` declarations, the same as if the user
didn't annotate the field type:
```julia
julia> struct Foo
x::Any
y::Int
z
end
julia> code_lowered(Foo)[2]
CodeInfo(
@ REPL[1]:2 within `unknown scope`
1 ─ %1 = builtin Core.fieldtype(#ctor-self#, 2)
│ %2 = y
│ @_4 = %2
│ %4 = builtin @_4 isa %1
└── goto #3 if not %4
2 ─ goto #4
3 ─ @_4 = Base.convert(%1, @_4)
4 ┄ %8 = @_4
│ %9 = %new(#ctor-self#, x, %8, z)
└── return %9
)
```
The outer/inner names might be a bit historical at this point (predating
where clauses allowing specifying them flexibly inside or outside of the
struct def): they are really exact-type-type&convert-args-from-any /
exact-arg-types&apply-type-from-args if named for precisely what they
do.
(cherry picked from commit f4a9d25)
Whether or not a binding is exported affects the binding resolution of any downstream modules that `using` the module that defines the binding. As such, it needs to fully participate in the invalidation mechanism, so that code which references bindings whose resolution may have changed get properly invalidated. To do this, move the `exportp` flag from Binding into a separate bitflag set that gets or'd into the BindingPartition `->kind` field. Note that we do not move `publicp` in the same way since it does not affect binding resolution. There is currently no mechanism to un-export a binding, although the system is set up to support this in the future (and Revise may want it). That said, at such a time, we may need to revisit the above decision on `publicp`. Lastly, I will note that this adds a fair number of additional invalidations. Most of these are unnecessary, as changing an export only affects the *downstream* users not the binding itself. I am planning to tackle this as part of a larger future PR that avoids invalidation when this is not required. Fixes #57377 (cherry picked from commit b27a24a)
Should fix the error part of #57329. I also cannot reproduce the underlying assertion error on master, so that was likely fixed in one of the other PRs. Closes #57329 as a result, but of course there could be other issues with the same symptoms, which can get their own issues. (cherry picked from commit 88b292d)
This makes non-guard bindings stronger than guard bindings for ambiguity purposes. Note that both of these are yet stronger than deprecated bindings, so if there's a "non-guard deprecated" binding and a "guard non-deprecated" binding, the latter will win and the access will be UndefVarError. I think this is the closest to the 1.11 behavior without relying on resolvedness. Fixes #57404 This PR is against #57405 just because that PR touches the common interface, but is conceptually independent. (cherry picked from commit a371899)
This has been bouncing around as a idea for a while. One of the challenges around time-to-safepoint has been Julia code that is calling libraries. Since foreign code will not include safepoints we see increased latency when one thread is running a foreign-call and another wants to trigger GC. The open design question here is: - Do we expose this as an option the user must "opt-in", e.g. by using a keyword arg to `@ccall` or a specific calling-convetion. - Or do we turn this on for all ccall, except for Julia runtime calls. There is relativly little code outside the Julia runtime that needs to be "GC unsafe", exception are programs that directly use the Julia C-API. Incidentially `jl_adopt_thread` and `@cfunction`/`@ccallable` do the right thing and transition to "GC unsafe", regardless of what state the thread currently is in. I still need to figure out how to reliably detect Julia runtime calls, but I think we can switch all other calls to "GC safe". We should also consider optimizations that mark large regions of code without Julia runtime interactions as "GC safe" in particular numeric for-loops. Closes #57057 --------- Co-authored-by: Gabriel Baraldi <[email protected]> (cherry picked from commit 85458a0)
|
@nanosoldier |
|
The package evaluation job you requested has completed - possible new issues were detected. Report summary❗ Packages that crashed30 packages crashed only on the current version.
✖ Packages that failed662 packages failed only on the current version.
28 packages failed on the previous version too. ✔ Packages that passed tests2 packages passed tests only on the current version.
249 packages passed tests on the previous version too. ➖ Packages that were skipped altogether1 packages were skipped only on the current version.
|
Backported PRs:
usingBase, not Core #57357gcd#57204Pairspublic #56794(-Inf)^-1inconsistency #55875Contains multiple commits, manual intervention needed:
Non-merged PRs with backport label:
linearize#57416RationalfromAbstractIrrational#55853