This flag is used to make the execution order around `+=` operators
pessimistic. Failure to save/restore the flag was causing independent
async blocks to effect one another, leading to strange ICEs and failed
assumptions.

by redirecting everything to `Command`

The iterators are now "fused" with `Option` so we don't need separate
state to track which part is already exhausted, and we may also get
niche layout for `None`. We don't use the real `Fuse` adapter because
its specialization for `FusedIterator` unconditionally descends into the
iterator, and that could be expensive to keep revisiting stuff like
nested chains. It also hurts compiler performance to add more iterator
layers to `Chain`.

Use unrolled loop for searching NULL in [u16] on Windows

save/restore `pessimistic_yield` when entering bodies

This flag is used to make the execution order around `+=` operators
pessimistic. Failure to save/restore the flag was causing independent
async blocks to effect one another, leading to strange ICEs and failed
assumptions.

Fixes rust-lang#69307

r? @Zoxc

…ion, r=ecstatic-morse

Don't lint for self-recursion when the function can diverge

Fixes rust-lang#54444

…ti865

rustc_codegen_ssa: Refactor construction of linker arguments

And add comments.

This PR doesn't reorder any linker arguments and therefore shouldn't contain any observable changes.

The next goal here is to
- Factor out order-independent linker arguments in the compiler code and in target specifications and pass them together. Such arguments generally apply to the whole linking session or the produced linking result rather to individual object files or libraries.
- Figure out where exactly among the remaining order-dependent arguments we should place customization points like `-C link-args` and `-Z pre-link-args`.
- Possibly provide command line opt-outs for options that are currently passed unconditionally (like CRT objects or arguments defined by the target spec).
- Document and stabilize the customization points that are not yet stable (rust-lang#70505).

Implement Chain with Option fuses

The iterators are now "fused" with `Option` so we don't need separate state to track which part is already exhausted, and we may also get niche layout for `None`. We don't use the real `Fuse` adapter because its specialization for `FusedIterator` unconditionally descends into the iterator, and that could be expensive to keep revisiting stuff like nested chains. It also hurts compiler performance to add more iterator layers to `Chain`.

This change was inspired by the [proposal](https://internals.rust-lang.org/t/proposal-implement-iter-chain-using-fuse/12006) on the internals forum. This is an alternate to rust-lang#70332, directly employing some of the same `Fuse` optimizations as rust-lang#70366 and rust-lang#70750.

r? @scottmcm

Support `#[track_caller]` on functions in `extern "Rust" { ... }`

Fixes rust-lang#70830 which is the follow-up to @eddyb's suggestion in rust-lang#69251 (comment) to allow `#[track_caller]` on `fn`s in FFI imports, that is, on functions in `extern "Rust" { ... }` blocks.

This requires that the other side, the FFI export, also have the `#[track_caller]` attribute. Otherwise, undefined behavior is triggered and the blame lies, as usual, with the `unsafe { ... }` block which called the FFI imported function.

After this PR, all forms of `fn` items with the right ABI (`"Rust"`) support `#[track_caller]`.

As a drive-by, the PR also hardens the check rejecting `#[naked] #[track_caller]` such that methods and other forms of `fn` items are also considered.

r? @eddyb
cc @rust-lang/lang

…vidtwco

rustc_session: forbid lints override regardless of position

Addresses the regression reported in rust-lang#70819 for command line arguments, but does not address the source code flag regression.