Sync from rust 2023/10/25

…update_cg_gcc_2023-10-25

Rollup of 6 pull requests

Successful merges:

 - #116968 (Invalid `?` suggestion on mismatched `Ok(T)`)
 - #117032 (Enable cg_clif tests for riscv64gc)
 - #117106 (When expecting closure argument but finding block provide suggestion)
 - #117114 (Improve `stringify.rs` test)
 - #117188 (Avoid repeated interning of `env!("CFG_RELEASE")`)
 - #117243 (Explain implementation of mem::replace)

r? `@ghost`
`@rustbot` modify labels: rollup

… fields

Fix #22488.

…ect assert

Co-authored-by: Jubilee <46493976+workingjubilee@users.noreply.github.com>

Only emit one error per unsized binding, instead of one per usage

Fix #56607.

Decompose singular `matches!` with or-patterns to individual `matches!`
statements to enable branchless code output. The following functions
were changed:
- `is_ascii_alphanumeric`
- `is_ascii_hexdigit`
- `is_ascii_punctuation`

Add codegen tests

Co-authored-by: George Bateman <george.bateman16@gmail.com>
Co-authored-by: scottmcm <scottmcm@users.noreply.github.com>

Allow target specs to use an LLD flavor, and self-contained linking components

This PR allows:
- target specs to use an LLD linker-flavor: this is needed to switch `x86_64-unknown-linux-gnu` to using LLD, and is currently not possible because the current flavor json serialization fails to roundtrip on the modern linker-flavors. This can e.g. be seen in rust-lang/rust#115622 (comment) which explains where an `Lld::Yes` is ultimately deserialized into an `Lld::No`.
- target specs to declare self-contained linking components: this is needed to switch `x86_64-unknown-linux-gnu` to using `rust-lld`
- adds an end-to-end test of a custom target json simulating `x86_64-unknown-linux-gnu` being switched to using `rust-lld`
- disables codegen backends from participating because they don't support `-Zgcc-ld=lld` which is the basis of mcp510.

r? `@petrochenkov:` if the approach discussed rust-lang/rust#115622 (comment) and on zulip would work for you: basically, see if we can emit only modern linker flavors in the json specs, but accept both old and new flavors while reading them, to fix the roundtrip issue.

The backwards compatible `LinkSelfContainedDefault` variants are still serialized and deserialized in `crt-objects-fallback`, while the spec equivalent of e.g. `-Clink-self-contained=+linker` is serialized into a different json object (with future-proofing to incorporate `crt-objects-fallback`  in the future).

---

I've been test-driving this in rust-lang/rust#113382 to test actually switching `x86_64-unknown-linux-gnu`  to `rust-lld` (and fix what needs to be fixed in CI, bootstrap, etc), and it seems to work fine.

ZeroSized constants can be represented as `mir::Const::Val` even if
their layout is not yet known. In those cases, CrateItem::body() was
crashing when trying to convert a `ConstValue::ZeroSized` into its
stable counterpart `ConstantKind::Allocated`.

Instead, we now map `ConstValue::ZeroSized` into a new variant:
`ConstantKind::ZeroSized`.

Refactor some `char`, `u8` ASCII functions to be branchless

Extract conditions in singular `matches!` with or-patterns to individual `matches!` statements which enables branchless code output. The following functions were changed:
- `is_ascii_alphanumeric`
- `is_ascii_hexdigit`
- `is_ascii_punctuation`

Added codegen tests

---

Continued from rust-lang/rust#103024.
Based on the comment from `@scottmcm` rust-lang/rust#103024 (review).

The unmodified `is_ascii_*` functions didn't seem to benefit from extracting the conditions.

I've never written a codegen test before, but I tried to check that no branches were emitted.

The demangler was only needed by coverage tests, but those tests were migrated
into their own custom test mode in #112300.

This avoids having to build the demangler just for run-make tests. It will
still be built as needed by run-coverage tests or for other purposes.

This avoids useless rebuilds of the demangler when modifying the compiler.

This hopefully fixes the CI run after integration of this
target.

…r=dtolnay

