So that it can be tested in isolation easier.

This is an alternative to JuliaLang#53642

The `dom_edges()` for an exit block in the CFG are empty when computing
the PostDomTree so the loop below this may not actually run. In that
case, the right semidominator is the ancestor from the DFSTree, which is
the "virtual" -1 block.

This resolves half of the issue in
JuliaLang#53613:
```julia
julia> let code = Any[
               # block 1
               GotoIfNot(Argument(2), 3),
               # block 2
               ReturnNode(Argument(3)),
               # block 3 (we should visit this block)
               Expr(:call, throw, "potential throw"),
               ReturnNode(), # unreachable
           ]
           ir = make_ircode(code; slottypes=Any[Any,Bool,Bool])
           visited = BitSet()
           @test !Core.Compiler.visit_conditional_successors(CC.LazyPostDomtree(ir), ir, #=bb=#1) do succ::Int
               push!(visited, succ)
               return false
           end
           @test 2 ∈ visited
           @test 3 ∈ visited
       end
Test Passed
```

This needs some tests (esp. since I don't think we have any DomTree
tests at all right now), but otherwise should be good to go.

…iaLang#53642)

This commit fixes the first problem that was found while digging into
JuliaLang#53613. It turns out that the post-domtree constructed
from regular `IRCode` doesn't work for visiting conditional successors
for post-opt analysis in cases like:
```julia
julia> let code = Any[
               # block 1
               GotoIfNot(Argument(2), 3),
               # block 2
               ReturnNode(Argument(3)),
               # block 3 (we should visit this block)
               Expr(:call, throw, "potential throw"),
               ReturnNode(), # unreachable
           ]
           ir = make_ircode(code; slottypes=Any[Any,Bool,Bool])
           visited = BitSet()
           @test !Core.Compiler.visit_conditional_successors(CC.LazyPostDomtree(ir), ir, #=bb=#1) do succ::Int
               push!(visited, succ)
               return false
           end
           @test 2 ∉ visited
           @test 3 ∈ visited
       end
Test Failed at REPL[14]:16
  Expression: 2 ∉ visited
   Evaluated: 2 ∉ BitSet([2])
```

This might mean that we need to fix on the `postdominates` end, but for
now, this commit tries to get around it by using the augmented post
domtree in `visit_conditional_successors`. Since the augmented post
domtree is enforced to have a single return, we can keep using the
current `postdominates` to fix the issue.

However, this commit isn't enough to fix the NeuralNetworkReachability
segfault as reported in JuliaLang#53613, and we need to tackle the second issue
reported there too
(JuliaLang#53613 (comment)).

When multiple threads concurrently attempt to compile the same method,
`--trace-compile` could emit duplicate `precompile` statements. This
small tweak eliminates one source of these duplicates.

This test appears to be failing intermittently on aarch64 darwin, so
stop suppressing any errors that might be happening.

This makes it easier to fully-statically-type Base and init methods.
The changes are from gb/small-image2.

This passes slightly more information into this function (the full
`inst` rather than just the `stmt`) in order to allow external absint to
access additional fields (the flags and the info) if necessary to make
concrete evaluation decisions. It also splits out the actual concrete
evaluation from the part that just maps the `inst` to a CodeInstance.

We currently have
```
julia> @sprintf("%07f", -Inf)
"-000Inf"

julia> @sprintf("%07f", NaN)
"0000NaN"
```

With this PR
```
julia> @sprintf("%07f", -Inf)
"   -Inf"

julia> @sprintf("%07f", NaN)
"    NaN"
```
which is the same as Julia 1.5.4 and agrees with the C standard.

Does what it says. Doc-changes only.

Recent motivating example: FluxML/Flux.jl#2399

- ~~simplifies the signature of `transform_result_for_cache`~~
- ~~make `jl_uncompress_ir` take `MethodInstance` instead of
`CodeInstance`
  and simplifies the inlining algorithm~~
- renames of `codeinst::CodeInstace` objects
- removal of dead code

…3687)

This PR switches our code generation for `Ptr{T}` from `i64` to an
actual LLVM pointer type (`ptr` when using opaque pointers, an untyped
`i8*` otherwise). The main motivation is to simplify `llvmcall` usage
(doing away with the `inttoptr`/`ptrtoint` conversions), and also make
it possible to simply use `ccall` to call intrinsics with `Ptr`-valued
arguments (where we currently always need `llvmcall` for converting to
an actual pointer).

Changing codegen like this is a breaking change for `llvmcall` users,
but I've added backwards compatibility and a deprecation warning.

Before:

```llvm
julia> @code_llvm pointer([])
define i64 @julia_pointer_1542(ptr noundef nonnull align 8 dereferenceable(24) %"x::Array") #0 {
top:
; ┌ @ pointer.jl:65 within `cconvert`
   %0 = load ptr, ptr %"x::Array", align 8
; └
; ┌ @ pointer.jl:90 within `unsafe_convert`
; │┌ @ pointer.jl:30 within `convert`
    %bitcast_coercion = ptrtoint ptr %0 to i64
    ret i64 %bitcast_coercion
; └└
}
```

After:

