ADD - migrate MissingNativeStaticLibrary fatal error

This diagnostic has no UI test 🤔 Should we add some? If so, how?

This follows team’s suggestions in this thread https://rust-lang.zulipchat.com/#narrow/stream/336883-i18n/topic/.23100717.20diag.20translation/near/295305249

- UPDATE - revert migration of logs

- UPDATE - use derive on LinkRlibError enum

- [Gardening] UPDATE - alphabetically sort fluent_messages

- UPDATE - use PathBuf and unify both AddNativeLibrary to use Display (which is what PathBuf uses when conforming to IntoDiagnosticArg)

- UPDATE - fluent messages sort after rebase

Small tweaks to changes made in a previous PR, unrelated to eager
translation.

Signed-off-by: David Wood <[email protected]>

Eager translation will enable subdiagnostics to be translated multiple
times with different arguments - this requires the ability to replace
the value of one argument with a new value, which is better suited to a
`HashMap` than the previous storage, a `Vec`.

Signed-off-by: David Wood <[email protected]>

`AddToDiagnostic::add_to_diagnostic_with` is similar to the previous
`AddToDiagnostic::add_to_diagnostic` but takes a function that can be
used by the caller to modify diagnostic messages originating from the
subdiagnostic (such as performing translation eagerly).

`add_to_diagnostic` now just calls `add_to_diagnostic_with` with an
empty closure.

Signed-off-by: David Wood <[email protected]>

Add variant of `DiagnosticMessage` for eagerly translated messages
(messages in the target language which don't need translated by the
emitter during emission). Also adds `eager_subdiagnostic` function which
is intended to be invoked by the diagnostic derive for subdiagnostic
fields which are marked as needing eager translation.

Signed-off-by: David Wood <[email protected]>

Add support for `eager` argument to the `subdiagnostic` attribute which
generates a call to `eager_subdiagnostic`.

Signed-off-by: David Wood <[email protected]>

Using eager translation, migrate the remaining repeated cycle stack
diagnostic.

Signed-off-by: David Wood <[email protected]>

Diagnostic derives have previously had to take special care when
ordering the generated code so that fields were not used after a move.

This is unlikely for most fields because a field is either annotated
with a subdiagnostic attribute and is thus likely a `Span` and copiable,
or is a argument, in which case it is only used once by `set_arg`
anyway.

However, format strings for code in suggestions can result in fields
being used after being moved if not ordered carefully. As a result, the
derive currently puts `set_arg` calls last (just before emission), such
as:

```rust
let diag = { /* create diagnostic */ };

diag.span_suggestion_with_style(
    span,
    fluent::crate::slug,
    format!("{}", __binding_0),
    Applicability::Unknown,
    SuggestionStyle::ShowAlways
);
/* + other subdiagnostic additions */

diag.set_arg("foo", __binding_0);
/* + other `set_arg` calls */

diag.emit();
```

For eager translation, this doesn't work, as the message being
translated eagerly can assume that all arguments are available - so
arguments _must_ be set first.

Format strings for suggestion code are now separated into two parts - an
initialization line that performs the formatting into a variable, and a
usage in the subdiagnostic addition.

By separating these parts, the initialization can happen before
arguments are set, preserving the desired order so that code compiles,
while still enabling arguments to be set before subdiagnostics are
added.

```rust
let diag = { /* create diagnostic */ };

let __code_0 = format!("{}", __binding_0);
/* + other formatting */

diag.set_arg("foo", __binding_0);
/* + other `set_arg` calls */

diag.span_suggestion_with_style(
    span,
    fluent::crate::slug,
    __code_0,
    Applicability::Unknown,
    SuggestionStyle::ShowAlways
);
/* + other subdiagnostic additions */

diag.emit();
```

Signed-off-by: David Wood <[email protected]>

Following the approach taken in earlier commits to separate formatting
initialization from use in the subdiagnostic derive, simplify the
diagnostic derive by removing the field-ordering logic that previously
solved this problem.

Signed-off-by: David Wood <[email protected]>

The issue rust-lang#102157 demonstrates how currently the `-Z build-std` option
will fail when re-compiling the standard library with `RUSTFLAGS` like
`RUSTFLAGS="-C target-feature=+atomics,+bulk-memory -C
link-args=--shared-memory"`. This change attempts to resolve those build
issues by depending on the the WebAssembly `futex` module and providing
an implementation for `env_lock`. Fixes rust-lang#102157.

Copying the approach of the Unix target, this change uses the standard
`RwLock` to protect against concurrent access of libc's environment.
This locking is only enabled when WebAssembly's `atomics` feature is
also enabled.

When this was added, the sidebar had a bit more complex style. It can be
removed, now.

Allow compiling the `wasm32-wasi` std library with atomics

The issue rust-lang#102157 demonstrates how currently the `-Z build-std` option will fail when re-compiling the standard library with `RUSTFLAGS` like `RUSTFLAGS="-C target-feature=+atomics,+bulk-memory -C link-args=--shared-memory"`. This change attempts to resolve those build issues by depending on the the WebAssembly `futex` module and providing an implementation for `env_lock`. Fixes rust-lang#102157.

