add note

change wording

short_ty_string on t

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

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

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

Remove -Zdep-tasks.

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

…ebank

Make `E0277` use short paths

Fixes rust-lang#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

…rochenkov

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.

…pl, r=petrochenkov

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)

…-errors

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.

…-obk

`rustc_interface` cleanups

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

r? `@oli-obk`

…li-obk

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

Fixes rust-lang#117265