We should symlink /usr/include/x86_64-linux-gnu/asm for the host
triple, rather than /usr/include/asm-generic, which is used in the
implementation for asm for specific triple, but shouldn't be used
by itself.

The zicsr feature has been split off from the base ISA. A newer
binutils version is required to recognize it.

These were moved into builtins by https://reviews.llvm.org/D153989.

Prevent fill from being (correctly) optimized away by passing the
address of the alloca to black_box.

Function pointer alignment is specified since https://reviews.llvm.org/D147016.

The bundled version now uses the LLVM 17 code path.

Rollup of 9 pull requests

Successful merges:

 - #113568 (Fix spurious test failure with `panic=abort`)
 - #114196 (Bubble up nested goals from equation in `predicates_for_object_candidate`)
 - #114485 (Add trait decls to SMIR)
 - #114495 (Set max_atomic_width for AVR to 16)
 - #114496 (Set max_atomic_width for sparc-unknown-linux-gnu to 32)
 - #114510 (llvm-wrapper: adapt for LLVM API changes)
 - #114562 (stabilize abi_thiscall)
 - #114570 ([miri][typo] Fix a typo in a vector_block comment.)
 - #114573 (CI: do not hide error logs in a group)

r? `@ghost`
`@rustbot` modify labels: rollup

CI: do not hide error logs in a group

This PR avoids creating a GHA group at the very end of a CI workflow when some failure has happened. Before, when a failure has happened, its GHA group was not closed, however the clock drift check function would create a new group, which would actually close the group containing the error log, thus making errors hidden by default, which is not ideal.

See discussion here: https://rust-lang.zulipchat.com/#narrow/stream/326414-t-infra.2Fbootstrap/topic/GHA.20groups.20being.20closed.20on.20failures

r? bootstrap

[miri][typo] Fix a typo in a vector_block comment.

stabilize abi_thiscall

Closes https://github.com/rust-lang/rust/issues/42202, stabilizing the use of the "thiscall" ABI.

FCP was substituted by a poll, and the poll has been accepted.

llvm-wrapper: adapt for LLVM API changes

No functional changes intended.

Adapts llvm-wrapper for https://github.com/llvm/llvm-project/commit/65e57bbed06d55cab7bb64d54891d33ccb2d4159.

Found by our experimental rust + llvm @ HEAD CI:
https://buildkite.com/llvm-project/rust-llvm-integrate-prototype/builds/21304#0189c526-86cd-4db9-bdbc-dd0132dfc22b/197-500

Set max_atomic_width for sparc-unknown-linux-gnu to 32

This is currently set to 64

https://github.com/rust-lang/rust/blob/90f0b24ad3e7fc0dc0e419c9da30d74629cd5736/compiler/rustc_target/src/spec/sparc_unknown_linux_gnu.rs#L8

However, AFAIK, this architecture doesn't support 64-bit atomics, and LLVM generates libcalls: https://godbolt.org/z/chzThWGG1