…-diagnostics-structs, r=davidtwco

Migrate `codegen_ssa` to diagnostics structs - [Part 1]

Initial migration of `codegen_ssa`. Going to split this crate migration in at least two PRs in order to avoid a huge PR and to quick off some questions around:

1. Translating messages from "external" crates.
2. Interfacing with OS messages.
3. Adding UI tests while migrating diagnostics.

_See comments below._

…piler-errors

translation: eager translation

Part of rust-lang#100717. See [Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/336883-i18n/topic/.23100717.20lists!/near/295010720) for additional context.

- **Store diagnostic arguments in a `HashMap`**: Eager translation will enable subdiagnostics to be translated multiple times with different arguments - this requires the ability to replace the value of one argument with a new value, which is better suited to a `HashMap` than the previous storage, a `Vec`.
- **Add `AddToDiagnostic::add_to_diagnostic_with`**: `AddToDiagnostic::add_to_diagnostic_with` is similar to the previous `AddToDiagnostic::add_to_diagnostic` but takes a function that can be used by the caller to modify diagnostic messages originating from the subdiagnostic (such as performing translation eagerly). `add_to_diagnostic` now just calls `add_to_diagnostic_with` with an empty closure.
- **Add `DiagnosticMessage::Eager`**: Add variant of `DiagnosticMessage` for eagerly translated messages
(messages in the target language which don't need translated by the emitter during emission). Also adds `eager_subdiagnostic` function which is intended to be invoked by the diagnostic derive for subdiagnostic fields which are marked as needing eager translation.
- **Support `#[subdiagnostic(eager)]`**: Add support for `eager` argument to the `subdiagnostic` attribute which generates a call to `eager_subdiagnostic`.
- **Finish migrating `rustc_query_system`**: Using eager translation, migrate the remaining repeated cycle stack diagnostic.
- **Split formatting initialization and use in diagnostic derives**: Diagnostic derives have previously had to take special care when ordering the generated code so that fields were not used after a move.

  This is unlikely for most fields because a field is either annotated with a subdiagnostic attribute and is thus likely a `Span` and copiable, or is a argument, in which case it is only used once by `set_arg`
anyway.

  However, format strings for code in suggestions can result in fields being used after being moved if not ordered carefully. As a result, the derive currently puts `set_arg` calls last (just before emission), such as:

      let diag = { /* create diagnostic */ };

      diag.span_suggestion_with_style(
          span,
          fluent::crate::slug,
          format!("{}", __binding_0),
          Applicability::Unknown,
          SuggestionStyle::ShowAlways
      );
      /* + other subdiagnostic additions */

      diag.set_arg("foo", __binding_0);
      /* + other `set_arg` calls */

      diag.emit();

  For eager translation, this doesn't work, as the message being translated eagerly can assume that all arguments are available - so arguments _must_ be set first.

  Format strings for suggestion code are now separated into two parts - an initialization line that performs the formatting into a variable, and a usage in the subdiagnostic addition.

  By separating these parts, the initialization can happen before arguments are set, preserving the desired order so that code compiles, while still enabling arguments to be set before subdiagnostics are added.

      let diag = { /* create diagnostic */ };

      let __code_0 = format!("{}", __binding_0);
      /* + other formatting */

      diag.set_arg("foo", __binding_0);
      /* + other `set_arg` calls */

      diag.span_suggestion_with_style(
          span,
          fluent::crate::slug,
          __code_0,
          Applicability::Unknown,
          SuggestionStyle::ShowAlways
      );
      /* + other subdiagnostic additions */

      diag.emit();

- **Remove field ordering logic in diagnostic derive:** Following the approach taken in earlier commits to separate formatting initialization from use in the subdiagnostic derive, simplify the diagnostic derive by removing the field-ordering logic that previously solved this problem.

r? `@compiler-errors`

Use semaphores for thread parking on Apple platforms

Currently we use a mutex-condvar pair for thread parking on Apple systems. Unfortunately, `pthread_cond_timedwait` uses the real-time clock for measuring time, which causes problems when the system time changes. The parking implementation in this PR uses a semaphore instead, which measures monotonic time by default, avoiding these issues. As a further benefit, this has the potential to improve performance a bit, since `unpark` does not need to wait for a lock to be released.

Since the Mach semaphores are poorly documented (I could not find availability or stability guarantees for instance), this uses a [dispatch semaphore](https://developer.apple.com/documentation/dispatch/dispatch_semaphore?language=objc) instead. While it adds a layer of indirection (it uses Mach semaphores internally), the overhead is probably negligible.

Tested on macOS 12.5.

r? `@thomcc`

… r=GuillaumeGomez

rustdoc: remove unneeded `<div>` wrapper from sidebar DOM

When this was added, the sidebar had a bit more complex style. It can be removed, now.

Preview: https://notriddle.com/notriddle-rustdoc-demos/sidebar-block/std/index.html