When a type comes indirectly from one crate version but the imported trait comes from a separate crate version, the called method won't be found. We now show additional context:

```
error[E0599]: no method named `foo` found for struct `dep_2_reexport::Type` in the current scope
 --> multiple-dep-versions.rs:8:10
  |
8 |     Type.foo();
  |          ^^^ method not found in `Type`
  |
note: you have multiple different versions of crate `dependency` in your dependency graph
 --> multiple-dep-versions.rs:4:32
  |
4 | use dependency::{do_something, Trait};
  |                                ^^^^^ `dependency` imported here doesn't correspond to the right crate version
  |
 ::: ~/rust/build/x86_64-unknown-linux-gnu/test/run-make/crate-loading/rmake_out/multiple-dep-versions-1.rs:4:1
  |
4 | pub trait Trait {
  | --------------- this is the trait that was imported
  |
 ::: ~/rust/build/x86_64-unknown-linux-gnu/test/run-make/crate-loading/rmake_out/multiple-dep-versions-2.rs:4:1
  |
4 | pub trait Trait {
  | --------------- this is the trait that is needed
5 |     fn foo(&self);
  |        --- the method is available for `dep_2_reexport::Type` here
```

When encountering the following, mention the precense of conflicting crates:

```
error[E0599]: no function or associated item named `get_decoded` found for struct `HpkeConfig` in the current scope
   --> src/main.rs:7:17
    |
7   |     HpkeConfig::get_decoded(&foo);
    |                 ^^^^^^^^^^^ function or associated item not found in `HpkeConfig`
    |
note: if you're trying to build a new `HpkeConfig`, consider using `HpkeConfig::new` which returns `HpkeConfig`
   --> ~/.cargo/registry/src/index.crates.io-6f17d22bba15001f/janus_messages-0.3.1/src/lib.rs:908:5
    |
908 | /     pub fn new(
909 | |         id: HpkeConfigId,
910 | |         kem_id: HpkeKemId,
911 | |         kdf_id: HpkeKdfId,
912 | |         aead_id: HpkeAeadId,
913 | |         public_key: HpkePublicKey,
914 | |     ) -> HpkeConfig {
    | |___________________^
note: there are multiple different versions of crate `prio` in the dependency graph
   --> src/main.rs:1:5
    |
1   | use prio::codec::Decode;
    |     ^^^^^^^^^^^^^^^^^^^ `prio` imported here doesn't correspond to the right crate version
    |
   ::: ~/.cargo/registry/src/index.crates.io-6f17d22bba15001f/prio-0.9.1/src/codec.rs:35:1
    |
35  | pub trait Decode: Sized {
    | ----------------------- this is the trait that was imported
    |
   ::: ~/.cargo/registry/src/index.crates.io-6f17d22bba15001f/prio-0.10.3/src/codec.rs:35:1
    |
35  | pub trait Decode: Sized {
    | ----------------------- this is the trait that is needed
...
43  |     fn get_decoded(bytes: &[u8]) -> Result<Self, CodecError> {
    |     -------------------------------------------------------- the method is available for `HpkeConfig` here
help: there is an associated function `decode` with a similar name
    |
7   |     HpkeConfig::decode(&foo);
    |                 ~~~~~~
```

As per the case presented in rust-lang#128569, we should be showing the extra info even if auto-deref is involved.

Make checking slightly cheaper (by restricting to the right item only).

Add tests.

This test was previously flakey on `i686-mingw`, but since some
modifications I could no longer make it fail on `i686-mingw`.

See <rust-lang#128958> for multiple try
job runs.

`Either` is wasteful for a one-or-none iterator, especially since `Once`
is already an `option::IntoIter` internally. We don't really need any of
the iterator mechanisms in this case, just a single conditional insert.

This is a trivial Python script that simply tries to parse each line of stdin
(i.e. the test process output) as JSON, to verify that the overall output is
JSON Lines.

We can perform the same check directly in `rmake.rs` using `serde_json`.

…r=fee1-dead

Detect multiple crate versions on method not found

When a type comes indirectly from one crate version but the imported trait comes from a separate crate version, the called method won't be found. We now show additional context:

```
error[E0599]: no method named `foo` found for struct `dep_2_reexport::Type` in the current scope
 --> multiple-dep-versions.rs:8:10
  |
8 |     Type.foo();
  |          ^^^ method not found in `Type`
  |
note: there are multiple different versions of crate `dependency` in the dependency graph
 --> multiple-dep-versions.rs:4:32
  |
4 | use dependency::{do_something, Trait};
  |                                ^^^^^ `dependency` imported here doesn't correspond to the right crate version
  |
 ::: ~/rust/build/x86_64-unknown-linux-gnu/test/run-make/crate-loading/rmake_out/multiple-dep-versions-1.rs:4:1
  |
4 | pub trait Trait {
  | --------------- this is the trait that was imported
  |
 ::: ~/rust/build/x86_64-unknown-linux-gnu/test/run-make/crate-loading/rmake_out/multiple-dep-versions-2.rs:4:1
  |
4 | pub trait Trait {
  | --------------- this is the trait that is needed
5 |     fn foo(&self);
  |        --- the method is available for `dep_2_reexport::Type` here
```

