fix #50716.

(cherry picked from commit ebae716)

…#51782)

This fixes an assertion that might trigger if we run this pass on sysimg
modules.

(cherry picked from commit 01f6c4c)

Other changes:
* replace `:total` with the less powerful `:foldable`
* add an `<:Integer` dispatch constraint on the `rationalize` method,
closes #55872
* replace `Rational{<:Integer}` with just `Rational`, they're equal

Other issues, related to `BigFloat` precision, are still present in
irrationals.jl, to be fixed by followup PRs, including #55853.

Fixes #55874

(cherry picked from commit d60837f)

Implementing `widen` isn't a requirement any more, since #26022.

(cherry picked from commit e95860c)

Fixes #51001

(cherry picked from commit ca3713e)

…ternal name like `r_` to `r"` (#56254)

(cherry picked from commit 4236a33)

(cherry picked from commit 894296b)

… considered harmful") (#42080)

I feel we are heading up against a "`using` crisis" where any new
feature that is implemented by exporting a new name (either in Base or a
package) becomes a breaking change. This is already happening
(JuliaGPU/CUDA.jl#1097,
JuliaWeb/HTTP.jl#745) and as projects get bigger
and more names are exported, the likelihood of this rapidly increases.

The flaw in `using Foo` is fundamental in that you cannot lexically see
where a name comes from so when two packages export the same name, you
are screwed. Any code that relies on `using Foo` and then using an
exported name from `Foo` is vulnerable to another dependency exporting
the same name.
Therefore, I think we should start to strongly discourage the use of
`using Foo` and only recommend `using Foo` for ephemeral work (e.g. REPL
work).

---------

Co-authored-by: Dilum Aluthge <[email protected]>
Co-authored-by: Mason Protter <[email protected]>
Co-authored-by: Max Horn <[email protected]>
Co-authored-by: Matt Bauman <[email protected]>
Co-authored-by: Alex Arslan <[email protected]>
Co-authored-by: Ian Butterworth <[email protected]>
Co-authored-by: Neven Sajko <[email protected]>
(cherry picked from commit ee09ae7)

(cherry picked from commit 346f38b)

…56264)

- fixes #56248

(cherry picked from commit 08d11d0)

…6304)

fix #56040

(cherry picked from commit 53ffe56)

… causes deprecation warnings (#56306)

The current version of `subtypes` will throw deprecation errors even if
no one is using the deprecated bindings.

A similar bug was fixed in Aqua.jl -
https://github.com/JuliaTesting/Aqua.jl/pull/89/files

See discussion here:

- JuliaIO/ImageMagick.jl#235 (for identifying
the problem)
- simonster/Reexport.jl#42 (for pointing to
the issue in Aqua.jl)
- https://github.com/JuliaTesting/Aqua.jl/pull/89/files (for the fix in
Aqua.jl)

This adds the `isbindingresolved` test to the `subtypes` function to
avoid throwing deprecation warnings. It also adds a test to check that
this doesn't happen.

---

On the current master branch (before the fix), the added test shows:

```
WARNING: using deprecated binding InternalModule.MyOldType in OuterModule.
, use MyType instead.
Subtypes and deprecations: Test Failed at /home/dgleich/devextern/julia/usr/share/julia/stdlib/v1.12/Test/src/Test.jl:932
  Expression: isempty(stderr_content)
   Evaluated: isempty("WARNING: using deprecated binding InternalModule.MyOldType in OuterModule.\n, use MyType instead.\n")
Test Summary:             | Fail  Total  Time
Subtypes and deprecations |    1      1  2.8s
ERROR: LoadError: Some tests did not pass: 0 passed, 1 failed, 0 errored, 0 broken.
in expression starting at /home/dgleich/devextern/julia/stdlib/InteractiveUtils/test/runtests.jl:841
ERROR: Package InteractiveUtils errored during testing
```

---

Using the results of this pull request:

```
@test_nowarn subtypes(Integer);
```

passes without error. The other tests pass too.

(cherry picked from commit 20f933a)

