Skip to content

Conversation

nickrobinson251
Copy link
Member

@nickrobinson251 nickrobinson251 commented Jan 15, 2025

@nickrobinson251 nickrobinson251 force-pushed the v1.12.0-DEV+RAI branch 4 times, most recently from 966538b to 9da665d Compare January 29, 2025 13:01
@DelveCI DelveCI force-pushed the v1.12.0-DEV+RAI branch 7 times, most recently from 1cff7d7 to 1e6e20d Compare February 7, 2025 00:28
@DelveCI DelveCI force-pushed the v1.12.0-DEV+RAI branch 5 times, most recently from 02e0f68 to 35024c5 Compare February 18, 2025 00:28
@DelveCI DelveCI force-pushed the v1.12.0-DEV+RAI branch 4 times, most recently from fb189dc to 7e4f1cb Compare February 27, 2025 00:29
@DelveCI DelveCI force-pushed the v1.12.0-DEV+RAI branch 3 times, most recently from 7eb4dc1 to d4a2432 Compare March 9, 2025 00:27
@DelveCI DelveCI force-pushed the v1.12.0-DEV+RAI branch 5 times, most recently from f36b557 to 4abc802 Compare March 26, 2025 00:30
gbaraldi and others added 5 commits August 18, 2025 12:23
…59297)

These modifications to the MethodTable should be performed at the
"link-stage", after all user top-level code has executed. This should be
closer to the upcoming 1.13 pipeline, which will move all top-level user
code to its standard package execution context.

This also makes any user-provided functionality for type printing
available to the `TrimVerifier`.

Resolves JuliaLang#59280.
…uliaLang#59298)

Not sure why this wasn't using this before since the code is effectively
identical, but this allows:
```julia
@Assert false "$("Hello,") assertion!"
```
to be `--trim`-"compatible" (unfortunately by deleting the assertion
message...)
…lgebra (JuliaLang#59299)

We may want to move this changes to base proper.
@LilithHafner should sort functions just always specialize on the
`by`/`lt` params? It currently sometimes relies on inlining for good
performance

---------

Co-authored-by: Cody Tapscott <[email protected]>
Co-authored-by: Cody Tapscott <[email protected]>
…uliaLang#59232)

This prevents accidentally registering hooks during the sysimage build
that would persist to run-time (unlike what happens when registering
hooks while building a pkgimage)

~~Required for JuliaLang/LinearAlgebra.jl#1407
…7776)

This still sort of errored correctly anyways (after breakage added from
PR JuliaLang#56499), but that behavior should not be relied upon optimizations
not breaking it when this is providing incorrect info to the compiler.

Fix JuliaLang#57459

(cherry picked from commit a5abb6f)
lgoettgens and others added 2 commits August 21, 2025 13:29
…m)` (JuliaLang#59343)

The issue is that JET reported that in `libgfortran_version(p).major`
the first arg of `getproperty` could be `nothing`. This is already
checked in the previous line, but in a way that the compiler cannot
remember until that call. Putting it into a variable should fix that.

It would be great if this could get backported to at least 1.12 (1.10
and 1.11 would also be great), since that is where people try to use JET
for their packages, and this reduces the Base noise in the output.
The fields of `StringIndexError` are abstractly typed, so there's no
reason to specialize on a concrete type. The change seems like
it could prevent some invalidation on loading user code.

---------

Co-authored-by: Shuhei Kadowaki <[email protected]>
DilumAluthgeBot and others added 16 commits August 25, 2025 16:15
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]>
Alternative to JuliaLang#58146.

We want to compile a subset of the possible specializations of a
function. To this end, we have a number of manually written `precompile`
statements. Creating this list is, unfortunately, error-prone, and the
list is also liable to going stale. Thus we'd like to validate each
`precompile` statement in the list.

The simple answer is, of course, to actually run the `precompile`s, and
we naturally do so, but this takes time.

We would like a relatively quick way to check the validity of a
`precompile` statement.
This is a dev-loop optimization, to allow us to check "is-precompilable"
in unit tests.

We can't use `hasmethod` as it has both false positives (too loose):
```julia
julia> hasmethod(sum, (AbstractVector,))
true

julia> precompile(sum, (AbstractVector,))
false

julia> Base.isprecompilable(sum, (AbstractVector,)) # <- this PR
false
```
and also false negatives (too strict):
```julia
julia> bar(@nospecialize(x::AbstractVector{Int})) = 42
bar (generic function with 1 method)

julia> hasmethod(bar, (AbstractVector,))
false

julia> precompile(bar, (AbstractVector,))
true

julia> Base.isprecompilable(bar, (AbstractVector,)) # <- this PR
true
```
We can't use `hasmethod && isconcretetype` as it has false negatives
(too strict):
```julia
julia> has_concrete_method(f, argtypes) = all(isconcretetype, argtypes) && hasmethod(f, argtypes)
has_concrete_method (generic function with 1 method)

julia> has_concrete_method(bar, (AbstractVector,))
false

julia> has_concrete_method(convert, (Type{Int}, Int32))
false

julia> precompile(convert, (Type{Int}, Int32))
true

julia> Base.isprecompilable(convert, (Type{Int}, Int32))  # <- this PR
true
```
`Base.isprecompilable` is essentially `precompile` without the actual
compilation.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.