(Currently, attempts to run `cargo test` for this target result in "undefined reference to `__sync_val_compare_and_swap_8'" error. https://github.com/taiki-e/rust-cross-toolchain/commit/02efe1e74f2280f06662eaf275690883b2f9c7ae)

r? `@Amanieu`

Set max_atomic_width for AVR to 16

This is currently set to 0

https://github.com/rust-lang/rust/blob/90f0b24ad3e7fc0dc0e419c9da30d74629cd5736/compiler/rustc_target/src/spec/avr_gnu_base.rs#L26-L27

However, LLVM supports {8,16}-bit atomic load/store on AVR (support for RMW is still quite incomplete and only partially supported).

https://github.com/llvm/llvm-project/blob/llvmorg-15.0.0/llvm/test/CodeGen/AVR/atomics/load8.ll#L5-L13
https://github.com/llvm/llvm-project/blob/llvmorg-15.0.0/llvm/test/CodeGen/AVR/atomics/load16.ll#L3-L12
https://github.com/llvm/llvm-project/blob/llvmorg-15.0.0/llvm/test/CodeGen/AVR/atomics/store.ll#L3-L22

cc #99668

r? `@Amanieu`

Add trait decls to SMIR

r? `@oli-obk`

Closes https://github.com/rust-lang/project-stable-mir/issues/20

Bubble up nested goals from equation in `predicates_for_object_candidate`

This used to be needed for https://github.com/rust-lang/rust/pull/114036#discussion_r1273987510, but since it's no longer, I'm opening this as a separate PR. This also fixes one ICEing UI test: (`tests/ui/unboxed-closures/issue-53448.rs`)

r? `@lcnr`

Fix spurious test failure with `panic=abort`

Description on why it happens and why the fix should work is in the code comments.

Make `unconditional_recursion` warning detect recursive drops

Closes #55388

Also closes #50049 unless we want to keep it for the second example which this PR does not solve, but I think it is better to track that work in #57965.

r? `@oli-obk` since you are the mentor for #55388

Unresolved questions:
- [x] There are two false positives that must be fixed before merging (see diff). I suspect the best way to solve them is to perform analysis after drop elaboration instead of before, as now, but I have not explored that any further yet. Could that be an option? **Answer:** Yes, that solved the problem.

`@rustbot` label +T-compiler +C-enhancement +A-lint

⬆ `rust-analyzer`

r? `@ghost`

update Miri

Rollup of 8 pull requests

Successful merges:

 - #98935 (Implement `Option::take_if`)
 - #114093 (Add regression test for `echo 'mod unknown;' | rustc -`)
 - #114229 (Nest tests/codegen/sanitizer*.rs tests in sanitizer dir)
 - #114230 (Nest other codegen test topics)
 - #114362 (string.rs: remove "Basic usage" text)
 - #114365 (str.rs: remove "Basic usage" text)
 - #114382 (Add a new `compare_bytes` intrinsic instead of calling `memcmp` directly)
 - #114549 (Style fix and refactor on resolve diagnostics)

r? `@ghost`
`@rustbot` modify labels: rollup

Style fix and refactor on resolve diagnostics

- coding style
- refactor api of `span_look_ahead`

Add a new `compare_bytes` intrinsic instead of calling `memcmp` directly

As discussed in #113435, this lets the backends be the place that can have the "don't call the function if n == 0" logic, if it's needed for the target.  (I didn't actually *add* those checks, though, since as I understood it we didn't actually need them on known targets?)

Doing this also let me make it `const` (unstable), which I don't think `extern "C" fn memcmp` can be.

cc `@RalfJung` `@Amanieu`

str.rs: remove "Basic usage" text

Only one example is given

string.rs: remove "Basic usage" text

Only a single example is given

Nest other codegen test topics

This PR is like rust-lang/rust#114229 in that it mostly pushes codegen tests around, shoving them into their own directories, but because all of the changes are very simple cleanups I pulled them into a separate PR. The other PR might involve actually evaluating the correctness of the test after changes, but here it is mostly a matter of taste. The only "functional" change is deleting a few tests that... hinge on a version of LLVM that we don't support (as of rust-lang/rust#114148 anyways).

I considered a few different ways to group other topics but I feel the question of whether `tests/codegen/{vec,array,slice}` should exist is more subtle than these choices, as it might be better to group such related tests by other topics like bounds check elision, thus I avoided making it.

Nest tests/codegen/sanitizer*.rs tests in sanitizer dir

The sanitizer tests are the largest and most meticulously tested set of tests in tests/codegen. That's good! They all clearly belong to a subject and thus could go in a directory, but are not, instead being placed simply in tests/codegen. That's bad! Fix this by placing them in their own directory and renaming them to be less repetitive after that move.

A few tests are brittle, and embed their filename in the test's checks. This is acceptable for the ones where it is used only two times, but one test embeds the test's mangled filename in the test *over 50 times*! This may have been one of the things discouraging anyone from moving it, and thus from moving the set. Fortunately, I have some knowledge of Itanium mangling (involuntarily), regex, and the FileCheck syntax. With a capturing variable, FileCheck allows us to now move this test around again without diffing it on ~50 lines, while still guaranteeing that the mangled substring is the same each time.

This also clarifies why the substring is repeated a zillion times, instead of being cryptic. They don't call it mangling because the result is pretty and easy to understand, but now it is slightly easier! Yay descriptive variables!

Add regression test for `echo 'mod unknown;' | rustc -`

Closes #65601

The bug is fixed since long ago, probably by #69838 (see https://github.com/rust-lang/rust/issues/65601#issuecomment-1650508071 for more details).
Add a regression test so we can close the issue.

Implement `Option::take_if`

Tracking issue: #98934
ACP: rust-lang/libs-team#70 [accepted]

fix(ci): Ensure idempotence of user creation

Previously, re-running `run.sh` in the same container would fail at the useradd step, because the user already exists. Instead, change that step to "create if not exists" semantics to ease interactive debugging of CI failures.

Split out from https://github.com/rust-lang/rust/pull/111891 per request by `@jackh726`

Add more context to `quit_if_file_exists` in `configure.py` & delete config.toml in CI

If the `obj` directory isn't empty, the error message is subtle and not very helpful:

```
== clock drift check ==
  local time: Sun Jul  2 00:57:06 UTC 2023
  network time: Sun, 02 Jul 2023 00:57:06 GMT
== end clock drift check ==
sccache: Starting the server...
configure: error: Existing 'config.toml' detected.
== clock drift check ==
  local time: Sun Jul  2 00:57:06 UTC 2023
  network time: Sun, 02 Jul 2023 00:57:06 GMT
== end clock drift check ==
```

This makes it stand out and suggests how to resolve the issue:

```
== clock drift check ==
  local time: Sun Jul  2 02:11:30 UTC 2023
  network time: Sun, 02 Jul 2023 02:11:31 GMT
== end clock drift check ==
sccache: Starting the server...

configure: ERROR: Existing 'config.toml' detected. Exiting
Is objdir '/home/tmgross/projects/rust/obj' clean?

== clock drift check ==
  local time: Sun Jul  2 02:11:31 UTC 2023
  network time: Sun, 02 Jul 2023 02:11:31 GMT
== end clock drift check ==
```