…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

This shrinks `compiler/rustc_codegen_gcc/Cargo.lock` quite a bit. The
only remaining dependencies in `compiler/rustc_codegen_gcc/Cargo.lock`
are `gccjit`, `lang_tester`, and `boml`, all of which aren't used in any
other compiler crates.

The commit also reorders and adds comments to the `extern crate` items
so they match those in miri.

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]

It was [pointed out recently][comment] that enabling `wasm-component-ld`
as a host tool is different from other host tools. This commit refactors
the logic to match by deduplicating selection of when to build other
tools and then using the same logic for `wasm-component-ld`.

[comment]: rust-lang#127866 (comment)

…ion`

because "Borrow" is the more idiomatic Rust term than "AddrOf".

…ure as the '&' variants

…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

added support for GNU/Hurd on x86_64

…rename, r=aDotInTheVoid

rustdoc: normalise type/field names

Updates rust-lang#100961

- `Import` -> `Use`, to better reflect the terminology of Rust & its syntax
- `TypeBinding` -> `AssocItemConstraint`, to sync up with `clean`
- `FnDecl` -> `FunctionSignature`, because that's what it is
- `Header` -> `FunctionHeader`, because `Header` is a very word that's very heavily loaded with different meanings
- `ItemEnum::AssocType`: `default` -> `type`, because those items appear in `impl` blocks as well, where they're _not_ the "default"
- `ItemEnum::AssocConst`: `default` -> `value`, see the previous point
- `ForeignType` -> `ExternType`, because "foreign" is not the right word there
- boolean fields' names made to consistently be a phrase that can be a yes/no answer, e.g. `async` -> `is_async`

The docs of `ItemEnum::AssocType::type_` & of `ItemEnum::AssocConst::value` are also updated to be up to date with the clarification of the name of the fields

…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

…egen_gcc, r=Mark-Simulacrum

Use sysroot crates maximally in `rustc_codegen_gcc`.

This shrinks `compiler/rustc_codegen_gcc/Cargo.lock` quite a bit. The only remaining dependencies in `compiler/rustc_codegen_gcc/Cargo.lock` are `gccjit`, `lang_tester`, and `boml`, all of which aren't used in any other compiler crates.

The commit also reorders and adds comments to the `extern crate` items so they match those in miri.

r? ``@Mark-Simulacrum``

…nt-ld-comments, r=onur-ozkan

 Fix enabling wasm-component-ld to match other tools

It was [pointed out recently][comment] that enabling `wasm-component-ld` as a host tool is different from other host tools. This commit refactors the logic to match by deduplicating selection of when to build other tools and then using the same logic for `wasm-component-ld`.

While here I also fixed a typo pointed out in rust-lang#126967 (review)

[comment]: rust-lang#127866 (comment)

…ieyouxu

run-make-support: Add llvm-pdbutil

Add llvm-pdbutil to run-make-support, so we can write better unit tests for PDB specific features.

r? ```@jieyouxu```
```@rustbot``` label: +O-windows

…jieyouxu

Test codegen when setting deployment target

Test our codegen in different scenarios when setting the deployment target. There are many places here where this is still incorrect, these will be fixed in rust-lang#129342, rust-lang#129367 and rust-lang#129369. See rust-lang#129432 for the bigger picture.

Tested locally using:
```console
./x test tests/run-make/apple-deployment-target --target="aarch64-apple-darwin,aarch64-apple-ios,aarch64-apple-ios-macabi,aarch64-apple-ios-sim,aarch64-apple-tvos,aarch64-apple-tvos-sim,aarch64-apple-visionos,aarch64-apple-visionos-sim,aarch64-apple-watchos,aarch64-apple-watchos-sim,arm64_32-apple-watchos,armv7s-apple-ios,i386-apple-ios,x86_64-apple-darwin,x86_64-apple-ios,x86_64-apple-ios-macabi,x86_64-apple-tvos,x86_64-apple-watchos-sim,x86_64h-apple-darwin"
```

The only Apple targets that aren't tested by the above command are:
- `arm64e-apple-darwin`, failed to build, see rust-lang/cc-rs#1205.
- `armv7k-apple-watchos`, failed to link, see rust-lang#130071.
- `arm64e-apple-ios`, failed to link, see rust-lang#130085.
- `i686-apple-darwin`, requires a bit of setup and an older machine, see [the docs](https://doc.rust-lang.org/nightly/rustc/platform-support/i686-apple-darwin.html).
- `i386-apple-ios` requires you to set `IPHONEOS_DEPLOYMENT_TARGET=10.0` for the test helpers to work, will be fixed by rust-lang/cc-rs#1030.

But all of this is as it was before this PR.

Fixes rust-lang#47825, since we now have a test that compiles a `dylib` for `aarch64-apple-ios`.

Split out from rust-lang#129342, see that for a little bit of the review that this has gone through already.

r? petrochenkov

``@rustbot`` label O-apple

…ef, r=compiler-errors

Rename variant `AddrOfRegion` of `RegionVariableOrigin` to `BorrowRegion`

because "Borrow" is the more idiomatic Rust term than "AddrOf".

…ingjubilee

remove 'const' from 'Option::iter'

This is kind of pointless to be a `const fn` since you can't do anything with the iterator. It is also the only `const fn iter*` in the entire standard library. It probably got constified when `~const` traits got added everywhere, and then was forgotten to be de-constified when that was undone.

The rest of the const_option feature seems like it can reasonably be stabilized, but this one IMO should not be stabilized, and it's not worth creating a new tracking issue.

Cc rust-lang#67441

make Result::copied unstably const

The corresponding `Option::copied` is unstably const, so seems reasonable to do the same here.

Fixes typo in wasm32-wasip2 doc comment

const: make ptr.is_null() stop execution on ambiguity

This seems better than saying `false` -- saying `false` is in fact actively unsound if `NonNull` then uses this to permit putting this pointer inside of it, but at runtime it turns out to be null.

Part of rust-lang#74939
Cc ``@rust-lang/wg-const-eval``

…=workingjubilee

Remove needless returns detected by clippy in libraries