…ror-pattern`

Resolves Issue rust-lang#118752

in particular, this makes the `c` feature for compiler-builtins an explicit opt-in, rather than silently detected by whether `llvm-project` is checked out on disk.
exposing this is necessary because the `cc` crate doesn't support cross-compiling to MSVC, and we want people to be able to run `x check --target foo` regardless of whether they have a c toolchain available.

this also uses the new option in CI, where we *do* want to optimize compiler_builtins.

the new option is off by default for the `dev` channel and on otherwise.

add test for rust-lang#117626

Close rust-lang#117626

Promote `riscv32{im|imafc}` targets to tier 2

Pending the approval of [the MCP](rust-lang/compiler-team#701).

…, r=davidtwco

Switch from using `//~ERROR` annotations with `--error-format` to `error-pattern`

Fixes rust-lang#118752

As noticed by ``@jyn514`` while working on a patch, tests failed due to `//~ERROR` annotations used in combination with the older `--error-format` which is now `error-pattern`.

…rors

custom mir: make it clear what the return block is

Custom MIR recently got support for specifying the "unwind action", so now there's two things coming after the actual call part of `Call` terminators. That's not very self-explaining so I propose we change the syntax to imitate keyword arguments:
```
Call(popped = Vec::pop(v), ReturnTo(drop), UnwindContinue())
```

Also fix some outdated docs and add some docs to `Call` and `Drop`.

Use Result::flatten in catch_with_exit_code

Support reg_addr register class in s390x inline assembly

In s390x, `r0` cannot be used as an address register (it is evaluated as zero in an address context).

Therefore, currently, in assemblies involving memory accesses, `r0` must be [marked as clobbered](https://github.com/taiki-e/atomic-maybe-uninit/blob/1a1155653a26667396c805954ab61c8cbb14de8c/src/arch/s390x.rs#L58) or [explicitly used to a non-address](https://github.com/taiki-e/atomic-maybe-uninit/blob/1a1155653a26667396c805954ab61c8cbb14de8c/src/arch/s390x.rs#L135) or explicitly use an address register to prevent `r0` from being allocated to a register for the address.

This patch adds a register class for allocating general-purpose registers, except `r0`, to make it easier to use address registers. (powerpc already has a register class (reg_nonzero) for a similar purpose.)

This is identical to the `a` constraint in LLVM and GCC:

https://llvm.org/docs/LangRef.html#supported-constraint-code-list
> a: A 32, 64, or 128-bit integer address register (excludes R0, which in an address context evaluates as zero).

https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html
> a
> Address register (general purpose register except r0)

cc `@uweigand`

r? `@Amanieu`

…uviper

Remove libtest's dylib

libtest.so is only used by rustdoc, and tests seem to pass locally with this change. I suppose if this is broken, the only way to find out is to make a PR.

Make offset_of field parsing use metavariable which handles any spacing

As discussed at and around comments rust-lang#106655 (comment) and rust-lang#106655 (comment), the current arguments to offset_of do not accept all the whitespace combinations: `0. 1.1.1` and `0.1.1. 1` are currently treated specially in `tests/ui/offset-of/offset-of-tuple-nested.rs`.

They also do not allow [forwarding individual fields as in](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=444cdf0ec02b99e8fd5fd8d8ecb312ca)
```rust
macro_rules! off {
    ($a:expr) => {
        offset_of!(m::S, 0. $a)
    }
}
```

This PR replaces the macro arguments with `($Container:ty, $($fields:expr)+ $(,)?)` which does allow any arrangement of whitespace that I could come up with and the forwarding of fields example above.

This also allows for array indexing in the future, which I think is the last future extension to the syntax suggested in the offset_of RFC.

Tracking issue for offset_of: rust-lang#106655
`@rustbot` label F-offset_of

`@est31`

stop feed vis when cant access for trait item

Fixes rust-lang#119463

It's not necessary to feed visibility when use a private trait.

r? `@petrochenkov`

…tins, r=onur-ozkan

Reland optimized-compiler-builtins config

Copy of rust-lang#102579 PR.

From rust-lang#102579:

> No concerns on my side. Currently, Jyn isn't actively working on the project. I will close this PR; open another one to cherry-pick the commits, resolve conflicts, and then r+ it.

> Fixes rust-lang#102560. Fixes rust-lang#101172. Helps with rust-lang#105065 (although there's some weirdness there - it's still broken when optimized-compiler-builtins is set to true).

Fixes rust-lang#102560. Fixes rust-lang#101172. Helps with rust-lang#105065

r? ghost