```llvm
julia> @code_llvm pointer([])
define ptr @julia_pointer_3880(ptr noundef nonnull align 8 dereferenceable(24) %"x::Array") #0 {
top:
; ┌ @ pointer.jl:65 within `cconvert`
   %0 = load ptr, ptr %"x::Array", align 8
; └
; ┌ @ pointer.jl:90 within `unsafe_convert`
; │┌ @ pointer.jl:30 within `convert`
    ret ptr %0
; └└
}
```

This also simplifies "real code", e.g., when `ccall` converts an Array
to a pointer, resulting in some more optimization opportunities.

~~Apparently somewhere in codegen inside `emit_codeinst`some piece of
code is relying on the implicit try catch gcstack restoring. I haven't
got the analyzer working on that file yet (it has hundreds of issues and
it doesn't like C++ code that much + the file is tens of thousands of
lines after includes so it struggles).~~

This fixes the compileall segfault in apple-aarch64 ci.
JuliaLang#53811

These flisp accessor functions make use of the `jl_filename` and
`jl_lineno` globals. I was looking at removing these globals for
unrelated reasons, when I saw that one of the primary uses was in these
flisp accessor, which appear entirely unnecessary. They are only used to
provide a default for an error message, but the place that puts the
error message into a list to return to julia does actually already have
access to this information, so there's no need for these to look at the
globals.

While we're at it, also add a test for this code path, which was
otherwise unexercised in our test suite.

I don't like `jl_filename`/`jl_lineno`. They are weird internal state,
and they are also not thread safe, so if different threads are evaling
different things at the same time, line numbers can get confused.

This PR changes the core function `jl_toplevel_eval_flex` to keep track
of its current file/line context on the stack, so at least there is no
confusion within one call to this function.

With this PR and JuliaLang#53797, the global `jl_filename`/`jl_lineno` are used
for three purposes:

1. To initialize the filename/lineno used by lowering from `Core.eval`.
2. To give binding deprecation warnings.
3. For `jl_critical_error`.
4. By humans in the debugger.

I think 3 and 4 are fine, they are exceptional cases. Case 2, I think
could be changed to plumb through locations explicitly,
 but it's a bit annoying, so I didn't tackle it here.
Case 1, I think can probably just be changed to consistently initialize,
and if you want a proper line number, you need to put it in there
explicitly.
However, I didn't change that in this PR, because I think it could be
slightly
 breaking, so should be pkgeval'd.

…kage (JuliaLang#53789)

Fixes JuliaLang#53788

…g#53805)

Currently it's a bit excessive in the `Pkg.test` precompile job

![Screenshot 2024-03-20 at 12 04
03 PM](https://github.com/JuliaLang/julia/assets/1694067/7600f0b8-6e4b-43b2-9c42-c8d5d16b8d57)


This PR
```
Precompiling project for configuration --code-coverage=none --color=yes --check-bounds=yes --warn-overwrite=yes --depwarn=yes --inline=yes --startup-file=no --track-allocation=none...
    354.9 ms  ✓ RFFT
  1 dependency successfully precompiled in 1 seconds. 38 already precompiled.
```

Pkg could also just set the non-default flags to minimize the list.

…aLang#53808)

Reverts JuliaLang#53778 which appears to have introduced a windows
failure

See
JuliaLang#53778 (comment)

Fixes JuliaDebug/Cthulhu.jl#541 by picking up
libuv/libuv@3ecce91.

…Lang#53778)" (JuliaLang#53820)

This makes it easier to fully-statically-type Base and init methods. The
changes are from gb/small-image2.

…53821)

Currently, in order to give the nice prompt for missing packages, we
look for any `using`/`import` statements in the AST before evaluation.
However, this misses any `using` statements introduced by macros:

```
julia> using Pkg

julia> using BenchmarkTools
 │ Package BenchmarkTools not found, but a package named BenchmarkTools is
 │ available from a registry.
 │ Install package?
 │   (@v1.11) pkg> add BenchmarkTools
 └ (y/n/o) [y]: n
ERROR: ArgumentError: Package BenchmarkTools not found in current path.
- Run `import Pkg; Pkg.add("BenchmarkTools")` to install the BenchmarkTools package.
Stacktrace:
 [1] macro expansion
   @ Base ./loading.jl:1781 [inlined]
 [2] macro expansion
   @ Base ./lock.jl:267 [inlined]
 [3] __require(into::Module, mod::Symbol)
   @ Base ./loading.jl:1762
 [4] #invoke_in_world#3
   @ Base ./essentials.jl:963 [inlined]
 [5] invoke_in_world
   @ Base ./essentials.jl:960 [inlined]
 [6] require(into::Module, mod::Symbol)
   @ Base ./loading.jl:1755

julia> macro foo()
       :(using BenchmarkTools)
       end
@foo (macro with 1 method)

julia> @foo
ERROR: ArgumentError: Package BenchmarkTools not found in current path.
- Run `import Pkg; Pkg.add("BenchmarkTools")` to install the BenchmarkTools package.
Stacktrace:
 [1] macro expansion
   @ Base ./loading.jl:1781 [inlined]
 [2] macro expansion
   @ Base ./lock.jl:267 [inlined]
 [3] __require(into::Module, mod::Symbol)
   @ Base ./loading.jl:1762
 [4] #invoke_in_world#3
   @ Base ./essentials.jl:963 [inlined]
 [5] invoke_in_world
   @ Base ./essentials.jl:960 [inlined]
 [6] require(into::Module, mod::Symbol)
   @ Base ./loading.jl:1755
 [7] top-level scope
   @ REPL[4]:1
```

Generally, it doesn't matter, but embedded DSLs may want to do this kind
of thing, so we might as well try to support it.

Co-authored-by: Lilith Orion Hafner <lilithhafner@gmail.com>
Co-authored-by: Steven G. Johnson <stevenj@mit.edu>

…3653)