…ractiveUtils (#56276)

This way all packages can be timed including InteractiveUtils and its
deps (Base64, JuliaSyntaxHighlighting, Markdown, StyledStrings).

With this PR
```
% ./julia --start=no -e "@time Base.@time_imports using REPL"
     41.8 ms  StyledStrings
               ┌ 0.1 ms JuliaSyntaxHighlighting.__init__()
     14.2 ms  JuliaSyntaxHighlighting
      1.0 ms  Base64
               ┌ 0.0 ms Markdown.__init__()
      9.6 ms  Markdown
      2.2 ms  InteractiveUtils
      0.3 ms  Unicode
               ┌ 0.0 ms REPL.REPLCompletions.__init__()
               ├ 0.0 ms REPL.__init__()
     95.7 ms  REPL
  0.225907 seconds (290.95 k allocations: 16.761 MiB)
```

Otherwise
```
% ./julia --start=no -e "using InteractiveUtils; @time @time_imports using REPL"
      0.5 ms  Unicode
               ┌ 0.0 ms REPL.REPLCompletions.__init__()
               ├ 0.1 ms REPL.__init__()
    107.5 ms  REPL
  0.127016 seconds (164.18 k allocations: 9.199 MiB)
```

Also the `@trace_compile` and `@trace_dispatch` macros for the same
reason.

(cherry picked from commit ab22f98)

(cherry picked from commit 1c67d0c)

Closes #56109

Simulating a bad manifest by having `LibGit2_jll` missing as a dep of
`LibGit2` in my default env, say because the manifest was generated by a
different julia version or different master julia commit.

```
julia> using Revise

julia>
```
i.e.
```
% JULIA_DEBUG=loading ./julia --startup-file=no
julia> using Revise
...
┌ Debug: Stdlib LibGit2 [76f85450-5226-5b5a-8eaa-529ad045b433] is trying to load `LibGit2_jll`
│ which is not listed as a dep in the load path manifests, so resorting to search
│ in the stdlib Project.tomls for true deps
└ @ Base loading.jl:387
┌ Debug: LibGit2 [76f85450-5226-5b5a-8eaa-529ad045b433] indeed depends on LibGit2_jll in project /Users/ian/Documents/GitHub/julia/usr/share/julia/stdlib/v1.12/LibGit2/Project.toml
└ @ Base loading.jl:395
...

julia>
```

```
julia> using Revise
Info Given Revise was explicitly requested, output will be shown live
ERROR: LoadError: ArgumentError: Package LibGit2 does not have LibGit2_jll in its dependencies:
- Note that the following manifests in the load path were resolved with a potentially
  different DEV version of the current version, which may be the cause of the error.
  Try to re-resolve them in the current version, or consider deleting them if that fails:
    /Users/ian/.julia/environments/v1.12/Manifest.toml
- You may have a partially installed environment. Try `Pkg.instantiate()`
  to ensure all packages in the environment are installed.
- Or, if you have LibGit2 checked out for development and have
  added LibGit2_jll as a dependency but haven't updated your primary
  environment's manifest file, try `Pkg.resolve()`.
- Otherwise you may need to report an issue with LibGit2
...
```

(cherry picked from commit b02d671)

Fixes #55719

---------

Co-authored-by: Max Horn <[email protected]>
(cherry picked from commit 99b8868)

This is an alternative to #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
#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.

… [deps] (#54009) (#56383)

This is a backport of #54009

---------

Co-authored-by: Kristoffer Carlsson <[email protected]>
Co-authored-by: KristofferC <[email protected]>

This is a backport of #55299

Backport of #55764.

8c84b8c (#56431)

Stdlib: SparseArrays
URL: https://github.com/JuliaSparse/SparseArrays.jl.git
Stdlib branch: release-1.10
Julia branch: backports-release-1.10
Old commit: 279b363
New commit: 8c84b8c
Julia version: 1.10.6
SparseArrays version: 1.10.0(Does not match)
Bump invoked by: @IanButterworth
Powered by:
[BumpStdlibs.jl](https://github.com/JuliaLang/BumpStdlibs.jl)

Diff:
JuliaSparse/SparseArrays.jl@279b363...8c84b8c

```
$ git log --oneline 279b363..8c84b8c
8c84b8c Merge pull request #572 from JuliaSparse/backports-release-1.10
ec38631 Update ci.yml with more architectures
46c8f7e Merge branch 'release-1.10' into backports-release-1.10
2d762b3 Manual commit for PR #550 to backport to 1.10 (#577)
5c37298 Add versions to include arch
b539588 Update CI
fa49620 Disable nested dissection
d2a80a6 Change default QR tolerance to match SPQR (#557)
9b8cd14 SparseMatrixCSC constructor with a Tuple of Integers (#523)
546be18 Fix docs conflict when building as part of full Julia docs (#430)
30fbfc6 Test suite: activate a temp project if we need to install Aqua.jl during the test suite (#425)
91b0aa5 doc: move solvers doc to `src\solvers.md` (#576)
5d3724a Inline sparse-times-dense in-place multiplication
```

Co-authored-by: Dilum Aluthge <[email protected]>

This fixes the warning:
```
/cache/build/default-aws-aarch64-ci-1-3/julialang/julia-master/src/stackwalk.c: In function 'jl_simulate_longjmp':
/cache/build/default-aws-aarch64-ci-1-3/julialang/julia-master/src/stackwalk.c:995:22: warning: initialization of 'mcontext_t *' {aka 'struct sigcontext *'} from incompatible pointer type 'struct unw_sigcontext *' [-Wincompatible-pointer-types]
  995 |     mcontext_t *mc = &c->uc_mcontext;
      |                      ^
```

This is the last remaining warning during compilation on aarch64-linux.

(cherry picked from commit 8593792)

…edness (#53658)

(cherry picked from commit 5fc1662)

currentlu this route is mentioned in docs
https://docs.julialang.org/en/v1/stdlib/Profile/#Triggered-During-Execution
but missing from the module docstring, this should help users who have
little idea how to "send a kernel signal to a process" to get started

---------

Co-authored-by: Ian Butterworth <[email protected]>
(cherry picked from commit 9af0dea)

Co-authored-by: Viral B. Shah <[email protected]>
(cherry picked from commit cd748a5)