Calling `Cargo::configure_linker` unconditionally slows down certain
commands (e.g., "check" command) without providing any benefit.

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

For commands like check/clean there is no need to check for target tools.
Avoiding this check can also speed up the process.

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

…n stable

otherwise the test would build in the source root's `target` folder

it'll be easier to see and update the list: the other cmd args
can just be ignored

…ify test

The latest versions of `memchr` experience LTO-related issues when
compiling for windows-gnu [1], so needs to be pinned. The issue is
present in the standard library.

`memchr` has been pinned in `rustc_ast`, but since the workspace was
recently split, this pin no longer has any effect on library crates.

Resolve this by adding `memchr` as an _unused_ dependency in `std`,
pinned to 2.5. Additionally, remove the pin in `rustc_ast` to allow
non-library crates to upgrade to the latest version.

Link: rust-lang#127890 [1]

Co-authored-by: Jubilee <workingjubilee@gmail.com>

…jieyouxu,petrochenkov

Update mingw-w64 + GNU toolchain

The list of packaged tools and their versions is available at: https://github.com/niXman/mingw-builds-binaries/releases/tag/14.1.0-rt_v12-rev0

Fixes: rust-lang#112368

bypass linker configuration and cross target check for specific commands

Avoids configuring the linker and checking cross-target-specific tools unless necessary.

Resolves rust-lang#128180

cc `@ChrisDenton`

…r=albertlarsan68

Distribute rustc_codegen_cranelift for Windows

With support for raw-dylib recently added to cg_clif, and inline assembly support working on Windows for quite a while now, all blockers for distributing cg_clif on Windows that I mentioned in rust-lang#81746 (comment) are fixed now.

Add test to build crates used by r-a on stable

r? ``@Kobzol``

I've opened other PRs for this one to work and they've landed already. I cherry-picked your commit, and added the last remaining pieces we needed I think.

…lacrum

Adjust `memchr` pinning and run `cargo update`

try-job: x86_64-mingw

…ilee

enable const-float-classify test, and test_next_up/down on 32bit x86

The  test_next_up/down tests have been disabled on all 32bit x86 targets, which goes too far -- they should definitely work on our (tier 1) i686 target, it is only without SSE that we might run into trouble due to rust-lang#114479. However, I cannot reproduce that trouble any more -- maybe that got fixed by rust-lang#123351?

The  const-float-classify test relied on const traits "because we can", and got disabled when const traits got removed. That's an unfortunate reduction in test coverage of our float functionality, so let's restore the test in a way that does not rely on const traits.

The const-float tests are actually testing runtime behavior as well, and I don't think that runtime behavior is covered anywhere else. Probably they shouldn't be called "const-float", but we don't have a `tests/ui/float` folder... should I create one and move them there? Are there any other ui tests that should be moved there?

I also removed some FIXME referring to not use x87 for Rust-to-Rust-calls -- that has happened in rust-lang#123351 so this got fixed indeed. Does that mean we can simplify all that float code again? I am not sure how to test it. Is running the test suite with an i586 target enough?

Cc `@tgross35` `@workingjubilee`

…, r=lolbinarycat,GuillaumeGomez

rustdoc-search: allow trailing `Foo ->` arg search

Fixes rust-lang#129710