Rollup merge of #73618 - poliorcetics:false-keyword, r=jyn514

Documentation for the false keyword

Partial fix of #34601.

Short documentation for the false keyword mainly pointing to the `true` keyword.

Apply suggestions from review

Co-authored-by: Joshua Nelson <joshua@yottadb.com>

Auto merge of #74518 - Manishearth:rollup-jfmnh1r, r=Manishearth

Rollup of 4 pull requests

Successful merges:

 - #74333 (Deny unsafe operations in unsafe functions in libstd/alloc.rs)
 - #74356 (Remove combine function)
 - #74419 (Add a thumbv4t-none-eabi target)
 - #74485 (More intra-doc links, add explicit exception list to linkchecker)

Failed merges:

 - #74486 (Improve Read::read_exact documentation)

r? @ghost

Rollup merge of #74485 - Manishearth:more-intra-doc, r=jyn514

More intra-doc links, add explicit exception list to linkchecker

Fixes the broken links behind #32553

Progress on #32130 and #32129 except for a small number of links. Instead of whitelisting entire files, I've changed the code to whitelist specific links in specific files, and added a comment requesting people explain the reasons they add exceptions. I'm not sure if we should close those issues in favor of the already filed intra-doc link issues.

Rollup merge of #74419 - Lokathor:gba-target, r=jonas-schievink

Add a thumbv4t-none-eabi target

(cc @ketsuban, one of the few other Rust users who programs for GBA.)

---