Stabilize `[const_]pointer_byte_offsets`

Closes #96283
Awaiting FCP completion: rust-lang/rust#96283 (comment)

r? libs-api

… r=ehuss

feat(docs): add cargo-pgo to PGO documentation 📝

fixes #114995

Tweak suggestion span for outer attr and point at item following invalid inner attr

After:

```
error: `unix_sigpipe` attribute cannot be used at crate level
  --> $DIR/unix_sigpipe-crate.rs:2:1
   |
LL | #![unix_sigpipe = "inherit"]
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
LL |
LL | fn main() {}
   | ------------ the inner attribute doesn't annotate this function
   |
help: perhaps you meant to use an outer attribute
   |
LL - #![unix_sigpipe = "inherit"]
LL + #[unix_sigpipe = "inherit"]
   |
```

Before:

```
error: `unix_sigpipe` attribute cannot be used at crate level
  --> $DIR/unix_sigpipe-crate.rs:2:1
   |
LL | #![unix_sigpipe = "inherit"]
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
help: perhaps you meant to use an outer attribute
   |
LL | #[unix_sigpipe = "inherit"]
   | ~~~~~~~~~~~~~~~~~~~~~~~~~~~
```

CC #89566.

…o-fix-typo, r=the8472

Fix documentation typo in std::iter::Iterator::collect_into

…i-obk

Stash and cancel cycle errors for auto trait leakage in opaques

We don't need to emit a traditional cycle error when we have a selection error that explains what's going on but in more detail.

We may want to augment this error to actually point out the cycle, now that the cycle error is not being emitted. We could do that by storing the set of opaques that was in the `CyclePlaceholder` that gets returned from `type_of_opaque`.

r? `@oli-obk` cc `@estebank` #117235

Create a new ConstantKind variant (ZeroSized) for StableMIR

ZeroSized constants can be represented as `mir::Const::Val` even if their layout is not yet known. In those cases, CrateItem::body() was crashing when trying to convert a `ConstValue::ZeroSized` into its stable counterpart  `ConstantKind::Allocated`.

Instead, we now map `ConstValue::ZeroSized` into a new variant: `ConstantKind::ZeroSized`.

**Note:** I didn't add any new test here since we already have covering tests in our project repository which I manually confirmed that will fix the issue.

replace transmute by raw pointer cast

Now that rust-lang/rust#113257 is fixed we can finally do this. :)

Rollup of 6 pull requests

Successful merges:

 - #114998 (feat(docs): add cargo-pgo to PGO documentation 📝)
 - #116868 (Tweak suggestion span for outer attr and point at item following invalid inner attr)
 - #117240 (Fix documentation typo in std::iter::Iterator::collect_into)
 - #117241 (Stash and cancel cycle errors for auto trait leakage in opaques)
 - #117262 (Create a new ConstantKind variant (ZeroSized) for StableMIR)
 - #117266 (replace transmute by raw pointer cast)

r? `@ghost`
`@rustbot` modify labels: rollup

notes

This commit extends the `#[diagnostic::on_unimplemented]` (and
`#[rustc_on_unimplemented]`) attributes to allow multiple `note`
options. This enables emitting multiple notes for custom error messages.
For now I've opted to not change any of the existing usages of
`#[rustc_on_unimplemented]` and just updated the relevant compile tests.

…t-codegen

This ensures that cg_clif can be built for targets that aren't natively
supported by Cranelift. It will not be possible to compile for the host
in this case, but cross-compilation will still be possible.

We won't distribute cg_clif as rustup component for any targets that
aren't natively supported by Cranelift, but will still build it if
codegen-backends lists "cranelift".

…t-codegen

This ensures that cg_clif can be built for targets that aren't natively
supported by Cranelift. It will not be possible to compile for the host
in this case, but cross-compilation will still be possible.

We won't distribute cg_clif as rustup component for any targets that
aren't natively supported by Cranelift, but will still build it if
codegen-backends lists "cranelift".

This adds support for loongarch and a bunch of other targets

This adds support for loongarch and a bunch of other targets

Suggest assoc fn `new` when trying to build tuple struct with private fields