This is similar to workspaces in cargo where multiple projects share a
manifest https://doc.rust-lang.org/book/ch14-03-cargo-workspaces.html
and upon resolving the dependencies and compat of all projects in the
workspace is adhered to.

The idea is to use this for e.g. test, doc environments where you want
to "overlay" a dependency graph on top of a base one.

The code change in Base adds support for the code loading and precompilation part of this, those changes are:

- Finding the manifest from any active project in the workspace
- Merge preferences among projects in a workspace.
- Allowing one to pass `manifest=true` to `precompilepkgs` to compile every package in the manifest.
- The effect of giving no packages to `precompilepkgs` was changed from compiling all packages in the manifest to only those in the active project (which is equivalent in case of no workspace being used but different when it is used).

A common idiom used throughout the codebase is to get a pointer to
thread-local-state through `jl_current_task->ptls`.

Create a phantom task for GC threads so that we can make use of this
idiom when running in the GC threads as well.

Idea originally suggested by @vchuravy, bugs are mine.

Since currently `Xoshiro` is a default random number generator I propose
to add it to the docstring of `Random` module.

MPFR 4.2.1 was released on 22 August 2023.
It contains bugfixes.

Released 1st March 2024:
https://github.com/nghttp2/nghttp2/releases/tag/v1.60.0

Released Apr 23, 2023:
https://github.com/NixOS/patchelf/releases/tag/0.18.0

Released on 16 February 2024. Among the changes is support for Unicode
15.0.0

Released January 22, 2024

…uliaLang#53850)

JuliaInterpreter tries to do some very questionable pre-lowering
introspection to find line numbers, but doesn't properly handle hygienic
scope. That should be fixed, but as I was about to put in a hack there,
I figured we might as well not bother re-wrapping bare LineNumberNodes
in hygienic scopes. They just get discarded again immediately anyway. No
functional change in that this is semantically equivalent to what we had
before, just with a slightly more compact lowering result and additional
JuliaInterpreter test passing.

…#53846)

