Fixes issues introduced in #50691 and found in #55906:
* use `@inbounds` and `@boundscheck` macros in rawbigints, for catching
OOB with `--check-bounds=yes`
* fix OOB in `truncate`

(cherry picked from commit 17445fe)

(cherry picked from commit 81ce6a4)

(cherry picked from commit fbb3e11)

While building the 1.11.0-rc4 in Homebrew[^1] in preparation for 1.11.0
release (and to confirm Sequoia successfully builds) I noticed some odd
linkage for our Linux builds, which included of:

1. LLVM libraries were linking to `libedit.so`, e.g.
    ```
    Dynamic Section:
      NEEDED       libedit.so.0
      NEEDED       libz.so.1
      NEEDED       libzstd.so.1
      NEEDED       libstdc++.so.6
      NEEDED       libm.so.6
      NEEDED       libgcc_s.so.1
      NEEDED       libc.so.6
      NEEDED       ld-linux-x86-64.so.2
      SONAME       libLLVM-16jl.so
    ```
    CMakeCache.txt showed
    ```
    //Use libedit if available.
    LLVM_ENABLE_LIBEDIT:BOOL=ON
    ```
Which might be overriding `HAVE_LIBEDIT` at
https://github.com/JuliaLang/llvm-project/blob/julia-release/16.x/llvm/cmake/config-ix.cmake#L222-L225.
So just added `LLVM_ENABLE_LIBEDIT`

2. Wasn't sure if there was a reason for this but `libccalllazy*` had
mismatched SONAME:
    ```console
    ❯ objdump -p lib/julia/libccalllazy* | rg '\.so'
    lib/julia/libccalllazybar.so:	file format elf64-x86-64
      NEEDED       ccalllazyfoo.so
      SONAME       ccalllazybar.so
    lib/julia/libccalllazyfoo.so:	file format elf64-x86-64
      SONAME       ccalllazyfoo.so
    ```
    Modifying this, but can drop if intentional.

---

[^1]: Homebrew/homebrew-core#192116

(cherry picked from commit 77c5875)

Minor formatting fix

(cherry picked from commit 42737f7)

#55977 looked simple but wasn't
quite right because of a bad pattern in the lock conflicts report
section.

So fix and add tests.

(cherry picked from commit 636a35d)

(cherry picked from commit 3a132cf)

…rojname` (#55851)

(cherry picked from commit fb77d60)

(cherry picked from commit 5d12c6d)

Fixes #56017

(cherry picked from commit 57e3c9e)

…0d22b (#56032)

Stdlib: Pkg
URL: https://github.com/JuliaLang/Pkg.jl.git
Stdlib branch: release-1.11
Julia branch: backports-release-1.11
Old commit: 6ceafca8e
New commit: aba90d22b
Julia version: 1.11.0
Pkg version: 1.11.0
Bump invoked by: @IanButterworth
Powered by:
[BumpStdlibs.jl](https://github.com/JuliaLang/BumpStdlibs.jl)

Diff:
JuliaLang/Pkg.jl@6ceafca...aba90d2

```
$ git log --oneline 6ceafca8e..aba90d22b
aba90d22b Merge pull request #4037 from JuliaLang/backports-release-1.11
76eaa4caa Fix julia#55850 by using safe_realpath instead of abspath in projname (#4025)
df38587fb warn if General is installed via the old slow methods (#4022)
1475b628a update package extension naming docs (#4000)
72dc85e80 Tweak sentence syntax in getting-started.md (#4020)
0b2397089 make `add` and `dev` on a package remove it from the set of weak dependencies (#3865)
ee2d51054 collect e.g. weak deps from project even if it is not a package (#3852)
```

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

It's too disruptive to show errors for hints. The error will still be
shown if tab is pressed.

Helps issues like #56037

(cherry picked from commit 8d515ed)

This had the incorrect number of arguments to `Expr(:purity, ...)`
causing it to be silently ignored.

Works around #56022

(cherry picked from commit c7071e1)

There is a use case where you have a weak dependency (for one of your
extensions) that is misbehaving and you quickly want to try debug that
issue. A workflow that feels reasonable for this could be:

```
pkg> dev WeakDependency

julia> using Package, WeakDependency

```

This doesn't work right now for two reasons:

1. Doing the `dev WeakDependency` will add the dependency to `[deps]`
but not remove it from `[weakdeps]` which means you all of a sudden are
in the scenario described in
https://pkgdocs.julialang.org/v1/creating-packages/#Transition-from-normal-dependency-to-extension
which is not what is desired.
2. The extension will not actually load because you can right now only
trigger extensions from weak deps getting loaded, not from deps getting
loaded.

Point 1. is fixed by JuliaLang/Pkg.jl#3865
Point 2. is fixed by this PR.

(cherry picked from commit f46cb4c)

The current way of loading extensions when precompiling an extension
very easily leads to cycles. For example, if you have more than one
extension and you happen to transitively depend on the triggers of one
of your extensions you will immediately hit a cycle where the extensions
will try to load each other indefinitely. This is an issue because you
cannot directly influence your transitive dependency graph so from this
p.o.v the current system of loading extension is "unsound".

The test added here checks this scenario and we can now precompile and
load it without any warnings or issues.

Would have made #55517 a non
issue.

Fixes #55557

---------

Co-authored-by: KristofferC <[email protected]>
(cherry picked from commit 4da0671)

Fixes #55792
Replaces #55822
Improves what #51635 was trying
to do

i.e.
```
ERROR: LoadError: `using/import Printf` outside of a Module detected. Importing a package outside of a module is not allowed during package precompilation.
```

(cherry picked from commit 0fade45)

(cherry picked from commit 243bded)

…m being …"

This reverts commit 4a4ca9c.

(cherry picked from commit d65f48a)

This was very explicitly designed such that if there was a bunch of
extra space at the end of the array, we would copy rather than
allocating, but by making `newmemlen` be at least
`overallocation(memlen)` rather than `overallocation(len)`, this branch
was never hit. found by #56026

(cherry picked from commit  d4ca92c)

Co-authored-by: Oscar Smith <[email protected]>

…hes (#53469)

We can detect this since we set the `usingfailed` bit when the clash
occurs (to avoid printing the `WARNING` multiple times). In this case,
typos or missing imports (the current message) isn't quite as clear as
it could be, because in fact the name is probably spelled totally right,
it's just that there is a missing explicit import or the name should be
qualified.

This code will stop working if we change the flags in `Core.Binding`,
but the test I added should catch that. However if REPL is supposed to
be independent of Base and not depend on internals there, there could be
an issue. In that case we should probably add an API to Base to inspect
this `usingfailed` bit so we can use it in the REPL.

---------

Co-authored-by: Jameson Nash <[email protected]>
Co-authored-by: Alex Arslan <[email protected]>
(cherry picked from commit 0f902bf)

…module` (#55316)

also avoid calling `active_module` from low-level printing functions
fix #54888

(cherry picked from commit ddecfe7)

(cherry picked from commit 1438b15)