**EDIT:** This is now a more general `thumbv4t-none-eabi` PR! See [this comment](https://github.com/rust-lang/rust/pull/74419#issuecomment-660391579)

---

Now that the PSP officially has an official target within Rust, well as the lead of the `gba` crate I can't _not_ add a GBA target as well.

I know that the [target tier policy](https://github.com/rust-lang/rfcs/pull/2803) isn't ratified and official, but I'll use it as an outline (cc @joshtriplett):
* Designated Developer: Lokathor
* Naming consistent with any existing targets
* Doesn't create Rust project legal issues.
* No license issues
* Uses the standard Apache/mit license.
* Rust tooling users don't have to accept any new licensing requirements
* Does not support hosting rust tooling.
* Doesn't require linking in proprietary code to obtain a functional binary. However, you will need to do some post-build steps to turn the ELF file into a usable GBA ROM (either for an emulator or for the actual hardware).
* This is a `no_std` environment, without even a standard global allocator, so this adds no new code to `alloc` or `std`.
* The process of building for this target is documented in the `gba` crate ([link](https://rust-console.github.io/gba/development-setup.html)). Well, the docs there are currently a little out of date, they're back on using `cargo-xbuild`, but the crate docs there will get updated once this target is available.
* This places no new burden on any other targets
* Does not break any existing targets.

I'm not fully confident in specifying the same linker script for all possible projects, so I'm currently just not giving a linker script at all, and users can continue to select their own linker script by using `-C` to provide a linker arg.

I added the file, and added it to the `supported_targets!` macro usage, and I think that's all there is to do.

Rollup merge of #74356 - lzutao:rm_combine, r=LukasKalbertodt

Remove combine function

Comparing two array directly helps generate better assert message.
Resolve https://github.com/rust-lang/rust/pull/74271/files#r454538514

Rollup merge of #74333 - poliorcetics:std-alloc-unsafe-op-in-unsafe-fn, r=LukasKalbertodt

Deny unsafe operations in unsafe functions in libstd/alloc.rs

Partial fix of #73904.

This encloses `unsafe` operations in `unsafe fn` in `libstd/alloc.rs`.

@rustbot modify labels: F-unsafe-block-in-unsafe-fn

Remove useless link to bool primitive

Auto merge of #74163 - cuviper:debian6, r=Mark-Simulacrum

ci: Update dist-{i686,x86_64}-linux to Debian 6

This increases the minimum `{i686,x86_64}-unknown-linux-gnu` platform
from RHEL/CentOS 5 (glibc 2.5 and kernel 2.6.18) to a slightly newer
Debian 6 `squeeze` (glibc 2.11 and kernel 2.6.32). While that release is
already EOL, it happens to match the minimum common versions of two
enterprise distros that do still need Rust support -- RHEL 6 (glibc 2.12
and kernel 2.6.32) and SLES 11 SP4 (glibc 2.11 and kernel 3.0).

Closes #62516.

Auto merge of #74091 - richkadel:llvm-coverage-map-gen-4, r=tmandry

Generating the coverage map

@tmandry @wesleywiser

rustc now generates the coverage map and can support (limited)
coverage report generation, at the function level.

Example commands to generate a coverage report:
```shell
$ BUILD=$HOME/rust/build/x86_64-unknown-linux-gnu
$ $BUILD/stage1/bin/rustc -Zinstrument-coverage \
$HOME/rust/src/test/run-make-fulldeps/instrument-coverage/main.rs
$ LLVM_PROFILE_FILE="main.profraw" ./main
called
$ $BUILD/llvm/bin/llvm-profdata merge -sparse main.profraw -o main.profdata
$ $BUILD/llvm/bin/llvm-cov show --instr-profile=main.profdata main
```

r? @wesleywiser

Rust compiler MCP rust-lang/compiler-team#278
Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation

primitive impls are weird

Clarify the literal string

Update src/libstd/io/mod.rs

Co-authored-by: Joshua Nelson <joshua@yottadb.com>

Update src/tools/linkchecker/main.rs

Co-authored-by: Joshua Nelson <joshua@yottadb.com>

remove unused imports

Auto merge of #74493 - Manishearth:rollup-ust7yr4, r=Manishearth

Rollup of 7 pull requests

Successful merges:

 - #70817 (Add core::task::ready! macro)
 - #73762 (Document the trait keyword)
 - #74021 (impl Index<RangeFrom> for CStr)
 - #74071 (rustc_metadata: Make crate loading fully speculative)
 - #74445 (add test for #62878)
 - #74459 (Make unreachable_unchecked a const fn)
 - #74478 (Revert "Use an UTF-8 locale for the linker.")

Failed merges:

r? @ghost

Resolve https://github.com/rust-lang/rust/pull/74419#issuecomment-660518936

Rollup merge of #74478 - rust-lang:revert-74416-linker-locale-utf8, r=Mark-Simulacrum

Revert "Use an UTF-8 locale for the linker."

Reverts rust-lang/rust#74416

This is suspected to have caused significant compile time regressions: https://perf.rust-lang.org/compare.html?start=39d5a61f2e4e237123837f5162cc275c2fd7e625&end=d3df8512d2c2afc6d2e7d8b5b951dd7f2ad77b02&stat=instructions:u

Rollup merge of #74459 - canova:const-unreachable-unchecked, r=oli-obk

Make unreachable_unchecked a const fn

This PR makes `std::hint::unreachable_unchecked` a const fn so we can use it inside a const function.
r? @RalfJung
Fixes #53188.

Rollup merge of #74445 - lcnr:const-generic-ty-decl, r=Dylan-DPC

add test for #62878

forgot to push this as part of #74159

r? @Dylan-DPC

Rollup merge of #74071 - petrochenkov:cload3, r=matthewjasper

rustc_metadata: Make crate loading fully speculative

Instead of reporting `span_err`s on the spot crate loading errors are now wrapped into the `CrateError` enum and returned, so they are reported only at the top level `resolve_crate` call, and not reported at all if we are resolving speculatively with `maybe_resolve_crate`.

As a result we can attempt loading crates for error recovery (e.g. import suggestions) without any risk of producing extra errors.
Also, this means better separation between error reporting and actual logic.

Fixes https://github.com/rust-lang/rust/issues/55103
Fixes https://github.com/rust-lang/rust/issues/56590

Rollup merge of #74021 - 1011X:master, r=dtolnay

impl Index<RangeFrom> for CStr

This change implements (partial) slicing for `CStr`.

Since a `CStr` must end in a null byte, it's not possible to trim from the right and still have a valid `CStr`. But, it *is* possible to trim from the left. This lets us be a bit more flexible and treat them more like strings.

```rust
let string = CStr::from_bytes_with_nul(b"Hello World!\0");
let result = CStr::from_bytes_with_nul(b"World!\0");
assert_eq!(&string[6..], result);
```

Rollup merge of #73762 - poliorcetics:trait-keyword, r=KodrAus

Document the trait keyword

Partial fix of #34601.

This document the trait keyword. To avoid doing too much and forcing more updates as functionalities evolve, I put two links to the reference, especially for trait objects. This mainly documents the "big" parts, not so much the small details that might trip someone experimenting.

@rustbot modify labels: T-doc,C-enhancement

Rollup merge of #70817 - yoshuawuyts:task-ready, r=dtolnay

Add core::task::ready! macro

This PR adds `ready!` as a top-level macro to `libcore` following the implementation of `futures_core::ready`, tracking issue https://github.com/rust-lang/rust/issues/70922. This macro is commonly used when implementing `Future`, `AsyncRead`, `AsyncWrite` and `Stream`. And being only 5 lines, it seems like a useful and straight forward addition to std.

## Example

```rust
use core::task::{Context, Poll};
use core::future::Future;
use core::pin::Pin;

async fn get_num() -> usize {
    42
}

pub fn do_poll(cx: &mut Context<'_>) -> Poll<()> {
    let mut f = get_num();
    let f = unsafe { Pin::new_unchecked(&mut f) };

    let num = ready!(f.poll(cx));
    // ... use num

    Poll::Ready(())
}
```

## Naming

In `async-std` we chose to nest the macro under the `task` module instead of having the macro at the top-level. This is a pattern that currently does not occur in std, mostly due to this not being possible prior to Rust 2018.

This PR proposes to add the `ready` macro as `core::ready`. But another option would be to introduce it as `core::task::ready` since it's really only useful when used in conjunction with `task::{Context, Poll}`.

## Implementation questions

I tried rendering the documentation locally but the macro didn't show up under `core`. I'm not sure if I quite got this right. I used the [`todo!` macro PR](https://github.com/rust-lang/rust/pull/56348/files) as a reference, and our approaches look similar.

## References

- [`futures::ready`](https://docs.rs/futures/0.3.4/futures/macro.ready.html)
- [`async_std::task::ready`](https://docs.rs/async-std/1.5.0/async_std/task/index.html)
- [`futures_core::ready`](https://docs.rs/futures-core/0.3.4/futures_core/macro.ready.html)

Add explicit exception list to linkchecker

Use intra-doc links on HashSet

Use intra-doc links on HashMap

Use intra-doc links in std::io

Update stability attribute for CStr indexing

impl Index<RangeFrom<usize>> for CStr

Use intra-doc links in BTreeMap

Use more intra-doc links in BTreeSet

Use intra-doc links in alloc::String

More links in std::str

Auto merge of #73441 - alexcrichton:backtrace-gimli, r=Mark-Simulacrum

std: Switch from libbacktrace to gimli

This commit is a proof-of-concept for switching the standard library's
backtrace symbolication mechanism on most platforms from libbacktrace to
gimli. The standard library's support for `RUST_BACKTRACE=1` requires
in-process parsing of object files and DWARF debug information to
interpret it and print the filename/line number of stack frames as part
of a backtrace.

Historically this support in the standard library has come from a
library called "libbacktrace". The libbacktrace library seems to have
been extracted from gcc at some point and is written in C. We've had a
lot of issues with libbacktrace over time, unfortunately, though. The
library does not appear to be actively maintained since we've had
patches sit for months-to-years without comments. We have discovered a
good number of soundness issues with the library itself, both when
parsing valid DWARF as well as invalid DWARF. This is enough of an issue
that the libs team has previously decided that we cannot feed untrusted
inputs to libbacktrace. This also doesn't take into account the
portability of libbacktrace which has been difficult to manage and
maintain over time. While possible there are lots of exceptions and it's
the main C dependency of the standard library right now.

For years it's been the desire to switch over to a Rust-based solution
for symbolicating backtraces. It's been assumed that we'll be using the
Gimli family of crates for this purpose, which are targeted at safely
and efficiently parsing DWARF debug information. I've been working
recently to shore up the Gimli support in the `backtrace` crate. As of a
few weeks ago the `backtrace` crate, by default, uses Gimli when loaded
from crates.io. This transition has gone well enough that I figured it
was time to start talking seriously about this change to the standard
library.

This commit is a preview of what's probably the best way to integrate
the `backtrace` crate into the standard library with the Gimli feature
turned on. While today it's used as a crates.io dependency, this commit
switches the `backtrace` crate to a submodule of this repository which
will need to be updated manually. This is not done lightly, but is
thought to be the best solution. The primary reason for this is that the
`backtrace` crate needs to do some pretty nontrivial filesystem
interactions to locate debug information. Working without `std::fs` is
not an option, and while it might be possible to do some sort of
trait-based solution when prototyped it was found to be too unergonomic.
Using a submodule allows the `backtrace` crate to build as a submodule
of the `std` crate itself, enabling it to use `std::fs` and such.

Otherwise this adds new dependencies to the standard library. This step
requires extra attention because this means that these crates are now
going to be included with all Rust programs by default. It's important
to note, however, that we're already shipping libbacktrace with all Rust
programs by default and it has a bunch of C code implementing all of
this internally anyway, so we're basically already switching
already-shipping functionality to Rust from C.

* `object` - this crate is used to parse object file headers and
  contents. Very low-level support is used from this crate and almost
  all of it is disabled. Largely we're just using struct definitions as
  well as convenience methods internally to read bytes and such.

* `addr2line` - this is the main meat of the implementation for
  symbolication. This crate depends on `gimli` for DWARF parsing and
  then provides interfaces needed by the `backtrace` crate to turn an
  address into a filename / line number. This crate is actually pretty
  small (fits in a single file almost!) and mirrors most of what
  `dwarf.c` does for libbacktrace.

* `miniz_oxide` - the libbacktrace crate transparently handles
  compressed debug information which is compressed with zlib. This crate
  is used to decompress compressed debug sections.

* `gimli` - not actually used directly, but a dependency of `addr2line`.

* `adler32`- not used directly either, but a dependency of
  `miniz_oxide`.

The goal of this change is to improve the safety of backtrace
symbolication in the standard library, especially in the face of
possibly malformed DWARF debug information. Even to this day we're still
seeing segfaults in libbacktrace which could possibly become security
vulnerabilities. This change should almost entirely eliminate this
possibility whilc also paving the way forward to adding more features
like split debug information.

Some references for those interested are:

* Original addition of libbacktrace - #12602
* OOM with libbacktrace - #24231
* Backtrace failure due to use of uninitialized value - #28447
* Possibility to feed untrusted data to libbacktrace - #21889
* Soundness fix for libbacktrace - #33729
* Crash in libbacktrace - #39468
* Support for macOS, never merged - ianlancetaylor/libbacktrace#2
* Performance issues with libbacktrace - #29293, #37477
* Update procedure is quite complicated due to how many patches we
  need to carry - #50955
* Libbacktrace doesn't work on MinGW with dynamic libs - #71060
* Segfault in libbacktrace on macOS - #71397

Switching to Rust will not make us immune to all of these issues. The
crashes are expected to go away, but correctness and performance may
still have bugs arise. The gimli and `backtrace` crates, however, are
actively maintained unlike libbacktrace, so this should enable us to at
least efficiently apply fixes as situations come up.

---

I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR, however:

* [ ] `gimli` needs to be published to crates.io
* [ ] `addr2line` needs a publish
* [ ] `miniz_oxide` needs a publish
* [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing
* [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349)
* [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325, https://github.com/rust-lang/backtrace-rs/issues/326, https://github.com/rust-lang/backtrace-rs/issues/350, https://github.com/rust-lang/backtrace-rs/issues/351

Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy.

In any case this is a pretty major change, so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR), but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this, so I'm hoping others can help me figure that out!

Revert "Use an UTF-8 locale for the linker."

Auto merge of #74468 - Manishearth:rollup-5nhvz80, r=Manishearth

Rollup of 11 pull requests

Successful merges:

 - #72414 ( Add lazy initialization primitives to std)
 - #74069 (Compare tagged/niche-filling layout and pick the best one)
 - #74418 (ci: Set `shell: bash` as a default, remove duplicates)
 - #74441 (bootstrap.py: patch RPATH on NixOS to handle the new zlib dependency.)
 - #74444 (Add regression test for #69414)
 - #74448 (improper_ctypes_definitions: allow `Box`)
 - #74449 (Test codegen of compare_exchange operations)
 - #74450 (Fix `Safety` docs for `from_raw_parts_mut`)
 - #74453 (Use intra-doc links in `str` and `BTreeSet`)
 - #74457 (rustbuild: drop tool::should_install)
 - #74464 (Use pathdiff crate)

Failed merges:

r? @ghost

rustc_metadata: Make crate loading fully speculative

rustc_metadata: Refactor away `CrateLocator::(dy,static)libname`

rustc_metadata: Remove some extra diagnostics for legacy plugins

They are deprecated so doing extra work for error recovery doesn't make sense

rustc_metadata: Remove a bit of ancient profiling

Rollup merge of #74464 - FedericoPonzi:fix-#67108, r=Manishearth

Use pathdiff crate

I wanted to tackle a simple issue, and stumbled upon #67108: this pr removes the function which was exported to the external crate as required in the todo/issue.
I've tested it with:
```
./x.py build --stage 1 --keep-stage 1 src/librustc_codegen_ssa
```
And it looks like it's compiling

Rollup merge of #74457 - Keruspe:install, r=Mark-Simulacrum

rustbuild: drop tool::should_install

Always install when the build succeeds

Fixes #74431

Rollup merge of #74453 - Manishearth:intra-doc-std, r=jyn514

Use intra-doc links in `str` and `BTreeSet`

Fixes #32129, fixes  #32130

A _slight_ degradation in quality is that the `#method.foo` links would previously link to the same page on `String`'s documentation, and now they will navigate to `str`. Not a big deal IMO, and we can also try to improve that.

Rollup merge of #74450 - aticu:master, r=jonas-schievink

Fix `Safety` docs for `from_raw_parts_mut`

This aligns the wording more with the documentation of e.g. `drop_in_place`, `replace`, `swap` and `swap_nonoverlapping` from `core::ptr`.

Also if the pointer were really only valid for writes, it would be trivial to introduce UB from safe code, after calling `core::slice::from_raw_parts_mut`.

Rollup merge of #74449 - tmiasko:cmpxchg-test, r=nikomatsakis

Test codegen of compare_exchange operations

Add a codegen test for compare_exchange to verify that rustc emits expected LLVM IR.

Rollup merge of #74448 - davidtwco:improper-ctypes-definitions-boxes, r=davidtwco

improper_ctypes_definitions: allow `Box`

Addresses https://github.com/rust-lang/rust/pull/72700#issuecomment-659449386.

This PR stops linting against `Box` in `extern "C" fn`s for the `improper_ctypes_definitions` lint - boxes are documented to be FFI-safe.

cc @alexcrichton @CryZe

Rollup merge of #74444 - Alexendoo:test-69414, r=nikomatsakis

Add regression test for #69414

Closes #69414 (no longer ICEs after #74159)

Rollup merge of #74441 - eddyb:zlib-on-nixos, r=nagisa

bootstrap.py: patch RPATH on NixOS to handle the new zlib dependency.

This is a stop-gap until #74420 is resolved (assuming we'll patch beta to statically link zlib).

However, I've been meaning to rewrite the NixOS support we have in `bootstrap.py` for a while now, and had to in order to cleanly add zlib as a dependency (the second commit is a relatively small delta in functionality, compared to the first).

Previously, we would extract the `ld-linux.so` path from the output of `ldd /run/current-system/sw/bin/sh`, which assumes a lot. On top of that we didn't use any symlinks, which meant if the user ran  GC (`nix-collect-garbage`), e.g. after updating their system, their `stage0` binaries would suddenly be broken (i.e. referring to files that no longer exist).
We were also using `patchelf` directly, assuming it can be found in `$PATH` (which is not necessarily true).

My new approach relies on using `nix-build` to get the following "derivations" (packages, more or less):
* `stdenv.cc.bintools`, which has a `nix-support/dynamic-linker` file containing the path to `ld-linux.so`
  * reading this file is [the canonical way to run `patchelf --set-interpreter`](https://github.com/NixOS/nixpkgs/search?l=Nix&q=%22--set-interpreter+%24%28cat+%24NIX_CC%2Fnix-support%2Fdynamic-linker%29%22)
* `patchelf` (so that the user doesn't need to have it installed)
* `zlib`, for the `libz.so` dependency of `libLLVM-*.so` (until #74420 is resolved, presumably)

This is closer to how software is built on Nix, but I've tried to keep it as simple as possible (and not add e.g. a `stage0.nix` file).
Symlinks to each of those dependencies are kept in `stage0/.nix-deps`, which prevents GC from invalidating `stage0` binaries.

r? @nagisa cc @Mark-Simulacrum @oli-obk @davidtwco

Rollup merge of #74418 - rye:gha-dedup-shell-setting, r=pietroalbini

ci: Set `shell: bash` as a default, remove duplicates

A follow-up to #74406, this commit merely removes the `shell: bash` lines where they were added in favor of setting defaults for *all* "run" steps in the jobs that run the tests.

The changes in #74406 were needed because of an upstream change to the `windows-2019` GitHub Actions image. Previously, the configuration worked fine without specifying `shell: bash`, but for some reason this broke with a new change that was deployed today. The preceding PR was a hotfix to get CI passing, but there was a slightly less duplicative way to specify the default shell for the jobs, which was to set the `defaults.run` option.

This change applies to the `pr`, `try`, `auto`, and `auto-fallible` jobs, which are derived from the YAML-anchor `base-ci-job`.  I did not apply these changes to the `master`, `try-success`, `try-failure`, `auto-success`, or `auto-failure` jobs because they have only a few steps.

cc/r? @Mark-Simulacrum

Rollup merge of #74069 - erikdesjardins:bad-niche, r=nikomatsakis

Compare tagged/niche-filling layout and pick the best one

Finishes up #71045, and so fixes #63866.

cc @eddyb
r? @nikomatsakis (since @eddyb wrote the first commit)

Rollup merge of #72414 - KodrAus:feat/stdlazy, r=Mark-Simulacrum

 Add lazy initialization primitives to std

Follow-up to #68198

Current RFC: https://github.com/rust-lang/rfcs/pull/2788

Rebased and fixed up a few of the dangling comments. Some notes carried over from the previous PR:

- [ ] Naming. I'm ok to just roll with the `Sync` prefix like `SyncLazy` for now, but [have a personal preference for `Atomic`](https://github.com/rust-lang/rfcs/pull/2788#issuecomment-574466983) like `AtomicLazy`.
- [x] [Poisoning](https://github.com/rust-lang/rfcs/pull/2788#discussion_r366725768). It seems like there's [some regret around poisoning in other `std::sync` types that we might want to just avoid upfront for `std::lazy`, especially if that would align with a future `std::mutex` that doesn't poison](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/parking_lot.3A.3AMutex.20in.20std/near/190331199). Personally, if we're adding these types to `std::lazy` instead of `std::sync`, I'd be on-board with not worrying about poisoning in `std::lazy`, and potentially deprecating `std::sync::Once` and `lazy_static` in favour of `std::lazy` down the track if it's possible, rather than attempting to replicate their behavior. cc @Amanieu @sfackler.
- [ ] [Consider making`SyncOnceCell::get` blocking](https://github.com/matklad/once_cell/pull/92). There doesn't seem to be consensus in the linked PR on whether or not that's strictly better than the non-blocking variant.

In general, none of these seem to be really blocking an initial unstable merge, so we could possibly kick off a FCP if y'all are happy?

cc @matklad @pitdicker have I missed anything, or were there any other considerations that have come up since we last looked at this?

Run fmt

Make the new target a general thumbv4t target.

Update UB test to fail during build with contant errors

link once_cell feature to #74465

Allows pathdiff package

fixes #67108 by using the external crate

std: Switch from libbacktrace to gimli

This commit is a proof-of-concept for switching the standard library's
backtrace symbolication mechanism on most platforms from libbacktrace to
gimli. The standard library's support for `RUST_BACKTRACE=1` requires
in-process parsing of object files and DWARF debug information to
interpret it and print the filename/line number of stack frames as part
of a backtrace.

Historically this support in the standard library has come from a
library called "libbacktrace". The libbacktrace library seems to have
been extracted from gcc at some point and is written in C. We've had a
lot of issues with libbacktrace over time, unfortunately, though. The
library does not appear to be actively maintained since we've had
patches sit for months-to-years without comments. We have discovered a
good number of soundness issues with the library itself, both when
parsing valid DWARF as well as invalid DWARF. This is enough of an issue
that the libs team has previously decided that we cannot feed untrusted
inputs to libbacktrace. This also doesn't take into account the
portability of libbacktrace which has been difficult to manage and
maintain over time. While possible there are lots of exceptions and it's
the main C dependency of the standard library right now.

For years it's been the desire to switch over to a Rust-based solution
for symbolicating backtraces. It's been assumed that we'll be using the
Gimli family of crates for this purpose, which are targeted at safely
and efficiently parsing DWARF debug information. I've been working
recently to shore up the Gimli support in the `backtrace` crate. As of a
few weeks ago the `backtrace` crate, by default, uses Gimli when loaded
from crates.io. This transition has gone well enough that I figured it
was time to start talking seriously about this change to the standard
library.

This commit is a preview of what's probably the best way to integrate
the `backtrace` crate into the standard library with the Gimli feature
turned on. While today it's used as a crates.io dependency, this commit
switches the `backtrace` crate to a submodule of this repository which
will need to be updated manually. This is not done lightly, but is
thought to be the best solution. The primary reason for this is that the
`backtrace` crate needs to do some pretty nontrivial filesystem
interactions to locate debug information. Working without `std::fs` is
not an option, and while it might be possible to do some sort of
trait-based solution when prototyped it was found to be too unergonomic.
Using a submodule allows the `backtrace` crate to build as a submodule
of the `std` crate itself, enabling it to use `std::fs` and such.

Otherwise this adds new dependencies to the standard library. This step
requires extra attention because this means that these crates are now
going to be included with all Rust programs by default. It's important
to note, however, that we're already shipping libbacktrace with all Rust
programs by default and it has a bunch of C code implementing all of
this internally anyway, so we're basically already switching
already-shipping functionality to Rust from C.

* `object` - this crate is used to parse object file headers and
  contents. Very low-level support is used from this crate and almost
  all of it is disabled. Largely we're just using struct definitions as
  well as convenience methods internally to read bytes and such.

* `addr2line` - this is the main meat of the implementation for
  symbolication. This crate depends on `gimli` for DWARF parsing and
  then provides interfaces needed by the `backtrace` crate to turn an
  address into a filename / line number. This crate is actually pretty
  small (fits in a single file almost!) and mirrors most of what
  `dwarf.c` does for libbacktrace.

* `miniz_oxide` - the libbacktrace crate transparently handles
  compressed debug information which is compressed with zlib. This crate
  is used to decompress compressed debug sections.

* `gimli` - not actually used directly, but a dependency of `addr2line`.

* `adler32`- not used directly either, but a dependency of
  `miniz_oxide`.

The goal of this change is to improve the safety of backtrace
symbolication in the standard library, especially in the face of
possibly malformed DWARF debug information. Even to this day we're still
seeing segfaults in libbacktrace which could possibly become security
vulnerabilities. This change should almost entirely eliminate this
possibility whilc also paving the way forward to adding more features
like split debug information.

Some references for those interested are:

* Original addition of libbacktrace - #12602
* OOM with libbacktrace - #24231
* Backtrace failure due to use of uninitialized value - #28447
* Possibility to feed untrusted data to libbacktrace - #21889
* Soundness fix for libbacktrace - #33729
* Crash in libbacktrace - #39468
* Support for macOS, never merged - ianlancetaylor/libbacktrace#2
* Performance issues with libbacktrace - #29293, #37477
* Update procedure is quite complicated due to how many patches we
  need to carry - #50955
* Libbacktrace doesn't work on MinGW with dynamic libs - #71060
* Segfault in libbacktrace on macOS - #71397

Switching to Rust will not make us immune to all of these issues. The
crashes are expected to go away, but correctness and performance may
still have bugs arise. The gimli and `backtrace` crates, however, are
actively maintained unlike libbacktrace, so this should enable us to at
least efficiently apply fixes as situations come up.

Use intra doc links in std::str

Auto merge of #74461 - Manishearth:rollup-xadbh00, r=Manishearth

Rollup of 18 pull requests

Successful merges:

 - #71670 (Enforce even more the code blocks attributes check through rustdoc)
 - #73930 (Make some Option methods const)
 - #74009 (Fix MinGW `run-make-fulldeps` tests)
 - #74056 (Add Arguments::as_str().)
 - #74169 (Stop processing unreachable blocks when solving dataflow)
 - #74251 (Teach bootstrap about target files vs target triples)
 - #74288 (Fix src/test/run-make/static-pie/test-aslr.rs)
 - #74300 (Use intra-doc links in core::iter module)
 - #74364 (add lazy normalization regression tests)
 - #74368 (Add CSS tidy check)
 - #74394 (Remove leftover from emscripten fastcomp support)
 - #74411 (Don't assign `()` to `!` MIR locals)
 - #74416 (Use an UTF-8 locale for the linker.)
 - #74424 (Move hir::Place to librustc_middle/hir)
 - #74428 (docs: better demonstrate that None values are skipped as many times a…)
 - #74438 (warn about uninitialized multi-variant enums)
 - #74440 (Fix Arc::as_ptr docs)
 - #74452 (intra-doc links: resolve modules in the type namespace)

Failed merges:

r? @ghost

Rollup merge of #74452 - Manishearth:module-type-ns, r=jyn514

intra-doc links: resolve modules in the type namespace

Fixes https://github.com/rust-lang/rust/issues/62830

Modules actually live in the type namespace, not all three, and it's not possible to clash a type with a module.

Rollup merge of #74440 - Abendstolz:patch-1, r=hanna-kruppe

Fix Arc::as_ptr docs

As a non-native speaker I stumbled upon this, looked it up and couldn't find a phrase, so I made my own assumption that "in any way" was meant (which is the meaning I would've deduced anyway)

Rollup merge of #74438 - RalfJung:uninit-lint, r=davidtwco

warn about uninitialized multi-variant enums

Fixes https://github.com/rust-lang/rust/issues/73608

Rollup merge of #74428 - tshepang:better-filter-map-doc, r=jonas-schievink

docs: better demonstrate that None values are skipped as many times a…

…s needed

Rollup merge of #74424 - sexxi-goose:move_hir_place, r=nikomatsakis

Move hir::Place to librustc_middle/hir

Needed to support https://github.com/rust-lang/project-rfc-2229/issues/7

Currently rustc_typeck depends on rustc_middle for definition TypeckTables, etc.
For supporting project-rfc-2229#7, rustc_middle would've to depend on
rustc_typeck for Place -- introducing a circular dependency.

This resembles the MIR equivalent of `Place` located in `lbrustc_middle/mir`.

Separate PR for this move will make the actual PR for using Places to represent captures cleaner/more focused.

r? @nikomatsakis  @matthewjasper

Rollup merge of #74416 - NieDzejkob:linker-locale-utf8, r=oli-obk

Use an UTF-8 locale for the linker.

Using a `C` locale breaks unicode filenames on Guix, where the linker is wrapped by a Guile program.

Rollup merge of #74411 - jonas-schievink:unbreak-mir, r=matthewjasper

Don't assign `()` to `!` MIR locals

Implements the fix described in https://github.com/rust-lang/rust/issues/73860#issuecomment-651731893.

Fixes https://github.com/rust-lang/rust/issues/73860

r? @matthewjasper

Rollup merge of #74394 - bjorn3:remove_emscripten_leftover, r=spastorino

Remove leftover from emscripten fastcomp support

This is no longer used since #63649

Rollup merge of #74368 - GuillaumeGomez:css-tidy-check, r=Mark-Simulacrum

Add CSS tidy check

r? @Mark-Simulacrum

Rollup merge of #74364 - lcnr:lazy-norm-tests, r=nikomatsakis

add lazy normalization regression tests

We previously didn't have simple tests which fail if we aren't careful around lazy normalization.

We now do.

Rollup merge of #74300 - lzutao:iterator-intra, r=jyn514

Use intra-doc links in core::iter module

This will make core::iter doc depend less on std doc.

Rollup merge of #74288 - haraldh:test_aslr, r=petrochenkov

Fix src/test/run-make/static-pie/test-aslr.rs

Might be subject to the birthday paradox occasionally, causing spurious failures.

Addresses: https://github.com/rust-lang/rust/pull/70740#pullrequestreview-430981320

Rollup merge of #74251 - shepmaster:bootstrap-target-files, r=Mark-Simulacrum

Teach bootstrap about target files vs target triples

`rustc` allows passing in predefined target triples as well as JSON
target specification files. This change allows bootstrap to have the
first inkling about those differences. This allows building a
cross-compiler for an out-of-tree architecture (even though that
compiler won't work for other reasons).

Even if no one ever uses this functionality, I think the newtype
around the `Interned<String>` improves the readability of the code.

Rollup merge of #74169 - ecstatic-morse:dataflow-unreachable, r=pnkfelix

Stop processing unreachable blocks when solving dataflow

...instead we `debug_assert` that the user is not checking the dataflow state for an unreachable block. This resolves a FIXME in the dataflow engine. The old behavior was an artifact of the previous dataflow framework. Things should run a tiny bit faster now, but I suspect not enough to show up in benchmarks. AFAIK, only the generator transform runs dataflow on MIR with unreachable basic blocks.

This PR also adds some utility methods to `mir::traversal`.

r? @pnkfelix

Rollup merge of #74056 - fusion-engineering-forks:fmt-arguments-as-str, r=Amanieu

Add Arguments::as_str().

There exist quite a few macros in the Rust ecosystem which use `format_args!()` for formatting, but special case the one-argument case for optimization:

```rust
#[macro_export]
macro_rules! some_macro {
    ($s:expr) => { /* print &str directly, no formatting, no buffers */ };
    ($s:expr, $($tt:tt)*) => { /* use format_args to write to a buffer first */ }
}
```

E.g. [here](https://github.com/rust-embedded/cortex-m-semihosting/blob/7a961f0fbe6eb1b29a7ebde4bad4b9cf5f842b31/src/macros.rs#L48-L58), [here](https://github.com/rust-lang-nursery/failure/blob/20f9a9e223b7cd71aed541d050cc73a747fc00c4/src/macros.rs#L9-L17), and [here](https://github.com/fusion-engineering/px4-rust/blob/7b679cd6da9ffd95f36f6526d88345f8b36121da/px4/src/logging.rs#L45-L52).

The problem with these is that a forgotten argument such as in `some_macro!("{}")` will not be diagnosed, but just prints `"{}"`.

With this PR, it is possible to handle the no-arguments case separately *after* `format_args!()`, while simplifying the macro. Then these macros can give the proper error about a missing argument, just like `print!("{}")` does, while still using the same optimized implementation as before.

This is even more important with [RFC 2795](https://github.com/rust-lang/rfcs/pull/2795), to make sure `some_macro!("{some_variable}")` works as expected.

Rollup merge of #74009 - mati865:mingw-tests-implib, r=nikomatsakis

Fix MinGW `run-make-fulldeps` tests

`compiler-rt-works-on-mingw` and `libs-search-path` were not ran because `only-mingw` doesn't match any target.
Enabled and verified few ignored tests with `windows-gnu` toolchain. They are still ignored on MSVC since I'm not experienced with this target.

Rollup merge of #73930 - a1phyr:feature_const_option, r=dtolnay

Make some Option methods const

Tracking issue: #67441

Constantify the following methods of `Option`:
- `as_ref`
- `is_some`
- `is_none`
- `iter` (not sure about this one, but it is possible, and will be useful when const traits are a thing)

cc @rust-lang/wg-const-eval @rust-lang/libs

Rollup merge of #71670 - GuillaumeGomez:enforce-codeblocks-attribute-check, r=Mark-Simulacrum

Enforce even more the code blocks attributes check through rustdoc

`rustdoc` now has a lint which allows it to warn if a code block attribute is malformated (which can end up in bad situations, even more in case of testing examples!). Now it'll fail if such a situation is encountered when testing markdown code blocks examples.

r? @Mark-Simulacrum

Use intra-doc links in BTreeSet docs

rustbuild: drop tool::should_install

Always install when the build succeeds

Fixes #74431

Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>

Add test for module ambiguity

Add a test for const unsafe_unreachable that triggers UB

Add a passing test for const unsafe_unreachable

Make unreachable_unchecked a const fn

Generating the coverage map

rustc now generates the coverage map and can support (limited)
coverage report generation, at the function level.

Example:

$ BUILD=$HOME/rust/build/x86_64-unknown-linux-gnu
$ $BUILD/stage1/bin/rustc -Zinstrument-coverage \
$HOME/rust/src/test/run-make-fulldeps/instrument-coverage/main.rs
$ LLVM_PROFILE_FILE="main.profraw" ./main
called
$ $BUILD/llvm/bin/llvm-profdata merge -sparse main.profraw -o main.profdata
$ $BUILD/llvm/bin/llvm-cov show --instr-profile=main.profdata main
    1|      1|pub fn will_be_called() {
    2|      1|    println!("called");
    3|      1|}
    4|       |
    5|      0|pub fn will_not_be_called() {
    6|      0|    println!("should not have been called");
    7|      0|}
    8|       |
    9|      1|fn main() {
   10|      1|    let less = 1;
   11|      1|    let more = 100;
   12|      1|
   13|      1|    if less < more {
   14|      1|        will_be_called();
   15|      1|    } else {
   16|      1|        will_not_be_called();
   17|      1|    }
   18|      1|}

Fix various tests to run on windows-gnu

intra-doc links: Resolve modules in type namespace

Fix `Safety` docs for `from_raw_parts_mut`

Auto merge of #72983 - Lezzz:rename-typeck, r=nikomatsakis

Rename TypeckTables to TypeckResults.

Originally suggested by @eddyb.

improper_ctypes_definitions: allow `Box`

This commit stops linting against `Box` in `extern "C" fn`s for the
`improper_ctypes_definitions` lint - boxes are documented to be
FFI-safe.

Signed-off-by: David Wood <david@davidtw.co>

Remove invalid test

When ran on Windows `cp` will follow symlink: `checkout/build/<target>/<stage>/lib/rustlib/src/rust`.
It points to `checkout` which means the test will get stuck in copying loop until there is no space left.

Allow matching test by target and env

Create implib for dlls when testing MinGW targets

Add tracking issue number for fmt_as_str.

Make fmt::Arguments::as_str() return a 'static str.

add test for #62878

document test changes

compare tagged/niche-filling layout and pick the best one

[experiment] ty/layout: compute both niche-filling and tagged layouts for enums.