Stdlib: Pkg
URL: https://github.com/JuliaLang/Pkg.jl.git
Stdlib branch: master
Julia branch: master
Old commit: 6859d6857
New commit: 162634c56
Julia version: 1.12.0-DEV
Pkg version: 1.12.0
Bump invoked by: @KristofferC
Powered by:
[BumpStdlibs.jl](https://github.com/JuliaLang/BumpStdlibs.jl)

Diff:
JuliaLang/Pkg.jl@6859d68...162634c

```
$ git log --oneline 6859d6857..162634c56
162634c56 Add workspace feature (JuliaLang#3841)
a4ec712eb Remove outdated UUID instructions (JuliaLang#3855)
9c6356fa9 collect e.g. weak deps from project even if it is not a package (JuliaLang#3852)
```

Co-authored-by: Dilum Aluthge <dilum@aluthge.com>

According to the release notes, three breaking (ABI) changes are handled
here:

- `GIT_CONFIG_LEVEL_WORKTREE` constant (and modification to value of
`GIT_CONFIG_LEVEL_APP`)
- `git_config_entry` structure
- `git_push_options` structure

https://github.com/libgit2/libgit2/releases/tag/v1.8.0

…ng single package (JuliaLang#53865)

Followup to JuliaLang#53653
Separate from JuliaLang#53862 because this one is just broken on master

Without this if you precompile a project with a single dep it thought
the user was calling `precompile Dep` or `using Dep` so went into live
print mode, which is confusing.

Signed-off-by: crazeteam <lilujing@outlook.com>

Following JuliaPackaging/Yggdrasil#8355

The behavior was changed and the CLI doc was removed
in JuliaLang#41638, though we current still allow users to
selectively use the `@fastmath` macro.
This adds back the CLI docs and makes a minor
clarification about behavior.

Co-authored-by: Matt Bauman <mbauman@juliahub.com>

This test fails intermittently on win32. Let's try to print some more
info in that case to see if we can find out anything.

This stmt type doesn't usually get introduced until IR conversion, but
we do allow it in inference (to allow it to be emitted by packages like
Diffractor). However, we didn't have a test for it, so the code path
grew a bug. Fix that and also allow this as a frontend form, so it can
be tested without resorting to generated functions.

)

fixes JuliaLang#52120

Following JuliaPackaging/Yggdrasil#8352

…aLang#53878)

This is an alternative to JuliaLang#53852. I don't think it's semantically legal
to put optimized source into the :source field of a method, but it
should be fine to just look it up from the CodeInstance. That said, this
is a bit of an unusual configuration. In particular it wasn't even
reachable with the surface APIs, which assumed that inferred IR was
always supposed to be compiled.

…PhiNodes (JuliaLang#53876)

There's two related, but distinct, issues here:
1. We were not using `tmerge` for merging SSA results inside loops,
which could cause infinite looping. In the absence of PhiNodes, things
usually have to go through a slot to be able to make the round trip,
which would usually put a PhiNode on the path, but it's possible there
may be other ways to smuggle things around (e.g. through exception
handling).

2. We were not properly accounting for the fact that PhiNode uses do not
need to be linearly ordered in the same BB, so we were getting the type
of the testcase here incorrect by failing to re-schedule the PhiNode.

The first of these shows up in the Diffractor test suite, the second was
found by writing the test case.

…liaLang#53879)

There was an odd phrase "in particular if `MersenneTwister` is used" in
the reproducibility discussion, which made it seem like the discussion
was specific to `MersenneTwister` (which we don't even use by default
anymore). I just deleted this clause.

…ng#53883)

…3877)

Incoming IR very rarely contains PhiNodes, but we do allow it to make
things easier on downstream packages like Diffractor that want to
generate the same code structures in both typed and untyped mode.
However, this does of course mean that once inference is finished, any
PhiNodes in the original source must be adjusted to maintain IRCode
invariants. One particular important invariant here is that the edges
list in a PhiNode must match the predecessor list, so in particular if a
predecessor becomes unreachable during inference, we must filter that
edge before passing it on to the optimizer.

---------

Co-authored-by: Shuhei Kadowaki <aviatesk@gmail.com>

…Lang#53873)

It is unclear what `Julia` exactly means in this docstring, but the two
occurences of the word have different formatting. The guidelines say
> in docstrings refer to the language as "Julia" and the executable as
"`julia`".

Given that we are not talking about the executable here, I removed the
backticks.

…e previous GC state (JuliaLang#53868)

I have not succeed in writing a test for this, but this was found on a
CI hang together with @Keno and @vtjnash.

In essence if we hit a safepoint while GC_SAFE things can go wrong
<img width="748" alt="image"
src="https://github.com/JuliaLang/julia/assets/28694980/7d8170ee-11ab-43de-9bb1-9219aa5a2d80">

This addresses the previous limitation to `Base.literal_pow`, where it
would only apply to literals between $\pm2\^{61}$ (or 29).

I will add a test case for this later.

xref:
https://github.com/JuliaDiff/Diffractor.jl/actions/runs/8476871477/job/23226991456

Not sure why this typo didn't mess up the CI, but it looks like a clear
problem, let's correct it. I'd appreciate any idea on how to exercise
this change.

- fixes JuliaDebug/JuliaInterpreter.jl#621

Should fix JuliaLang#53399. I think this is the correct fix.
Makes it so you can build Julia with `USE_BINARYBUILDER=0`.

Fixes JuliaLang#53885

Not the first time MacOS serving tempdir via a symlink has caused
obscure issues..

These commits add initial support of OpenBSD in julia.

It isn't strictly enough to make julia runable on OpenBSD (see JuliaLang#53632),
but it covers the larger part.

---------

Co-authored-by: Max Horn <max@quendi.de>
Co-authored-by: Oscar Smith <oscardssmith@gmail.com>

Fixes JuliaLang#48820

I think this is the proper fix, and there might be a configure option to
curl or nghttp2 to set it, but I haven't been found it. So we'll do it
that way.

JuliaLang#53899)

This is not needed after JuliaLang#53355.

This upstream patch needs to be removed because in latest curl, it's
already applied. This currently prevents a build from source. (And I am
wondering why that was not caught?)

…iaLang#53901)

Currently,
```julia
julia> C = CartesianIndices((1:2, 1:2))
CartesianIndices((1:2, 1:2))

julia> copy(C)
2×2 Matrix{CartesianIndex{2}}:
 CartesianIndex(1, 1)  CartesianIndex(1, 2)
 CartesianIndex(2, 1)  CartesianIndex(2, 2)
```
However, seeing that a `CartesianIndices` is equivalent to an n-D range,
there doesn't seem to be a need to materialize the result. This PR also
ensures that `copy(C)` returns the same type as `C`.

After this PR:
```julia
julia> C = CartesianIndices((1:2, 1:2))
CartesianIndices((1:2, 1:2))

julia> copy(C)
CartesianIndices((1:2, 1:2))
```
Also, a similar change for `LinearIndices` is added.

This PR adds a utility function `isrelocatable(pkg)` that can be used to
check if `pkg` is already precompiled and if the associated cachefile is
relocatable.

The reason to implicitly perform the `isprecompiled` check is that the
exact same computation needs to be done to find the right `.ji`.

A `pkg` is said to be relocatable if
1. all `include()` paths are relocatable (they start with `@depot`),
2. all `include_dependency()` paths are relocatable (they start with
`@depot` and `track_content=true` was used to include them).

Per
JuliaCI/julia-buildkite#224 (comment),
the path needs to be updated so that `llvm-size` can find `libLLVM.dll`.

Before JuliaLang#52415 we could do multiple rounds of inlining on
IR that had already been inlined, but this was no longer possible. By
removing the assertion that was introduced in JuliaLang#52415,
this commit makes it possible to do multi-inlining once more. Note that
to fully solve this, though, we need to enhance `ir_inline_linetable!`
so it can add new linetables to an inner linetable that's already been
inlined. This commit notes that enhancement as something we need to do
later, leaving it with a TODO comment.

Happy April fools day! 🪿 Let's celebrate with a very important PR 🩵

This PR updates the REPL completion list with all the fun new emoji from
unicode 15.1! This makes Julia ready for the up-and-coming programmzers
who want the latest trends in emoji coding! 🫶🫶 Fresh new emoji for fresh
new ideas! 🫶🫶

Some of the new emoji include:
- `\:biting_lip:` 🫦 for when the IO code gets *spicy*
- `\:beans:` 🫘 beanssss
- `\:mirror_ball:` 🪩 for parties!
- `\:playground_slide:` 🛝 for really fun code :)

Thanks to @oxinabox for the future-proof script!

Enjoy!!

…g#52415)" (JuliaLang#53781)

- fix up added documents: eb05b4f
- ~~set up a specific type to capture the 3-set data of `codelocs`:
6afde4b~~ (moved to a separate PR)

…files (JuliaLang#53905)

Fixes
JuliaLang#53859 (comment),
which was actually fixed before in
JuliaLang#52346, but
JuliaLang#52750 undid that fix.

This PR does not directly address JuliaLang#53859, because I can not reproduce it
atm.

---

The `@depot` resolution logic for `include()` files is adjusted as
follows:

1. (new behavior) If the cache is not relocatable because of an absolute
path, we ignore that path for the depot search. Recompilation will be
triggered by `stale_cachefile()` if that absolute path does not exist.
Previously this caused any `@depot` tags to be not resolved and so
trigger recompilation.
2. (new behavior) If we can't find a depot for a relocatable path, we
still replace it with the depot we found from other files. Recompilation
will be triggered by `stale_cachefile()` because the resolved path does
not exist.
3. (this behavior is kept) We require that relocatable paths all resolve
to the same depot.
4. (new behavior) We no longer use the first matching depot for
replacement, but instead we explicitly check that all resolve to the
same depot. This has two reasons:
- We want to scan all source files anyways in order to provide logs for
1. and 2. above, so the check is free.
- It is possible that a depot might be missing source files. Assume that
we have two depots on `DEPOT_PATH`, `depot_complete` and
`depot_incomplete`.
If `DEPOT_PATH=["depot_complete","depot_incomplete"]` then no
recompilation shall happen, because `depot_complete` will be picked.
If `DEPOT_PATH=["depot_incomplete","depot_complete"]` we trigger
recompilation and hopefully a meaningful error about missing files is
thrown. If we were to just select the first depot we find, then whether
recompilation happens would depend on whether the first relocatable file
resolves to `depot_complete` or `depot_incomplete`.

…aLang#53626)

The `failure_expanded` attribute of a test result is an _array_ of
objects, not a single object.

I believe this is to support the possibility of multiple failure reasons
in a single test case, although I'm not sure if that's used anywhere.

https://buildkite.com/docs/test-analytics/importing-json#json-test-results-data-reference-test-result-objects

It seemed worth documenting that display of `nothing` is suppressed by
the REPL (and similar environments, e.g. IJulia).

- remove unnecessary `Core.` accessors to `DebugInfo` within
`Core.Compiler`
- improve the type of `DebugInfoStream`'s `edges` field

Reflection version of JuliaLang#53878.

---------

Co-authored-by: Shuhei Kadowaki <40514306+aviatesk@users.noreply.github.com>
Co-authored-by: Shuhei Kadowaki <aviatesk@gmail.com>

Signed-off-by: crazehang <zhangrenzhong@outlook.com>

The expressions `a^x` and `@fastmath a^x` are now producing equivalent
results (apart from floating point accuracy) in the case of literal
integer `x`.
The logic in the `fastmath` macro, trying to mimic the behaviour of the
compiler is fixed.

Fixes JuliaLang#53817

---------

Co-authored-by: Oscar Smith <oscardssmith@gmail.com>

…PACK (JuliaLang#53578)

…w` case. (JuliaLang#53713)

The macros `@which`, `@edit`, `@functionloc`, `@less` from `InteractiveUtils`, if
applied to the case of literal powers, like `a^12` or `2^-1` used to direct the
user to function `^`, while the compiler generates code for `Base.literal_pow`.

Now the user is shown the code the compiler generates.

Fixes JuliaLang#53691
Fixes JuliaLang#43337
Fixes JuliaLang#21014

Co-authored-by: Matt Bauman <mbauman@juliahub.com>

…`Matrix` (JuliaLang#53912)

With this, we may convert a structured matrix to `Matrix` even if its
`eltype` doesn't support `zero(T)`, as long as we may index into the
matrix and the elements have `zero` defined for themselves. This makes
the following work:
```julia
julia> D = Diagonal(fill(Diagonal([1,3]), 2))
2×2 Diagonal{Diagonal{Int64, Vector{Int64}}, Vector{Diagonal{Int64, Vector{Int64}}}}:
 [1 0; 0 3]      ⋅     
     ⋅       [1 0; 0 3]

julia> Matrix{eltype(D)}(D)
2×2 Matrix{Diagonal{Int64, Vector{Int64}}}:
 [1 0; 0 3]  [0 0; 0 0]
 [0 0; 0 0]  [1 0; 0 3]
```
We also may materialize partly initialized matrices:
```julia
julia> D = Diagonal(Vector{BigInt}(undef, 2))
2×2 Diagonal{BigInt, Vector{BigInt}}:
 #undef    ⋅
   ⋅     #undef

julia> Matrix{eltype(D)}(D)
2×2 Matrix{BigInt}:
 #undef    0
   0     #undef
```

The performance seems identical for numeric matrices.

Since `zero` exists for a `TwicePrecision` type, it makes sense for a
method to exist for an instance as well.
Fixes JuliaLang#52713, which was a regression from v1.9.1. After this, the
following may be displayed without errors:
```julia
julia> r = 1.0*(1:5) .+ im
1.0 + 1.0im:Base.TwicePrecision{Float64}(1.0, 0.0):5.0 + 1.0im
```
However, in this case, the step is a `Base.TwicePrecision`, which seems
to be an implementation detail that's leaking out, although addressing
this may be a separate PR.

[skip ci]

…3944)

JuliaLang#53875 allowed
`:throw_undef_if_not` as a frontend form.

However, the `UndefVarError` being tested is thrown because the first
argument is resolved to a global ref:

```julia
julia> @eval function has_tuin()
           $(Expr(:throw_undef_if_not, :x, false))
       end
has_tuin (generic function with 1 method)

julia> @code_lowered has_tuin() # master
CodeInfo(
1 ─ %1 = $(Expr(:throw_undef_if_not, :(Main.x), false))
└──      return %1
)

julia> @code_lowered has_tuin() # this pr
CodeInfo(
1 ─ %1 = $(Expr(:throw_undef_if_not, :x, false))
└──      return %1
)
```

This change skips this global ref resolution for the first argument and
fixes a typo which would throw an error in case of non-const second
argument.

…53918)

This pull request changes `failure_expanded` from `Dict{String, Any}` to
`Vector{Dict{String, Any}}` to fix a JSON schema issue in the [Bootleg
JSON
writer](https://github.com/JuliaLang/julia/blob/7eb5cb89fb938a1dc67efa3861b25562767a7bbe/test/buildkitetestjson.jl#L13)
🏴‍☠️ which is responsible for producing JSON test results for [Buildkite
Test Analytics](https://buildkite.com/test-analytics).

The [`failure_expanded` attribute of a test
result](https://buildkite.com/docs/test-analytics/importing-json#json-test-results-data-reference-test-result-objects)
is a JSON array of objects, rather than a single object. I believe this
is to support the possibility of multiple failure reasons in a single
test case, although I'm not sure if that's used anywhere.

I believe the associated uploads (batches of up to 5,000 results) are
currently getting a successful HTTP 202 Accepted response, but the
response body will contain an error for each test case that had a
non-array `failure_expanded`, meaning those test cases will be dropped:

```http
HTTP/1.1 202 Accepted
Content-Type: application/json; charset=utf-8
Date: Tue, 12 Mar 2024 13:11:46 GMT
X-Request-Id: a35322f6-9990-4b8e-8895-d62bd6e10935

{
  "id": "55ac3b92-…",
  "run_id": "bfa6de98-…",
  "queued": 4998,
  "skipped": 2,
  "errors": [
    "Validation failed: Failure expanded must be an Array",
    "Validation failed: Failure expanded must be an Array"
  ],
  "run_url": "http://buildkite.com/…"
}
```

Rather than make the Buildkite API more permissive, I figured I'd come
and fix it upstream, and write my first few tiny lines of Julia while
I'm at it 😁

I've verified that the adjusted JSON output it accepted by our ingestion
system.

---

For verification, I added an error to an arbitrarily selected test
(because [workers don't return information about passing/broken tests,
only errors or
failure](https://github.com/JuliaLang/julia/blob/7eb5cb89fb938a1dc67efa3861b25562767a7bbe/test/runtests.jl#L363-L365)):

```patch
diff --git a/test/char.jl b/test/char.jl
index 1d3579013a..582423e8a3 100644
--- a/test/char.jl
+++ b/test/char.jl
@@ -1,6 +1,7 @@
 # This file is a part of Julia. License is MIT: https://julialang.org/license

 @testset "basic properties" begin
+    @test throw(ErrorException("testing Buildkite JSON"))
     @test typemax(Char) == reinterpret(Char, typemax(UInt32))
     @test typemin(Char) == Char(0)
     @test typemax(Char) == reinterpret(Char, 0xffffffff)
```

… and then `CI=true ./julia test/runtests.jl char` which produces
`test/results_1.json`.

Before:

```json
[
  {
    "file_name": "/Users/pda/code/julia/test/char.jl",
    "history": {
      "duration": 2.123565912246704,
      "start_at": 1.710245465232599e9,
      "end_at": 1.710245467356165e9
    },
    "name": "test_error: throw(ErrorException(\"testing Buildkite JSON\"))",
    "location": "/Users/pda/code/julia/test/char.jl:4",
    "failure_reason": "Exception (unexpectedly) thrown during test",
    "scope": "/Overall/char",
    "failure_expanded": {
      "backtrace": [
        " [1] top-level scope",
        "   @ ~/code/julia/test/char.jl:4",
        " [2] macro expansion",
        "   @ ~/code/julia/usr/share/julia/stdlib/v1.12/Test/src/Test.jl:164 [inlined]",
        " [3] macro expansion",
        "   @ ~/code/julia/test/char.jl:4 [inlined]",
        " [4] macro expansion",
        "   @ ~/code/julia/usr/share/julia/stdlib/v1.12/Test/src/Test.jl:164 [inlined]",
        " [5] macro expansion",
        "   @ ~/code/julia/test/char.jl:4 [inlined]"
      ],
      "expanded": [
        "testing Buildkite JSON"
      ]
    },
    "id": "e9272117-d5f5-f542-039b-cfd3d2e8f33a",
    "result": "failed"
  }
]
```

After:

```json
[
  {
    "file_name": "/Users/pda/code/julia/test/char.jl",
    "history": {
      "duration": 2.123565912246704,
      "start_at": 1.710245465232599e9,
      "end_at": 1.710245467356165e9
    },
    "name": "test_error: throw(ErrorException(\"testing Buildkite JSON\"))",
    "location": "/Users/pda/code/julia/test/char.jl:4",
    "failure_reason": "Exception (unexpectedly) thrown during test",
    "scope": "/Overall/char",
    "failure_expanded": [
      {
        "backtrace": [
          " [1] top-level scope",
          "   @ ~/code/julia/test/char.jl:4",
          " [2] macro expansion",
          "   @ ~/code/julia/usr/share/julia/stdlib/v1.12/Test/src/Test.jl:164 [inlined]",
          " [3] macro expansion",
          "   @ ~/code/julia/test/char.jl:4 [inlined]",
          " [4] macro expansion",
          "   @ ~/code/julia/usr/share/julia/stdlib/v1.12/Test/src/Test.jl:164 [inlined]",
          " [5] macro expansion",
          "   @ ~/code/julia/test/char.jl:4 [inlined]"
        ],
        "expanded": [
          "testing Buildkite JSON"
        ]
      }
    ],
    "id": "e9272117-d5f5-f542-039b-cfd3d2e8f33a",
    "result": "failed"
  }
]
```

Diff:

```patch
--- buildkite-before.json	2024-03-12 23:08:26
+++ buildkite-after.json	2024-03-12 23:07:58
@@ -10,23 +10,25 @@
     "location": "/Users/pda/code/julia/test/char.jl:4",
     "failure_reason": "Exception (unexpectedly) thrown during test",
     "scope": "/Overall/char",
-    "failure_expanded": {
-      "backtrace": [
-        " [1] top-level scope",
-        "   @ ~/code/julia/test/char.jl:4",
-        " [2] macro expansion",
-        "   @ ~/code/julia/usr/share/julia/stdlib/v1.12/Test/src/Test.jl:164 [inlined]",
-        " [3] macro expansion",
-        "   @ ~/code/julia/test/char.jl:4 [inlined]",
-        " [4] macro expansion",
-        "   @ ~/code/julia/usr/share/julia/stdlib/v1.12/Test/src/Test.jl:164 [inlined]",
-        " [5] macro expansion",
-        "   @ ~/code/julia/test/char.jl:4 [inlined]"
-      ],
-      "expanded": [
-        "testing Buildkite JSON"
-      ]
-    },
+    "failure_expanded": [
+      {
+        "backtrace": [
+          " [1] top-level scope",
+          "   @ ~/code/julia/test/char.jl:4",
+          " [2] macro expansion",
+          "   @ ~/code/julia/usr/share/julia/stdlib/v1.12/Test/src/Test.jl:164 [inlined]",
+          " [3] macro expansion",
+          "   @ ~/code/julia/test/char.jl:4 [inlined]",
+          " [4] macro expansion",
+          "   @ ~/code/julia/usr/share/julia/stdlib/v1.12/Test/src/Test.jl:164 [inlined]",
+          " [5] macro expansion",
+          "   @ ~/code/julia/test/char.jl:4 [inlined]"
+        ],
+        "expanded": [
+          "testing Buildkite JSON"
+        ]
+      }
+    ],
     "id": "e9272117-d5f5-f542-039b-cfd3d2e8f33a",
     "result": "failed"
   }
```

…ang#53826)

I checked and updated the three related files to make sure command-line
documentations are the same in all of them.

Previously mentioned in
JuliaLang#52645 (comment)

---------

Co-authored-by: Matt Bauman <mbauman@gmail.com>

The methods `float`, `cis`, `sincos` and `sincosd` are defined for
matrices, so it makes sense for these to be defined for a
`UniformScaling` as well.
E.g.:
```julia
julia> float(2I)
UniformScaling{Float64}
2.0*I

julia> sincos(2I)
(UniformScaling{Float64}(0.9092974268256817), UniformScaling{Float64}(-0.4161468365471424))
```

…ce` (JuliaLang#53952)

…aLang#53939)

also soft deprecate the `path` entry in project file in favour of using
`entryfile` instead

Fixes the Julia Base part of JuliaLang#53937

…53961)

This reduces dynamic dispatch and makes JET happier.
Testing on v1.11:
```julia
julia> import LinearAlgebra: checksquare

julia> using JET

julia> @report_opt checksquare(rand(2,2), rand(2,2))
═════ 4 possible errors found ═════
┌ checksquare(::Matrix{Float64}, ::Matrix{Float64}) @ LinearAlgebra /cache/build/builder-amdci4-1/julialang/julia-release-1-dot-11/usr/share/julia/stdlib/v1.11/LinearAlgebra/src/LinearAlgebra.jl:307
│┌ string(::String, ::Tuple{Int64, Int64}) @ Base ./strings/io.jl:189
││┌ print_to_string(::String, ::Tuple{Int64, Int64}) @ Base ./strings/io.jl:150
│││┌ _unsafe_take!(io::IOBuffer) @ Base ./iobuffer.jl:494
││││┌ wrap(::Type{Array}, m::MemoryRef{UInt8}, l::Int64) @ Base ./array.jl:3101
│││││ failed to optimize due to recursion: wrap(::Type{Array}, ::MemoryRef{UInt8}, ::Int64)
││││└────────────────────
│││┌ print_to_string(::String, ::Vararg{Any}) @ Base ./strings/io.jl:143
││││ runtime dispatch detected: Base._str_sizehint(%17::Any)::Int64
│││└────────────────────
│││┌ print_to_string(::String, ::Vararg{Any}) @ Base ./strings/io.jl:148
││││ runtime dispatch detected: print(%59::IOBuffer, %97::Any)::Any
│││└────────────────────
│││┌ string(::String, ::Int64, ::String, ::Tuple{Int64}, ::String, ::Int64, ::String, ::Int64, ::String) @ Base ./strings/io.jl:189
││││ failed to optimize due to recursion: string(::String, ::Int64, ::String, ::Tuple{Int64}, ::String, ::Int64, ::String, ::Int64, ::String)
│││└────────────────────

julia> function checksquare(A...) # This PR
                  sizes = Int[]
                  for a in A
                      size(a,1)==size(a,2) || throw(DimensionMismatch(lazy"matrix is not square: dimensions are $(size(a))"))
                      push!(sizes, size(a,1))
                  end
                  return sizes
              end
checksquare (generic function with 2 methods)

julia> @report_opt checksquare(rand(2,2), rand(2,2))
No errors detected

```

)

On `1.11.0-alpha2`
Old:
```julia
@benchmark Base.dec($0x1, $0, $false)
BenchmarkTools.Trial: 10000 samples with 994 evaluations.
 Range (min … max):  33.702 ns …   4.242 μs  ┊ GC (min … max):  0.00% … 97.61%
 Time  (median):     37.626 ns               ┊ GC (median):     0.00%
 Time  (mean ± σ):   45.787 ns ± 147.794 ns  ┊ GC (mean ± σ):  14.53% ±  4.47%

    ▄▅▆▇█▇▇▅▃▃▂▂▂▁    ▁▂▁▁▁             ▁▁   ▁                 ▂
  ▄▇███████████████▇▇██████▇█▆▆▄▄▃▄▅▄▆▇████████▆▅▅▇▆▅▆▄▄▅▄▄▄▁▅ █
  33.7 ns       Histogram: log(frequency) by time      67.5 ns <

 Memory estimate: 88 bytes, allocs estimate: 3.
```
New:
```julia
BenchmarkTools.Trial: 10000 samples with 995 evaluations.
 Range (min … max):  27.538 ns …   3.397 μs  ┊ GC (min … max):  0.00% … 97.86%
 Time  (median):     30.151 ns               ┊ GC (median):     0.00%
 Time  (mean ± σ):   34.547 ns ± 105.101 ns  ┊ GC (mean ± σ):  10.37% ±  3.39%

       ▁ █▆▃  ▁
  ▂▂▃▃▅█████▆████▆▄▄▃▃▃▃▃▃▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▁▂▂▂▂▂▁▂▂▂▂▂▂▂▂▂▂▂▂▂ ▃
  27.5 ns         Histogram: frequency by time         43.8 ns <

 Memory estimate: 56 bytes, allocs estimate: 2.
```


Fixes JuliaLang#53950, actually now even faster than `1.10.2`.

It doesn't look like the length is ever changed and we don't return
these `StringMemory`s so this change should be fine.

From a type-stability perspective, this restores a lot of our behavior
before JuliaLang#47903.

As it turns out, 10 of the 11 uses of `parse_int` (now called
`parse_integer`) introduced in that PR are unnecessary since the TOML
format already requires the parsed value to be within a very limited
range.

Note that this change does not actually revert any functionality (in
contrast to JuliaLang#49576)

This represents the unexported names by the fully qualified namespace,
which makes it simpler to interpret the keyword arguments. Otherwise,
for example, it's not obvious where `Forward` comes from in the `sort`
docstring.

Also, replaces some occurrences of `instance <: Algorithm` by `instance
isa Algorithm`, which is the correct relation. This is also closer to
English, which helps with readability.

---------

Co-authored-by: Lilith Orion Hafner <lilithhafner@gmail.com>