Support for `f16` and `f128` is varied across targets, backends, andbackend versions. Eventually we would like to reach a point where allbackends support these approximately equally, but until then we have towork around some of these nuances of support being observable.Introduce the `cfg_target_has_reliable_f16_f128` internal feature, whichprovides the following new configuration gates:* `cfg(target_has_reliable_f16)`* `cfg(target_has_reliable_f16_math)`* `cfg(target_has_reliable_f128)`* `cfg(target_has_reliable_f128_math)``reliable_f16` and `reliable_f128` indicate that basic arithmetic forthe type works correctly. The `_math` versions indicate that anythingrelying on `libm` works correctly, since sometimes this hits a separateclass of codegen bugs.These options match configuration set by the build script at [1]. Thelogic for LLVM support is duplicated as-is from the same script. Thereare a few possible updates that will come as a follow up.The config introduced here is not planned to ever become stable, it isonly intended to replace the build scripts for `std` tests and`compiler-builtins` that don't have any way to configure based on thecodegen backend.MCP:rust-lang/compiler-team#866Closes:rust-lang/compiler-team#866[1]:https://github.com/rust-lang/rust/blob/555e1d0386f024a8359645c3217f4b3eae9be042/library/std/build.rs#L84-L186

New compiler configuration has been introduced that is designed toreplace the build script configuration `reliable_f16`, `reliable_f128`,`reliable_f16_math`, and `reliable_f128_math`. Do this replacement here,which allows us to clean up `std`'s build script.All tests are gated by `#[cfg(bootstrap)]` rather than doing a morecomplicated `cfg(bootstrap)` / `cfg(not(bootstrap))` split since thenext beta split is within two weeks.

The test run-make/amdgpu-kd has an issue where rust-lld will sometimes fail with error 0xc0000374 (STATUS_HEAP_CORRUPTION).

…sfied

…-inline, r=ZuseZ4add autodiff inlinecloses:rust-lang#138920r? `@ZuseZ4`try-job: dist-aarch64-linux

…y, r=lcnrDo not compute type_of for impl item if impl where clauses are unsatisfiedConsider the following code:```rusttrait Foo {    fn call(self) -> impl Send;}trait Nested {}impl<T> Foo for Twhere    T: Nested,{    fn call(self) -> impl Sized {        NotSatisfied.call()    }}struct NotSatisfied;impl Foo for NotSatisfied {    fn call(self) -> impl Sized {        todo!()    }}```In `impl Foo for NotSatisfied`, we need to prove that the RPITIT is well formed. This requires proving the item bound `<NotSatisfied as Foo>::RPITIT: Send`. Normalizing `<NotSatisfied as Foo>::RPITIT: Send` assembles two impl candidates, via the `NotSatisfied` impl and the blanket `T` impl. We end up computing the `type_of` for the blanket impl even if `NotSatisfied: Nested` where clause does not hold.This type_of query ends up needing to prove that its own `impl Sized` RPIT satisfies `Send`, which ends up needing to compute the hidden type of the RPIT, which is equal to the return type  of `NotSatisfied.call()`. That ends up in a query cycle, since we subsequently try normalizing that return type via the blanket impl again!In the old solver, we don't end up computing the `type_of` an impl candidate if its where clauses don't hold, since this select call would fail before confirming the projection candidate:https://github.com/rust-lang/rust/blob/d7ea436a02d5de4033fcf7fd4eb8ed965d0f574c/compiler/rustc_trait_selection/src/traits/project.rs#L882This PR makes the new solver more consistent with the old solver by adding a call to `try_evaluate_added_goals` after regstering the impl predicates, which causes us to bail before computing the `type_of` for impls if the impl definitely doesn't apply.r? lcnrFixesrust-lang/trait-system-refactor-initiative#185

…lcnrMove inline asm check to typeck, properly handle aliasesPull `InlineAsmCtxt` down to `rustc_hir_typeck`, and instead of using things like `Ty::is_copy`, use the `InferCtxt`-aware methods. Tofixrust-lang/trait-system-refactor-initiative#189, we also add a `try_structurally_resolve_*` call to `expr_ty`.r? lcnr

Implement the internal feature `cfg_target_has_reliable_f16_f128`Support for `f16` and `f128` is varied across targets, backends, and backend versions. Eventually we would like to reach a point where all backends support these approximately equally, but until then we have to work around some of these nuances of support being observable.Introduce the `cfg_target_has_reliable_f16_f128` internal feature, which provides the following new configuration gates:* `cfg(target_has_reliable_f16)`* `cfg(target_has_reliable_f16_math)`* `cfg(target_has_reliable_f128)`* `cfg(target_has_reliable_f128_math)``reliable_f16` and `reliable_f128` indicate that basic arithmetic for the type works correctly. The `_math` versions indicate that anything relying on `libm` works correctly, since sometimes this hits a separate class of codegen bugs.These options match configuration set by the build script at [1]. The logic for LLVM support is duplicated as-is from the same script. There are a few possible updates that will come as a follow up.The config introduced here is not planned to ever become stable, it is only intended to replace the build scripts for `std` tests and `compiler-builtins` that don't have any way to configure based on the codegen backend.MCP:rust-lang/compiler-team#866Closes:rust-lang/compiler-team#866[1]:https://github.com/rust-lang/rust/blob/555e1d0386f024a8359645c3217f4b3eae9be042/library/std/build.rs#L84-L186---The second commit makes use of this config to replace `cfg_{f16,f128}{,_math}` in `library/`. I omitted providing a `cfg(bootstrap)` configuration to keep things simpler since the next beta branch is in two weeks.try-job: aarch64-gnutry-job: i686-msvc-1try-job: test-varioustry-job: x86_64-gnutry-job: x86_64-msvc-ext2

…lcnrResolve instance for SymFn in global/naked asm`Instance::expect_resolve` ensures that we're actually going from trait item -> impl item.Fixesrust-lang#140373

Rename sub_ptr to offset_from_unsigned in docsThere are still a few mentions of `sub_ptr` in comments and doc comments, which were missed inrust-lang#137483.

…jieyouxuMake bootstrap git tests more self-containedBased onhttps://stackoverflow.com/a/67512433/1107768.Fixes:rust-lang#140387r? `@jieyouxu`

Workaround for windows-gnu rust-lld test failureThe test run-make/amdgpu-kd has an issue on windows-gnu where rust-lld will sometimes fail with error 0xc0000374 (`STATUS_HEAP_CORRUPTION`).This works around the issue by passing `--threads=1` to the linker as suggested [here](rust-lang#115985 (comment)). Note I don't know if this will help and it happens only sometimes in our CI so it's hard to test.

…r=compiler-errorsonly return nested goals for `Certainty::Yes`Ambiguous `NormalizesTo` goals can otherwise repeatedly add the same nested goals to the parent.r? `@compiler-errors`