Merging upstream version 1.76.0+dfsg1.

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

8 files changed, 176 insertions, 67 deletions

diff --git a/src/doc/unstable-book/src/compiler-flags/check-cfg.md b/src/doc/unstable-book/src/compiler-flags/check-cfg.md
index 0e15c7907..a5b9169c9 100644
--- a/src/doc/unstable-book/src/compiler-flags/check-cfg.md
+++ b/src/doc/unstable-book/src/compiler-flags/check-cfg.md
@@ -35,6 +35,9 @@ and `cfg!(name = "value")` call. It will check that the `"value"` specified is p
 list of expected values. If `"value"` is not in it, then `rustc` will report an `unexpected_cfgs`
 lint diagnostic. The default diagnostic level for this lint is `Warn`.
 
+The command line `--cfg` arguments are currently *NOT* checked but may very well be checked in
+the future.
+
 To enable checking of values, but to provide an empty set of expected values, use these forms:
 
 ```bash
@@ -187,70 +190,3 @@ fn shoot_lasers() {}
                             // the cfg(feature) list
 fn write_shakespeare() {}
 ```
-
-## The deprecated `names(...)` form
-
-The `names(...)` form enables checking the names. This form uses a named list:
-
-```bash
-rustc --check-cfg 'names(name1, name2, ... nameN)'
-```
-
-where each `name` is a bare identifier (has no quotes). The order of the names is not significant.
-
-If `--check-cfg names(...)` is specified at least once, then `rustc` will check all references to
-condition names. `rustc` will check every `#[cfg]` attribute, `#[cfg_attr]` attribute, `cfg` clause
-inside `#[link]` attribute and `cfg!(...)` call against the provided list of expected condition
-names. If a name is not present in this list, then `rustc` will report an `unexpected_cfgs` lint
-diagnostic. The default diagnostic level for this lint is `Warn`.
-
-If `--check-cfg names(...)` is not specified, then `rustc` will not check references to condition
-names.
-
-`--check-cfg names(...)` may be specified more than once. The result is that the list of valid
-condition names is merged across all options. It is legal for a condition name to be specified
-more than once; redundantly specifying a condition name has no effect.
-
-To enable checking condition names with an empty set of valid condition names, use the following
-form. The parentheses are required.
-
-```bash
-rustc --check-cfg 'names()'
-```
-
-Note that `--check-cfg 'names()'` is _not_ equivalent to omitting the option entirely.
-The first form enables checking condition names, while specifying that there are no valid
-condition names (outside of the set of well-known names defined by `rustc`). Omitting the
-`--check-cfg 'names(...)'` option does not enable checking condition names.
-
-## The deprecated `values(...)` form
-
-The `values(...)` form enables checking the values within list-valued conditions. It has this
-form:
-
-```bash
-rustc --check-cfg `values(name, "value1", "value2", ... "valueN")'
-```
-
-where `name` is a bare identifier (has no quotes) and each `"value"` term is a quoted literal
-string. `name` specifies the name of the condition, such as `feature` or `target_os`.
-
-When the `values(...)` option is specified, `rustc` will check every `#[cfg(name = "value")]`
-attribute, `#[cfg_attr(name = "value")]` attribute, `#[link(name = "a", cfg(name = "value"))]`
-and `cfg!(name = "value")` call. It will check that the `"value"` specified is present in the
-list of expected values. If `"value"` is not in it, then `rustc` will report an `unexpected_cfgs`
-lint diagnostic. The default diagnostic level for this lint is `Warn`.
-
-To enable checking of values, but to provide an empty set of valid values, use this form:
-
-```bash
-rustc --check-cfg `values(name)`
-```
-
-The `--check-cfg values(...)` option can be repeated, both for the same condition name and for
-different names. If it is repeated for the same condition name, then the sets of values for that
-condition are merged together.
-
-If `values()` is specified, then `rustc` will enable the checking of well-known values defined
-by itself. Note that it's necessary to specify the `values()` form to enable the checking of
-well known values, specifying the other forms doesn't implicitly enable it.
diff --git a/src/doc/unstable-book/src/compiler-flags/codegen-options.md b/src/doc/unstable-book/src/compiler-flags/codegen-options.md
new file mode 100644
index 000000000..31dfcdb19
--- /dev/null
+++ b/src/doc/unstable-book/src/compiler-flags/codegen-options.md
@@ -0,0 +1,56 @@
+# Unstable codegen options
+
+All of these options are passed to `rustc` via the `-C` flag, short for "codegen". The flags are
+stable but some of their values are individually unstable, and also require using `-Z
+unstable-options` to be accepted.
+
+## linker-flavor
+
+In addition to the stable set of linker flavors, the following unstable values also exist:
+- `ptx`: use [`rust-ptx-linker`](https://github.com/denzp/rust-ptx-linker)
+  for Nvidia NVPTX GPGPU support.
+- `bpf`: use [`bpf-linker`](https://github.com/alessandrod/bpf-linker) for eBPF support.
+
+Additionally, a set of more precise linker flavors also exists, for example allowing targets to
+declare that they use the LLD linker by default. The following values are currently unstable, and
+the goal is for them to become stable, and preferred in practice over the existing stable values:
+- `gnu`: unix-like linker with GNU extensions
+- `gnu-lld`: `gnu` using LLD
+- `gnu-cc`: `gnu` using a C/C++ compiler as the linker driver
+- `gnu-lld-cc`: `gnu` using LLD and a C/C++ compiler as the linker driver
+- `darwin`: unix-like linker for Apple targets
+- `darwin-lld`: `darwin` using LLD
+- `darwin-cc`: `darwin` using a C/C++ compiler as the linker driver
+- `darwin-lld-cc`: `darwin` using LLD and a C/C++ compiler as the linker driver
+- `wasm-lld`: unix-like linker for Wasm targets, with LLD
+- `wasm-lld-cc`: unix-like linker for Wasm targets, with LLD and a C/C++ compiler as the linker
+  driver
+- `unix`: basic unix-like linker for "any other Unix" targets (Solaris/illumos, L4Re, MSP430, etc),
+  not supported with LLD.
+- `unix-cc`: `unix` using a C/C++ compiler as the linker driver
+- `msvc-lld`: MSVC-style linker for Windows and UEFI, with LLD
+- `em-cc`: emscripten compiler frontend, similar to `wasm-lld-cc` with a different interface
+
+## link-self-contained
+
+This flag generally controls whether the linker will use libraries and objects shipped with Rust
+instead of those in the system. The stable boolean values for this flag are coarse-grained
+(everything or nothing), but there exists a set of unstable values with finer-grained control,
+`-Clink-self-contained` can accept a comma-separated list of components, individually enabled
+(`+component`) or disabled (`-component`):
+- `crto`: CRT objects (e.g. on `windows-gnu`, `musl`, `wasi` targets)
+- `libc`: libc static library (e.g. on `musl`, `wasi` targets)
+- `unwind`: libgcc/libunwind (e.g. on `windows-gnu`, `fuchsia`, `fortanix`, `gnullvm` targets)
+- `linker`: linker, dlltool, and their necessary libraries (e.g. on `windows-gnu` and for
+  `rust-lld`)
+- `sanitizers`: sanitizer runtime libraries
+- `mingw`: other MinGW libs and Windows import libs
+
+Out of the above self-contained linking components, `linker` is the only one currently implemented
+(beyond parsing the CLI options).
+
+It refers to the LLD linker, built from the same LLVM revision used by rustc (named `rust-lld` to
+avoid naming conflicts), that is distributed via `rustup` with the compiler (and is used by default
+for the wasm targets). One can also opt-in to use it by combining this flag with an appropriate
+linker flavor: for example, `-Clinker-flavor=gnu-lld-cc -Clink-self-contained=+linker` will use the
+toolchain's `rust-lld` as the linker.
diff --git a/src/doc/unstable-book/src/compiler-flags/default-hidden-visibility.md b/src/doc/unstable-book/src/compiler-flags/default-hidden-visibility.md
new file mode 100644
index 000000000..579add4a9
--- /dev/null
+++ b/src/doc/unstable-book/src/compiler-flags/default-hidden-visibility.md
@@ -0,0 +1,12 @@
+# `default-hidden-visibility`
+
+The tracking issue for this feature is: https://github.com/rust-lang/compiler-team/issues/656
+
+------------------------
+
+This flag can be used to override the target's
+[`default_hidden_visibility`](https://doc.rust-lang.org/beta/nightly-rustc/rustc_target/spec/struct.TargetOptions.html#structfield.default_hidden_visibility)
+setting.
+Using `-Zdefault_hidden_visibility=yes` is roughly equivalent to Clang's
+[`-fvisibility=hidden`](https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-fvisibility)
+cmdline flag.
diff --git a/src/doc/unstable-book/src/compiler-flags/env.md b/src/doc/unstable-book/src/compiler-flags/env.md
new file mode 100644
index 000000000..ac6d7474a
--- /dev/null
+++ b/src/doc/unstable-book/src/compiler-flags/env.md
@@ -0,0 +1,45 @@
+# `env`
+
+The tracking issue for this feature is: [#118372](https://github.com/rust-lang/rust/issues/118372).
+
+------------------------
+
+This option flag allows to specify environment variables value at compile time to be
+used by `env!` and `option_env!` macros. It also impacts `tracked_env::var` function
+from the `proc_macro` crate.
+
+This information will be stored in the dep-info files. For more information about
+dep-info files, take a look [here](https://doc.rust-lang.org/cargo/guide/build-cache.html#dep-info-files).
+
+When retrieving an environment variable value, the one specified by `--env` will take
+precedence. For example, if you want have `PATH=a` in your environment and pass:
+
+```bash
+rustc --env PATH=env
+```
+
+Then you will have:
+
+```rust,no_run
+assert_eq!(env!("PATH"), "env");
+```
+
+It will trigger a new compilation if any of the `--env` argument value is different.
+So if you first passed:
+
+```bash
+--env A=B --env X=12
+```
+
+and then on next compilation:
+
+```bash
+--env A=B
+```
+
+`X` value is different (not set) so the code will be re-compiled.
+
+Please note that on Windows, environment variables are case insensitive but case
+preserving whereas `rustc`'s environment variables are case sensitive. For example,
+having `Path` in your environment (case insensitive) is different than using
+`rustc --env Path=...` (case sensitive).
diff --git a/src/doc/unstable-book/src/compiler-flags/function-return.md b/src/doc/unstable-book/src/compiler-flags/function-return.md
new file mode 100644
index 000000000..d044a6f68
--- /dev/null
+++ b/src/doc/unstable-book/src/compiler-flags/function-return.md
@@ -0,0 +1,25 @@
+# `function-return`
+
+The tracking issue for this feature is: https://github.com/rust-lang/rust/issues/116853.
+
+------------------------
+
+Option `-Zfunction-return` controls how function returns are converted.
+
+It is equivalent to [Clang]'s and [GCC]'s `-mfunction-return`. The Linux kernel
+uses it for RETHUNK builds. For details, see [LLVM commit 2240d72f15f3] ("[X86]
+initial -mfunction-return=thunk-extern support") which introduces the feature.
+
+Supported values for this option are:
+
+  - `keep`: do not convert function returns.
+  - `thunk-extern`: convert function returns (`ret`) to jumps (`jmp`)
+    to an external symbol called `__x86_return_thunk`.
+
+Like in Clang, GCC's values `thunk` and `thunk-inline` are not supported.
+
+Only x86 and non-large code models are supported.
+
+[Clang]: https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-mfunction-return
+[GCC]: https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html#index-mfunction-return
+[LLVM commit 2240d72f15f3]: https://github.com/llvm/llvm-project/commit/2240d72f15f3b7b9d9fb65450f9bf635fd310f6f
diff --git a/src/doc/unstable-book/src/compiler-flags/llvm-module-flag.md b/src/doc/unstable-book/src/compiler-flags/llvm-module-flag.md
new file mode 100644
index 000000000..454ad0a9a
--- /dev/null
+++ b/src/doc/unstable-book/src/compiler-flags/llvm-module-flag.md
@@ -0,0 +1,12 @@
+# `llvm-module-flag`
+
+---------------------
+
+This flag allows adding a key/value to the `!llvm.module.flags` metadata in the
+LLVM-IR for a compiled Rust module.  The syntax is
+
+`-Z llvm_module_flag=<name>:<type>:<value>:<behavior>`
+
+Currently only u32 values are supported but the type is required to be specified
+for forward compatibility.  The `behavior` element must match one of the named
+LLVM [metadata behaviors](https://llvm.org/docs/LangRef.html#module-flags-metadata)
diff --git a/src/doc/unstable-book/src/compiler-flags/tls-model.md b/src/doc/unstable-book/src/compiler-flags/tls-model.md
index 8b19e785c..b7024ba88 100644
--- a/src/doc/unstable-book/src/compiler-flags/tls-model.md
+++ b/src/doc/unstable-book/src/compiler-flags/tls-model.md
@@ -20,6 +20,8 @@ loaded at program startup.
 The TLS data must not be in a library loaded after startup (via `dlopen`).
 - `local-exec` - model usable only if the TLS data is defined directly in the executable,
 but not in a shared library, and is accessed only from that executable.
+- `emulated` - Uses thread-specific data keys to implement emulated TLS.
+It is like using a general-dynamic TLS model for all modes.
 
 `rustc` and LLVM may use a more optimized model than specified if they know that we are producing
 an executable rather than a library, or that the `static` item is private enough.
diff --git a/src/doc/unstable-book/src/language-features/link-arg-attribute.md b/src/doc/unstable-book/src/language-features/link-arg-attribute.md
new file mode 100644
index 000000000..09915a7f2
--- /dev/null
+++ b/src/doc/unstable-book/src/language-features/link-arg-attribute.md
@@ -0,0 +1,21 @@
+# `link_arg_attribute`
+
+The tracking issue for this feature is: [#99427]
+
+------
+
+The `link_arg_attribute` feature allows passing arguments into the linker
+from inside of the source code. Order is preserved for link attributes as
+they were defined on a single extern block:
+
+```rust,no_run
+#![feature(link_arg_attribute)]
+
+#[link(kind = "link-arg", name = "--start-group")]
+#[link(kind = "static", name = "c")]
+#[link(kind = "static", name = "gcc")]
+#[link(kind = "link-arg", name = "--end-group")]
+extern "C" {}
+```
+
+[#99427]: https://github.com/rust-lang/rust/issues/99427