DO NOT MERGE: v1.12 branch for comparison to master #202
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
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
5 times, most recently
from
50775dd to
fd6934f
Compare
I couldn't find `time_ns` when I was looking for it, nice to make clear the "monotonic" clock is also available in Base. (cherry picked from commit a52de83)
DelveCI
force-pushed
the
v1.12.0-DEV+RAI
branch
from
fd6934f to
1cff7d7
Compare
…uliaLang#57241) The `fork()` we do here relies on `SIGCHLD` to make sure that we don't race against the child. This is easy to see in an embedding application that dynamically links `libjulia`: ```c int main(int argc, char *argv[]) { signal(SIGCHLD, SIG_IGN); void *handle = dlopen("path/to/libjulia.so", RTLD_LAZY); return 0; } ``` Without this change, this fails with an error message: ``` Error during libstdcxxprobe in parent process: waitpid: No child processes ``` Resolves JuliaLang#57240 (cherry picked from commit daf865e)
Restores JuliaLang#57035, undo JuliaLang#57089 for non-FreeBSD. While I suggested doing this change for all platforms, I forgot that means non-FreeBSD platforms become vulnerable again to the very deadlock problems that JuliaLang#57035 was required to prevent. That fix seems to not be viable on FreeBSD due to known libc implementation problems on that platform. However, upon closer inspection of the questionable design implementation decisions they seem to have made here, the platform is likely not currently vulnerable to this libunwind bug in the first place: https://github.com/lattera/freebsd/blob/master/libexec/rtld-elf/rtld_lock.c#L120 (cherry picked from commit 2f0a523)
…57211) It looks like these methods were just missed while overloading for BufferStream. There's also `readbytes!` where the current implementation will fallback to the `LibuvStream` implementation that is currently not threadsafe. What's the best approach there since the implementation is quite a bit more involved? Just duplicate the code but for BufferStream? Should we take the BufferStream lock and invoke the LibuvStream method? Open to ideas there. Also open to suggestions for having tests here? Not easy to simulate the data race of writing and calling readavailable. The fix here will unblock JuliaWeb/HTTP.jl#1213 (I'll probably do some compat shim there until this is fully released). Thanks to @oscardssmith for rubber ducking this issue with me. Probably most helpfully reviewed by @vtjnash. --------- Co-authored-by: Jameson Nash <[email protected]> (cherry picked from commit ffc96bc)
(cherry picked from commit 99fd5d9)
…ce (JuliaLang#57226) (cherry picked from commit ca7cf30)
This is the final PR in the binding partitions series (modulo bugs and tweaks), i.e. it closes JuliaLang#54654 and thus closes JuliaLang#40399, which was the original design sketch. This thus activates the full designed semantics for binding partitions, in particular allowing safe replacement of const bindings. It in particular allows struct redefinitions. This thus closes timholy/Revise.jl#18 and also closes JuliaLang#38584. The biggest semantic change here is probably that this gets rid of the notion of "resolvedness" of a binding. Previously, a lot of the behavior of our implementation depended on when bindings were "resolved", which could happen at basically an arbitrary point (in the compiler, in REPL completion, in a different thread), making a lot of the semantics around bindings ill- or at least implementation-defined. There are several related issues in the bugtracker, so this closes JuliaLang#14055 closes JuliaLang#44604 closes JuliaLang#46354 closes JuliaLang#30277 It is also the last step to close JuliaLang#24569. It also supports bindings for undef->defined transitions and thus closes JuliaLang#53958 closes JuliaLang#54733 - however, this is not activated yet for performance reasons and may need some further optimization. Since resolvedness no longer exists, we need to replace it with some hopefully more well-defined semantics. I will describe the semantics below, but before I do I will make two notes: 1. There are a number of cases where these semantics will behave slightly differently than the old semantics absent some other task going around resolving random bindings. 2. The new behavior (except for the replacement stuff) was generally permissible under the old semantics if the bindings happened to be resolved at the right time. With all that said, there are essentially three "strengths" of bindings: 1. Implicit Bindings: Anything implicitly obtained from `using Mod`, "no binding", plus slightly more exotic corner cases around conflicts 2. Weakly declared bindings: Declared using `global sym` and nothing else 3. Strongly declared bindings: Declared using `global sym::T`, `const sym=val`, `import Mod: sym`, `using Mod: sym` or as an implicit strong global declaration in `sym=val`, where `sym` is known to be global (either by being at toplevle or as `global sym=val` inside a function). In general, you always allowed to syntactically replace a weaker binding by a stronger one (although the runtime permits arbitrary binding deletion now, this is just a syntactic constraint to catch errors). Second, any implicit binding can be replaced by other implicit bindings as the result of changing the `using`'ed module. And lastly, any constants may be replaced by any other constants (irrespective of type). We do not currently allow replacing globals, but may consider changing that in 1.13. This is mostly how things used to work, as well in the absence of any stray external binding resolutions. The most prominent difference is probably this one: ``` set_foo!() = global foo = 1 ``` In the above terminology, this now always declares a "strongly declared binding", whereas before it declared a "weakly declared binding" that would become strongly declared on first write to the global (unless of course somebody had created a different strongly declared global in the meantime). To see the difference, this is now disallowed: ``` julia> set_foo!() = global foo = 1 set_foo! (generic function with 1 method) julia> const foo = 1 ERROR: cannot declare Main.foo constant; it was already declared global Stacktrace: [1] top-level scope @ REPL[2]:1 ``` Before it would depend on the order of binding resolution (although it just crashes on current master for some reason - whoops, probably my fault). Another major change is the ambiguousness of imports. In: ``` module M1; export x; x=1; end module M2; export x; x=2; end using .M1, .M2 ``` the binding `Main.x` is now always ambiguous and will throw on access. Before which binding you get, would depend on resolution order. To choose one, use an explicit import (which was the behavior you would previously get if neither binding was resolved before both imports). (cherry picked from commit 888cf03)
…#57273) Fixes JuliaLang#56864. Ref https://github.com/JuliaLang/julia/blob/99fd5d9a92190e826bc462d5739e7be948a3bf44/stdlib/REPL/src/LineEdit.jl#L504 --------- Co-authored-by: Ian Butterworth <[email protected]> (cherry picked from commit f0446c6)
- Update `JuliaSyntax.jl` to v1.0.1 - Revert workaround changes, use original test case `n37134` Fix JuliaLang#57223 (cherry picked from commit 97c920d)
DelveCI
force-pushed
the
v1.12.0-DEV+RAI
branch
from
1cff7d7 to
1e6e20d
Compare
Addresses review comment in JuliaLang#57212 (comment). The key is that the hand-off of responsibility for verification between the loading code and the ordinary backedge mechanism happens under the world counter lock to ensure synchronization. (cherry picked from commit 34aceb5)
Updating mmtk-julia version to include mmtk/mmtk-julia#228 and fix the MMTk CI. I've also changed the allocation profiler tests to skip all tests instead of just a few since I've seen some spurious errors - they should all be related though, we need to make sure the profiler accounts for fastpath allocation (see JuliaLang#57103) This should fix JuliaLang#57306. (cherry picked from commit 72f8a10)
Similar to JuliaLang#57229, this commit ensures that `Compiler.finish!` properly synchronizes the operations to set `max_world` for cached `CodeInstance`s by holding the world counter lock. Previously, `Compiler.finish!` relied on a narrow timing window to avoid race conditions, which was not a robust approach in a concurrent execution environment. This change ensures that `Compiler.finish!` holds the appropriate lock (via `jl_promote_ci_to_current`). (cherry picked from commit 4ebb50b)
(cherry picked from commit 132057c)
Fixes JuliaLang#54560 (comment) (cherry picked from commit 79e98e3)
This adds a warning for the auto-import of types cases (JuliaLang#25744) that we have long considered a bit of a bug, but didn't want to change because it is too breaking. The reason to do it now is that the binding rework has made this case more problematic (see JuliaLang#57290). To summarize, the question is what happens when the compiler sees `f(x) = ...` and `f` is currently and implicitly imported binding. There are two options: 1. We add a method to the generic function referred to by `f`, or 2. We create a new generic function `f` in the current module. Historically, case 1 has the additional complication that this error'd unless `f` is a type. It is my impression that a lot of existing code did not have a particularly good understanding of the resolved-ness dependence of this behavior. However, because case 1 errors for generic functions, it appears that existing code generally expects case 2. On the other hand, for types, there is existing code in both directions (JuliaLang#57290 is an example of case 2; see JuliaLang#57302 for examples of case 1). That said, case 1 is more common (because types tend to be resolved because they're used in signatures at toplevel). Thus, to retain compatibility, the current behavior on master (where resolvedness is no longer available) is that we always choose case 2 for functions and case 1 for types. This inconsistency is unfortunate, but I tried resolving this in either way (making all situations case 1 or all case 2) and the result was too breaking. Nevertheless, it is problematic that there is existing code that expects case 2 beavior for types and we should help users to know what the correct way to fix it is. The proposed resolution is thus: 1. Retain case 1 behavior for types 2. Make it a warning to use, encouraging people to explicitly import, since we generally consider the JuliaLang#25744 case a bug. Example: ``` julia> module Foo String(i::Int) = i end WARNING: Type Core.String was auto-`import`ed in `Foo`. NOTE: This behavior is deprecated and may change in future Julia versions. NOTE: This behavior may have differed in Julia versions prior to 1.12 depending on binding resolution. Hint: To retain the current behavior, add an explicit `import Core: String` in Foo. Hint: To create a new generic function of the same name use `function String end`. Main.Foo ``` (cherry picked from commit 8c62f42)
introduced in JuliaLang#56144 --------- Co-authored-by: Mosè Giordano <[email protected]> (cherry picked from commit dd13878)
…ng#58027) After JuliaLang#55575, inference for basic statements got inlined into `typeinf_local`. But external abstract interpreters like JET.jl need to overload this inference to customize this behavior. So this commit extracts the inlined inference logic back out into a separate `abstract_eval_basic_statement` method.
Edge invalidations of the form
```julia
Package InvalidA:
module InvalidA
f(::Integer) = 1
invokesfs(x) = invoke(f, Tuple{Signed}, x)
end
Package InvalidB:
module InvalidB
using InvalidA
InvalidA.invokesfs(1) # precompile
end
```
used as
```julia
using PkgA
InvalidA.f(::Signed) = 4
using PkgB
```
did not formerly attribute a "cause":
```
...
Tuple{typeof(InvalidA.f), Signed}
"insert_backedges_callee"
CodeInstance for MethodInstance for InvalidA.invokesfs(::Int64)
nothing
...
```
This fills in the new method that replaced the previous dispatch.
---------
Co-authored-by: Jameson Nash <[email protected]>
(cherry picked from commit 15e0deb)
Closes JuliaLang#57376 Closes JuliaLang#34037 - Adds a lock in `SimpleLogger` and `ConsoleLogger` for use on maxlog tracking and stream writes to improve threadsafety. Closely similar to JuliaLang#54497 - Turns the internal `_min_enabled_level` into a `Threads.Atomic`. There are [some direct interactions](https://juliahub.com/ui/Search?type=code&q=_min_enabled_level&w=true) to this internal in the ecosystem, but they should still work ``` julia> Base.CoreLogging._min_enabled_level[] = Logging.Info+1 LogLevel(1) ``` - Brings tests over from JuliaLang#57448 Performance seems highly similar: ### Master ``` julia> @time for i in 1:10000 @info "foo" maxlog=10000000 end [ Info: foo ... 0.481446 seconds (1.33 M allocations: 89.226 MiB, 0.49% gc time) ``` ### This PR ``` 0.477235 seconds (1.31 M allocations: 79.002 MiB, 1.77% gc time) ``` (cherry picked from commit 9af9650)
…aLang#58006) (cherry picked from commit 75d5588)
- Use `local` where variable names accidentally overlapped and caused
boxes
- Use `@lock` to avoid closures
- Move out some recursive closures to top-level normal function to avoid
boxing them
- Use explicit boxes (`Ref`) instead of relying on the typeassert on the
`Core.Box` because it it hard to determine if a `Core.Box` is benign or
not.
- Only assign to `io` once to avoid boxing it.
- Type assert some `Tuple{Int, Int}` on `IO`.
The two remaining boxes after this is `t_print` and `monitor_std`.
(cherry picked from commit 4a3eba3)
By moving the optional `assume_bindings_static` refinement logic into `abstract_eval_partition_load` and removing the redirect via `abstract_eval_globalref_partition`. Also adds test cases with `assume_bindings_static=true`.
…aLang#58018) also add more fast path.
DelveCI
force-pushed
the
v1.12.0-DEV+RAI
branch
from
4391727 to
f3abd65
Compare
GNU MPFR version 4.2.2 was released on 20 March 2025. Fix JuliaLang#57945 --------- Co-authored-by: Mosè Giordano <[email protected]> (cherry picked from commit 9d4e31f)
…e_dispatch` (JuliaLang#58011) Matches `@time` `@profile` etc. (cherry picked from commit 1117df6)
…uliaLang#58056) Also a couple builtins had the wrong function name in their error messages. fix JuliaLang#58013 (cherry picked from commit 90eb96f)
Also changed the check to compare against the tuple argument, instead of against the method static parameter for the tuple length. Should be better when the length isn't known at compile time. Fixes JuliaLang#58085 (cherry picked from commit b265dba)
This reverts commit f15d417.
…s from packages succeed. TODO: remove this once alpha/beta is released # Conflicts: # VERSION
Prevent transparent huge pages (THP) overallocating pysical memory. Co-authored-by: Adnan Alhomssi <[email protected]>
Prepend `[signal (X) ]thread (Y) ` to each backtrace line that is displayed. Co-authored-by: Diogo Netto <[email protected]>
Also show the signal number when we have it.
DelveCI
force-pushed
the
v1.12.0-DEV+RAI
branch
from
f3abd65 to
3be0e5d
Compare
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