DO NOT MERGE: v1.12 branch for comparison to master #202
Conversation
This file contains hidden or 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
nickrobinson251
force-pushed
the
v1.12.0-DEV+RAI
branch
4 times, most recently
from
966538b to
9da665d
Compare
d-netto
force-pushed
the
v1.12.0-DEV+RAI
branch
from
9da665d to
48a5871
Compare
nickrobinson251
force-pushed
the
v1.12.0-DEV+RAI
branch
from
48a5871 to
5974904
Compare
DelveCI
force-pushed
the
v1.12.0-DEV+RAI
branch
7 times, most recently
from
1cff7d7 to
1e6e20d
Compare
DelveCI
force-pushed
the
v1.12.0-DEV+RAI
branch
2 times, most recently
from
9815a48 to
38eead6
Compare
Addresses mystery #3 in JuliaLang#57381 (and extends the test from that issue). (cherry picked from commit cff8bd6)
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 JuliaLang#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 (JuliaLang#57377), as well as some nicer error messages in failure cases. (cherry picked from commit 40fbc88)
Resolves JuliaLang#56950. This should get backported to julia-1.12. (cherry picked from commit b3198c9)
…ang#57266) 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 <1120448+nalimilan@users.noreply.github.com> (cherry picked from commit 504cbc3)
Previously didn't handle ccall or cfunction that were assigned to a variable. Required for inlining correctness. Fixes JuliaLang#57023 (cherry picked from commit 57b7d2e)
See also: Triage request for this: JuliaLang#57067 (comment) Similar PR for `lcm`: JuliaLang#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 JuliaLang#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)
DelveCI
force-pushed
the
v1.12.0-DEV+RAI
branch
from
38eead6 to
7d154ea
Compare
…ng#57407) This seems basically the same as JuliaLang#57212, but from computing and using `method_roots_list` wrong instead here (specifically the recursively part). Fix it by integrating `jl_collect_new_roots` with the places we actually need it. Fixes JuliaLang#56994 (cherry picked from commit f5f6d41)
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 JuliaLang#57377 (cherry picked from commit b27a24a)
Should fix the error part of JuliaLang#57329. I also cannot reproduce the underlying assertion error on master, so that was likely fixed in one of the other PRs. Closes JuliaLang#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)
fixes JuliaLang#55831 (cherry picked from commit 2364719)
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 JuliaLang#57404 This PR is against JuliaLang#57405 just because that PR touches the common interface, but is conceptually independent. (cherry picked from commit a371899)
…ang#49933) 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 JuliaLang#57057 --------- Co-authored-by: Gabriel Baraldi <baraldigabriel@gmail.com> (cherry picked from commit 85458a0)
This adds the changes required to guess the MethodInstance that the runtime will eventually invoke for this call, enqueue it for codegen, and then verify its presence in the verifier.
Otherwise this will match `ftyp === Builtin`, which is pretty silly since that could just as well be any other built-in.
See JuliaLang#58143 for details.
…xx` (JuliaLang#58325) Otherwise these subroutines may raise `unhandled Vararg` errors when compiling e.g. CassetteOverlay for complex call graphs.
This is a follow-up to JuliaLang#54341. Otherwise, `validate_code!` may raise wrong errors for unmatched `nargs` information between generated code and original method.
This reverts commit f15d417.
…s from packages succeed. TODO: remove this once alpha/beta is released # Conflicts: # VERSION # Conflicts: # VERSION
Prevent transparent huge pages (THP) overallocating pysical memory. Co-authored-by: Adnan Alhomssi <adnan.alhomssi@relational.ai>
Prepend `[signal (X) ]thread (Y) ` to each backtrace line that is displayed. Co-authored-by: Diogo Netto <61364108+d-netto@users.noreply.github.com>
Also show the signal number when we have it.
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.
See also RAICode PR https://github.com/RelationalAI/raicode/pull/22602/commits