…keyword

Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>

This commit migrates the errors that indicates an incorrect
CGU type and the fatal error that indicates that a CGU has
not been correctly recorded

This commit migrates around 80% of the parse file to use SsessionDiagnostic
We still have to migrate struct_err and struct_warn.

This commit migrates the errors in the function check_expected_reuse
to use the new SessionDiagnostic. It also does some small refactor
for the IncorrectCguReuseType to include the 'at least' word in the
fluent translation file

…, r=thomcc

Use `DisplayBuffer` for socket addresses.

Continuation of rust-lang#100625 for socket addresses.

Renames `net::addr` to `net::addr::socket`, `net::ip` to `net::addr::ip` and `net::ip::display_buffer::IpDisplayBuffer` to `net::addr::display_buffer::DisplayBuffer`.

…leywiser

Implementation of import_name_type

Fixes rust-lang#96534 by implementing rust-lang/compiler-team#525

Symbols that are exported or imported from a binary on 32bit x86 Windows can be named in four separate ways, corresponding to the [import name types](https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#import-name-type) from the PE-COFF spec. The exporting and importing binaries must use the same name encoding, otherwise mismatches can lead to link failures due to "missing symbols" or to 0xc0000139 (`STATUS_ENTRYPOINT_NOT_FOUND`) errors when the executable/library is loaded. For details, see the comments on the raw-dylib feature's rust-lang#58713. To generate the correct import libraries for these DLLs, therefore, rustc must know the import name type for each `extern` function, and there is currently no way for users to provide this information.

This change adds a new `MetaNameValueStr` key to the `#[link]` attribute called `import_name_type`, and which accepts one of three values: `decorated`, `noprefix`, and `undecorated`.

A single DLL is likely to export all its functions using the same import type name, hence `import_name_type` is a parameter of `#[link]` rather than being its own attribute that is applied per-function. It is possible to have a single DLL that exports different functions using different import name types, but users could express such cases by providing multiple export blocks for the same DLL, each with a different import name type.

Note: there is a fourth import name type defined in the PE-COFF spec, `IMPORT_ORDINAL`. This case is already handled by the `#[link_ordinal]` attribute. While it could be merged into `import_type_name`, that would not make sense as `#[link_ordinal]` provides per-function information (namely the ordinal itself).

Design decisions (these match the MCP linked above):
* For GNU, `decorated` matches the PE Spec and MSVC rather than the default behavior of `dlltool` (i.e., there will be a leading `_` for `stdcall`).
* If `import_name_type` is not present, we will keep our current behavior of matching the environment (MSVC vs GNU) default for decorating.
* Using `import_name_type` on architectures other than 32bit x86 will result in an error.
* Using `import_name_type` with link kinds other than `"raw-dylib"` will result in an error.

…grate-session, r=davidtwco

translations(rustc_session): migrates `rustc_session` to use `SessionDiagnostic` - Pt. 1

## Description

This is the first PR for the migration of the module `rustc_session`. You can follow my progress [here](rust-lang#100717 (comment)).

The PR migrates the files `cgu_reuse_tracker` and `parse.rs` to use `SessionDiagnostic `.

…t_real_intrinsic, r=oli-obk,RalfJung

Make `const_eval_select` a real intrinsic

This fixes issues where `track_caller` functions do not have nice panic
messages anymore when there is a call to the function, and uses the
MIR system to replace the call instead of dispatching via lang items.

Fixes rust-lang#100696.

…ng_sugg, r=davidtwco

sugg: suggest the usage of boolean value when there is a typo in the keyword

Fixes rust-lang#100686

This adds a new suggestion when there is a well-known typo

With the following program

```rust
fn main() {
    let x = True;
}
```

Now we have the following suggestion

```
error[E0425]: cannot find value `True` in this scope
 --> test.rs:2:13
  |
2 |     let x = True;
  |             ^^^^ not found in this scope
  |
help: you may want to use a bool value instead
  |
2 |     let x = true;
  |             ~~~~

error: aborting due to previous error
```

Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>

extra sanity check against consts pointing to mutable memory

This should be both unreachable and redundant (since we already ensure that validation only reads from read-only memory, when validating consts), but I feel like we cannot be paranoid enough here, and also if this ever fails it'll be a nicer error than the "cannot read from mutable memory" error.

…r=JoshTriplett

Reduce code size of `assert_matches_failed`

Using `write_str` instead of `<str as Display>::fmt` avoids the `pad` function which is very expensive to have in size-constrained code.