JuliaLang / julia / #37976

77%

Build Type

push

local

Committed by web-flow

Commit Message

Compiler.jl: use `Base.[all|any]` instead of `Compiler`'s own versions (#56851)

The current `Compiler` defines its own versions of `all` and `any`,
which are separate generic functions from `Base.[all|any]`:
https://github.com/JuliaLang/julia/blob/<a class=hub.com/JuliaLang/julia/commit/2ed1a411e0a080f3107e75bb65105a15a0533a90">2ed1a411e/Compiler/src/utilities.jl#L15-L32

On the other hand, at the point where `Base.Compiler` is bootstrapped,
only a subset of `Base.[all|any]` are defined, specifically those
related to `Tuple`:

https://github.com/JuliaLang/julia/blob/2ed1a411e0a080f3107e75bb65105a15a0533a90/base/tuple.jl#L657-L668.
Consequently, in the type inference world, functions like
`Base.all(::Generator)` are unavailable. If `Base.Compiler` attempts to
perform operations such as `::BitSet ⊆ ::BitSet` (which internally uses
`Base.[all|any]`), a world age error occurs (while `Compiler.[all|any]`
can handle these operations, `::BitSet ⊆ ::BitSet` uses
`Base.[all|any]`, leading to this issue)

To resolve this problem, this commit removes the custom `Compiler`
versions of `[all|any]` and switches to using the Base versions.

One concern is that the previous `Compiler` versions of `[all|any]`
utilized `@nospecialize`. That annotation was introduced a long time ago
to prevent over-specialization, but it is questionable whether it is
still effective with the current compiler implementation. The results of
the nanosoldier benchmarks conducted below also seem to confirm that
the `@nospecialize`s are no longer necessary for those functions.

Run Details

49 of 50 new or added lines in 1 file covered. (98.0%)

28 existing lines in 4 files now uncovered.

51438 of 60066 relevant lines covered (85.64%)

11943077.13 hits per line