This commit refactors the initial implementation to fit into std and
makes some other changes:

- use MaybeUninit internally in SyncOnceCell
- correctly impl Drop for lazy::Once
- port Lazy::take from once_cell from: matklad/once_cell#100

Co-Authored-By: Paul Dicker <pitdicker@users.noreply.github.com>

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

Signed-off-by: Kristofer Rye <kristofer.rye@gmail.com>

This will render the src/ci/exec-with-shell.py script more or less
useless, but we're going to replace that by just using the system bash
instead.

Signed-off-by: Kristofer Rye <kristofer.rye@gmail.com>

Also, promote defaults.run.shell from inside only the primary jobs to
the top level.

The src/ci/exec-with-shell.py wrapper script was formerly used to change
out the shell mid-job by intercepting a CI_OVERRIDE_SHELL environment
variable.  Now, instead, we just set `bash` as the global default across
all jobs, and we also delete the exec-with-shell.py script.

Signed-off-by: Kristofer Rye <kristofer.rye@gmail.com>

Closes rust-lang#69414 (no longer ICEs after rust-lang#74159)

… for enums.

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>

Always install when the build succeeds

Fixes rust-lang#74431

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

…crum

 Add lazy initialization primitives to std

Follow-up to rust-lang#68198

Current RFC: rust-lang/rfcs#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`](rust-lang/rfcs#2788 (comment)) like `AtomicLazy`.
- [x] [Poisoning](rust-lang/rfcs#2788 (comment)). 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](matklad/once_cell#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?

…sakis

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

Finishes up rust-lang#71045, and so fixes rust-lang#63866.

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

…roalbini

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

A follow-up to rust-lang#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 rust-lang#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

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

This is a stop-gap until rust-lang#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 rust-lang#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

Add regression test for rust-lang#69414

Closes rust-lang#69414 (no longer ICEs after rust-lang#74159)

…ns-boxes, r=davidtwco

improper_ctypes_definitions: allow `Box`

Addresses rust-lang#72700 (comment).

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

Test codegen of compare_exchange operations

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

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`.

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

Fixes rust-lang#32129, fixes  rust-lang#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.

rustbuild: drop tool::should_install

Always install when the build succeeds

Fixes rust-lang#74431

…r=Manishearth

Use pathdiff crate

I wanted to tackle a simple issue, and stumbled upon rust-lang#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