Fix #22488.

Lint overlapping ranges as a separate pass

This reworks the [`overlapping_range_endpoints`](https://doc.rust-lang.org/beta/nightly-rustc/rustc_lint_defs/builtin/static.OVERLAPPING_RANGE_ENDPOINTS.html) lint. My motivations are:

- It was annoying to have this lint entangled with the exhaustiveness algorithm, especially wrt librarification;
- This makes the lint behave consistently.

Here's the consistency story. Take the following matches:
```rust
match (0u8, true) {
    (0..=10, true) => {}
    (10..20, true) => {}
    (10..20, false) => {}
    _ => {}
}
match (true, 0u8) {
    (true, 0..=10) => {}
    (true, 10..20) => {}
    (false, 10..20) => {}
    _ => {}
}
```
There are two semantically consistent options: option 1 we lint all overlaps between the ranges, option 2 we only lint the overlaps that could actually occur (i.e. the ones with `true`). Option 1 is what this PR does. Option 2 is possible but would require the exhaustiveness algorithm to track more things for the sake of the lint. The status quo is that we're inconsistent between the two.

Option 1 generates more false postives, but I prefer it from a maintainer's perspective. I do think the difference is minimal; cases where the difference is observable seem rare.

This PR adds a separate pass, so this will have a perf impact. Let's see how bad, it looked ok locally.

Signed-off-by: onur-ozkan <work@onurozkan.dev>

Only call `mir_const_qualif` if absolutely necessary

Pull the perf change out of rust-lang/rust#113617

This should not have any impact on behaviour (if it does, we'll see an ICE)

Fix #89868.

```
error[E0277]: the trait bound `S: d::Hidden` is not satisfied
  --> $DIR/sealed-trait-local.rs:53:20
   |
LL | impl c::Sealed for S {}
   |                    ^ the trait `d::Hidden` is not implemented for `S`
   |
note: required by a bound in `c::Sealed`
  --> $DIR/sealed-trait-local.rs:17:23
   |
LL |     pub trait Sealed: self::d::Hidden {
   |                       ^^^^^^^^^^^^^^^ required by this bound in `Sealed`
   = note: `Sealed` is a "sealed trait", because to implement it you also need to implement `c::d::Hidden`, which is not accessible; this is usually done to force you to use one of the provided types that already implement it
   = help: the following types implement the trait:
            - c::X
            - c::Y
```

The last `help` is new.

Remove `rustc_symbol_mangling/messages.ftl`.

It contains a single message that (a) doesn't contain any natural language, and (b) is only used in tests.

r? `@davidtwco`

…rrors

Properly restore snapshot when failing to recover parsing ternary

If the recovery parsed an expression, then failed to eat a `:`, it would return `false` without restoring the snapshot. Fix this by always restoring the snapshot when returning `false`.

Draft for now because I'd like to try and improve this recovery further.

Fixes #117208

Fix ICE: Restrict param constraint suggestion

When encountering an associated item with a type param that could be constrained, do not look at the parent item if the type param comes from the associated item.

Fix #117209, fix #89868.

…, r=workingjubilee,RalfJung

NVPTX: Allow PassMode::Direct for ptx kernels for now

Upgrading the nvptx toolchain to the newest nightly makes it hit the assert that links to rust-lang/rust#115666

It seems like most targets get around this by using `PassMode::Indirect`. That is impossible for the kernel as it's not a normal call, but instead the arguments are copied from CPU to GPU and the passed pointer would be invalid when it reached the GPU.

I also made an experiment with `PassMode::Cast` but at least the most simple version of this broke the assembly API tests.

I added  fixing the pass mode in my unofficial tracking issue list (I do not have the necessary permissions to update to official one). rust-lang/rust#38788 (comment)

Since the ptx_abi is currently unstable and have been working with `PassMode::Direct` for more than a year now, the steps above is hopefully sufficient to enable it as an exception until I can prioritize to fix it. I'm currently looking at steps to enable the CI for nvptx64 again and would prefer to finish that first.

Hide internal methods from documentation

The two methods here are perma-unstable and only made public for technical reasons. There is no reason to show them in documentation.

`@rustbot` label +A-docs

std::thread : add SAFETY comment

I forgot to add this in rust-lang/rust#117266.

fix miri target information for Test step

self-explanatory

r? RalfJung

Co-authored-by: Ralf Jung <post@ralfj.de>

Allow partially moved values in match

This PR attempts to unify the behaviour between `let _ = PLACE`, `let _: TY = PLACE;` and `match PLACE { _ => {} }`.
The logical conclusion is that the `match` version should not check for uninitialised places nor check that borrows are still live.

The `match PLACE {}` case is handled by keeping a `FakeRead` in the unreachable fallback case to verify that `PLACE` has a legal value.

Schematically, `match PLACE { arms }` in surface rust becomes in MIR:
```rust
PlaceMention(PLACE)
match PLACE {
  // Decision tree for the explicit arms
  arms,
  // An extra fallback arm
  _ => {
    FakeRead(ForMatchedPlace, PLACE);
    unreachable
  }
}
```

`match *borrow { _ => {} }` continues to check that `*borrow` is live, but does not read the value.
`match *borrow {}` both checks that `*borrow` is live, and fake-reads the value.

Continuation of ~rust-lang/rust#102256 ~rust-lang/rust#104844

Fixes rust-lang/rust#99180 rust-lang/rust#53114

This avoids needlessly building cg_clif for other targets and makes it
easier for the dist code to determine if it should distribute cg_clif as
component.

Co-authored-by: Esteban Kuber <estebank@users.noreply.github.com>

Make build scripts work with rust bootstrap

…update_cg_gcc_2023-10-25

Rollup of 7 pull requests

Successful merges:

 - #116834 (Remove `rustc_symbol_mangling/messages.ftl`.)
 - #117212 (Properly restore snapshot when failing to recover parsing ternary)
 - #117246 (Fix ICE: Restrict param constraint suggestion)
 - #117247 (NVPTX: Allow PassMode::Direct for ptx kernels for now)
 - #117270 (Hide internal methods from documentation)
 - #117281 (std::thread : add SAFETY comment)
 - #117287 (fix miri target information for Test step)

r? `@ghost`
`@rustbot` modify labels: rollup

In `test_edition_parsing`, change the
`build_session_options_and_crate_config` call to
`build_session_options`, because the config isn't used.

That leaves a single call site for
`build_session_options_and_crate_config`, so just inline and remove it.

Because its order doesn't matter. This is well demonstrated by
`to_crate_config`, which creates a `CrateConfig` from an `FxHashSet`.

In `parse_cfg`, we now construct a `FxHashSet<String>` directly instead of
constructing a `FxHashSet<Symbol>` and then immediately converting it to a
`FxHashSet<String>`(!)

(The type names made this behaviour non-obvious. The next commit will
make the type names clearer.)

`parse_cfgspecs` and `parse_check_cfg` run very early, before the main
interner is running. They each use a short-lived interner and convert
all interned symbols to strings in their output data structures. Once
the main interner starts up, these data structures get converted into
new data structures that are identical except with the strings converted
to symbols.

All is not obvious from the current code, which is a mess, particularly
with inconsistent naming that obscures the parallel string/symbol data
structures. This commit clean things up a lot.

- The existing `CheckCfg` type is generic, allowing both
  `CheckCfg<String>` and `CheckCfg<Symbol>` forms. This is really
  useful, but it defaults to `String`. The commit removes the default so
  we have to use `CheckCfg<String>` and `CheckCfg<Symbol>` explicitly,
  which makes things clearer.

- Introduces `Cfg`, which is generic over `String` and `Symbol`, similar
  to `CheckCfg`.

- Renames some things.
  - `parse_cfgspecs` -> `parse_cfg`
  - `CfgSpecs` -> `Cfg<String>`, plus it's used in more places, rather
    than the underlying `FxHashSet` type.
  - `CrateConfig` -> `Cfg<Symbol>`.
  - `CrateCheckConfig` -> `CheckCfg<Symbol>`

- Adds some comments explaining the string-to-symbol conversions.

- `to_crate_check_config`, which converts `CheckCfg<String>` to
  `CheckCfg<Symbol>`, is inlined and removed and combined with the
  overly-general `CheckCfg::map_data` to produce
  `CheckCfg::<String>::intern`.

- `build_configuration` now does the `Cfg<String>`-to-`Cfg<Symbol>`
  conversion, so callers don't need to, which removes the need for
  `to_crate_config`.

The diff for two of the fields in `Config` is a good example of the
improved clarity:
```
-    pub crate_cfg: FxHashSet<(String, Option<String>)>,
-    pub crate_check_cfg: CheckCfg,
+    pub crate_cfg: Cfg<String>,
+    pub crate_check_cfg: CheckCfg<String>,
```
Compare that with the diff for the corresponding fields in `ParseSess`,
and the relationship to `Config` is much clearer than before:
```
-    pub config: CrateConfig,
-    pub check_config: CrateCheckConfig,
+    pub config: Cfg<Symbol>,
+    pub check_config: CheckCfg<Symbol>,
```

Despite what I claimed in an earlier commit, the ordering does matter to
some degree. Using `FxIndexSet` prevents changes to the error message
order in `tests/ui/check-cfg/mix.rs`.

…pings

…meGomez

rustdoc: use JS to inline target type impl docs into alias

Preview docs:

- https://notriddle.com/rustdoc-html-demo-5/js-trait-alias/std/io/type.Result.html

- https://notriddle.com/rustdoc-html-demo-5/js-trait-alias-compiler/rustc_middle/ty/type.PolyTraitRef.html

This pull request also includes a bug fix for trait alias inlining across crates. This means more documentation is generated, and is why ripgrep runs slower (it's a thin wrapper on top of the `grep` crate, so 5% of its docs are now the Result type).

- Before, built with rustdoc 1.75.0-nightly (aa1a71e 2023-10-26), Result type alias method docs are missing: http://notriddle.com/rustdoc-html-demo-5/ripgrep-js-nightly/rg/type.Result.html
- After, built with this branch, all the methods on Result are shown: http://notriddle.com/rustdoc-html-demo-5/ripgrep-js-trait-alias/rg/type.Result.html

*Review note: This is mostly just reverting rust-lang/rust#115201. The last commit has the new work in it.*

Fixes #115718

This is an attempt to balance three problems, each of which would
be violated by a simpler implementation:

- A type alias should show all the `impl` blocks for the target
  type, and vice versa, if they're applicable. If nothing was
  done, and rustdoc continues to match them up in HIR, this
  would not work.

- Copying the target type's docs into its aliases' HTML pages
  directly causes far too much redundant HTML text to be generated
  when a crate has large numbers of methods and large numbers
  of type aliases.

- Using JavaScript exclusively for type alias impl docs would
  be a functional regression, and could make some docs very hard
  to find for non-JS readers.

- Making sure that only applicable docs are show in the
  resulting page requires a type checkers. Do not reimplement
  the type checker in JavaScript.

So, to make it work, rustdoc stashes these type-alias-inlined docs
in a JSONP "database-lite". The file is generated in `write_shared.rs`,
included in a `<script>` tag added in `print_item.rs`, and `main.js`
takes care of patching the additional docs into the DOM.

The format of `trait.impl` and `type.impl` JS files are superficially
similar. Each line, except the JSONP wrapper itself, belongs to a crate,
and they are otherwise separate (rustdoc should be idempotent). The
"meat" of the file is HTML strings, so the frontend code is very simple.
Links are relative to the doc root, though, so the frontend needs to fix
that up, and inlined docs can reuse these files.

However, there are a few differences, caused by the sophisticated
features that type aliases have. Consider this crate graph:

```text
 ---------------------------------
 | crate A: struct Foo<T>        |
 |          type Bar = Foo<i32>  |
 |          impl X for Foo<i8>   |
 |          impl Y for Foo<i32>  |
 ---------------------------------
     |
 ----------------------------------
 | crate B: type Baz = A::Foo<i8> |
 |          type Xyy = A::Foo<i8> |
 |          impl Z for Xyy        |
 ----------------------------------
```

The type.impl/A/struct.Foo.js JS file has a structure kinda like this:

```js
JSONP({
"A": [["impl Y for Foo<i32>", "Y", "A::Bar"]],
"B": [["impl X for Foo<i8>", "X", "B::Baz", "B::Xyy"], ["impl Z for Xyy", "Z", "B::Baz"]],
});
```

When the type.impl file is loaded, only the current crate's docs are
actually used. The main reason to bundle them together is that there's
enough duplication in them for DEFLATE to remove the redundancy.

The contents of a crate are a list of impl blocks, themselves
represented as lists. The first item in the sublist is the HTML block,
the second item is the name of the trait (which goes in the sidebar),
and all others are the names of type aliases that successfully match.

This way:

- There's no need to generate these files for types that have no aliases
  in the current crate. If a dependent crate makes a type alias, it'll
  take care of generating its own docs.
- There's no need to reimplement parts of the type checker in
  JavaScript. The Rust backend does the checking, and includes its
  results in the file.
- Docs defined directly on the type alias are dropped directly in the
  HTML by `render_assoc_items`, and are accessible without JavaScript.
  The JSONP file will not list impl items that are known to be part
  of the main HTML file already.

[JSONP]: https://en.wikipedia.org/wiki/JSONP

Avoid unnecessary builds/rebuilds of `rust-demangler`

This is a combination of two loosely-related changes:

- Don't build `rust-demangler` as a dependency of `tests/run-make`, because after #112300 none of the remaining run-make tests actually use it. (If future run-make tests ever do need the demangler, it'll be easy to add it back.)
- For `tests/run-coverage`, build the demangler with the stage 0 compiler instead of the current-stage compiler. This avoids having to uselessly rebuild the demangler after modifying and rebuilding the compiler itself.

Update cargo

8 commits in df3509237935f9418351b77803df7bc05c009b3d..708383d620e183a9ece69b8fe930c411d83dee27
2023-10-24 23:09:01 +0000 to 2023-10-27 21:09:26 +0000
- feat(doc): Print the generated docs links (rust-lang/cargo#12859)
- feat(toml): Allow version-less manifests (rust-lang/cargo#12786)
- Remove outdated option to `-Zcheck-cfg` warnings (rust-lang/cargo#12884)
- Remove duplicate binaries during install (rust-lang/cargo#12868)
- refactor(shell): Write at once rather than in fragments (rust-lang/cargo#12880)
- docs(ref): Link to docs.rs metadata table (rust-lang/cargo#12879)
- docs(contrib): Describe how to add a new package (rust-lang/cargo#12878)
- move up looking at index summary enum (rust-lang/cargo#12749)

r? ghost

…orn3,GuillaumeGomez

subtree update cg_gcc 2023/10/25

Remove -Zdep-tasks.

This option is not useful any more, we can use `tracing` and `RUSTC_LOG` to debug the dep-graph.

Make `E0277` use short paths

Fixes #116616

Create `windows/api.rs` for safer FFI

FFI is inherently unsafe. For memory safety we need to assert that some contract is being upheld on both sides of the FFI, though of course we can only ever check our side. In Rust, `unsafe` blocks are used to assert safety and `// SAFETY` comments describing why it is safe. Currently in sys/windows we have a lot of this unsafety spread all over the place, with variations on the same unsafe patterns repeated. And because of the repitition and frequency, we're a bit lax with the safety comments.

This PR aims to fix this and to make FFI safety more auditable by creating an `api` module with the goal of centralising and consolidating this unsafety. It contains thin wrappers around the Windows API that make most functions safe to call or, if that's not possible, then at least safer. Note that its goal is *only* to address safety. It does not stray far from the Windows API and intentionally does not attempt to make higher lever wrappers around, for example, file handles. This is better left to the existing modules. The windows/api.rs file has a top level comment to help future contributors understand the intent of the module and the design decisions made.

I chose two functions as a first tentative step towards the above goal:

- [`GetLastError`](https://learn.microsoft.com/en-us/windows/win32/api/errhandlingapi/nf-errhandlingapi-getlasterror) is trivially safe. There's no reason to wrap it in an `unsafe` block every time. So I simply created a safe `get_last_error` wrapper.
- [`SetFileInformationByHandle`](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-setfileinformationbyhandle) is more complex. It essentially takes a generic type but over a C API which necessitates some amount of ceremony. Rather than implementing similar unsafe patterns in multiple places, I provide a safe `set_file_information_by_handle` that takes a Rusty generic type and handles converting that to the form required by the C FFI.

r? libs

When encountering sealed traits, point types that implement it

```
error[E0277]: the trait bound `S: d::Hidden` is not satisfied
  --> $DIR/sealed-trait-local.rs:53:20
   |
LL | impl c::Sealed for S {}
   |                    ^ the trait `d::Hidden` is not implemented for `S`
   |
note: required by a bound in `c::Sealed`
  --> $DIR/sealed-trait-local.rs:17:23
   |
LL |     pub trait Sealed: self::d::Hidden {
   |                       ^^^^^^^^^^^^^^^ required by this bound in `Sealed`
   = note: `Sealed` is a "sealed trait", because to implement it you also need to implement `c::d::Hidden`, which is not accessible; this is usually done to force you to use one of the provided types that already implement it
   = help: the following types implement the trait:
            - c::X
            - c::Y
```

The last `help` is new.

…rochenkov

Cleanup and improve `--check-cfg` implementation

This PR removes some indentation in the code, as well as preventing some bugs/misusages and fix a nit in the doc.

r? ```@petrochenkov``` (maybe)

Parse rustc version at compile time

This PR eliminates a couple awkward codepaths where it was not clear how the compiler should proceed if its own version number is incomprehensible.

https://github.com/rust-lang/rust/blob/dab715641e96a61a534587fda9de1128b75b34dc/src/tools/clippy/clippy_utils/src/qualify_min_const_fn.rs#L385

https://github.com/rust-lang/rust/blob/dab715641e96a61a534587fda9de1128b75b34dc/compiler/rustc_attr/src/builtin.rs#L630

We can guarantee that every compiled rustc comes with a working version number, so the ICE codepaths above shouldn't need to be written.

`rustc_interface` cleanups

Particularly in and around `--cfg` and `--check-cfg` handling.

r? `@oli-obk`

fix failure to detect a too-big-type after adding padding

Fixes rust-lang/rust#117265

Rollup of 8 pull requests

Successful merges:

 - #116534 (Remove -Zdep-tasks.)
 - #116739 (Make `E0277` use short paths)
 - #116816 (Create `windows/api.rs` for safer FFI)
 - #116945 (When encountering sealed traits, point types that implement it)
 - #117025 (Cleanup and improve `--check-cfg` implementation)
 - #117256 (Parse rustc version at compile time)
 - #117268 (`rustc_interface` cleanups)
 - #117277 (fix failure to detect a too-big-type after adding padding)

r? `@ghost`
`@rustbot` modify labels: rollup

…sumption

Bump stdarch submodule and remove special handling for LLVM intrinsics that are no longer needed

Bumps stdarch to pull rust-lang/stdarch#1477, which reimplemented some functions with portable SIMD intrinsics instead of arch specific LLVM intrinsics.

Handling of those LLVM intrinsics is removed from cranelift codegen and miri.

cc `@RalfJung` `@bjorn3`

Bump stdarch submodule and remove special handling for LLVM intrinsics that are no longer needed

Bumps stdarch to pull rust-lang/stdarch#1477, which reimplemented some functions with portable SIMD intrinsics instead of arch specific LLVM intrinsics.

Handling of those LLVM intrinsics is removed from cranelift codegen and miri.

cc `@RalfJung` `@bjorn3`

This triggers a consistency check in rust (that all linker flavours
must have identical arguments), and on NetBSD/i386, the 32-bitness
is implicitly chosen through the chosen toolchain, and appears to
not be required.  So drop it, and also drop the imports of the
now-no-longer-used identifiers.

Add #[inline] to some recalcitrant ops::range methods

Fixes rust-lang/rust#116861