Fix rust-lang#128569, fix rust-lang#110926, fix rust-lang#109161, fix rust-lang#81659, fix rust-lang#51458, fix rust-lang#32611. Follow up to rust-lang#124944.

…r=compiler-errors

Re-enable more debuginfo tests on Windows

These tests used to be disabled on all Windows hosts. Now they're fully enabled or just disabled on windows-gnu with an issue citation that clearly explains why.

The changes in this PR are not tested by PR CI, but I've tested it using try-jobs below.

try-job: i686-msvc
try-job: i686-mingw
try-job: x86_64-mingw
try-job: x86_64-msvc

… r=petrochenkov

Emit an error for invalid use of the linkage attribute

fixes rust-lang#128486

Currently, the use of the linkage attribute for Mod, Impl,... is incorrectly permitted. This PR will correct this issue by generating errors, and I've also added some UI test cases for it.

Related: rust-lang#128552.

…bank

Re-enable `dump-ice-to-disk` for Windows

This test was previously flakey on `i686-mingw` (reason unknown), but since some modifications (quarantining each ICE test in separate tmp dirs, adding/removing `RUSTC_ICE` env vars as suitable to prevent any kind of environmental influence), I could no longer make it fail on `i686-mingw`.

I tried running this test (without the `ignore-windows` of course) a bunch of times via `i686-mingw` try jobs and it refused to fail (see rust-lang#128958). I was also never able to reproduce the failure locally.

In any case, if this turns out to be still flakey on `i686-mingw`, we can revert the removal of `ignore-windows` but this time we'll have way more context for why the test failed.

Running the `i686-mingw` alongside some Windows jobs for basic santiy check. But the try jobs succeeding is insufficient to guarantee reproducibility.

cc rust-lang#129115 for backlink.

try-job: x86_64-msvc
try-job: x86_64-mingw
try-job: i686-msvc
try-job: i686-mingw

Use `ar_archive_writer` for writing COFF import libs on all backends

This is mostly the same as the llvm backend but with the cranelift version copy/pasted in place of the LLVM library.

Also updates ar_archive_writer to 0.4.0 which fixes rust-lang#129020

…eril

mir/pretty: use `Option` instead of `Either<Once, Empty>`

`Either` is wasteful for a one-or-none iterator, especially since `Once`
is already an `option::IntoIter` internally. We don't really need any of
the iterator mechanisms in this case, just a single conditional insert.

…r=compiler-errors

Return correct HirId when finding body owner in diagnostics

Fixes rust-lang#129145
Fixes rust-lang#128810

r? ``@compiler-errors``

```rust
fn generic<const N: u32>() {}

trait Collate<const A: u32> {
    type Pass;
    fn collate(self) -> Self::Pass;
}

impl<const B: u32> Collate<B> for i32 {
    type Pass = ();
    fn collate(self) -> Self::Pass {
        generic::<{ true }>()
        //~^ ERROR: mismatched types
    }
}
```

When type checking the `{ true }` anon const we would error with a type mismatch. This then results in diagnostics code attempting to check whether its due to a type mismatch with the return type. That logic was implemented by walking up the hir until we reached the body owner, except instead of using the `enclosing_body_owner` function it special cased various hir nodes incorrectly resulting in us walking out of the anon const and stopping at `fn collate` instead.

This then resulted in diagnostics logic inside of the anon consts `ParamEnv` attempting to do trait solving involving the `<i32 as Collate<B>>::Pass` type which ICEs because it is in the wrong environment.

I have rewritten this function to just walk up until it hits the `enclosing_body_owner` and made some other changes since I found this pretty hard to read/understand. Hopefully it's easier to understand now, it also makes it more obvious that this is not implemented in a very principled way and is definitely missing cases :)

…=compiler-errors

Fix `is_val_statically_known` for floats

The LLVM intrinsic name for floats differs from the LLVM type name, so handle them explicitly. Also adds support for `f16` and `f128`.

`f16`/`f128` tracking issue: rust-lang#116909

Port `run-make/libtest-json/validate_json.py` to Rust

This is a trivial Python script that simply tries to parse each line of stdin (i.e. the test process output) as JSON, to verify that the overall output is JSON Lines.

We can perform the same check directly in `rmake.rs` using `serde_json`.

r? ``@jieyouxu``