rustc_interface: Dismantle `register_plugins` query

It did three independent things:
- Constructed `LintStore`
- Prepared incremental directories and dep graph
- Initialized some fields in `Session`

The `LintStore` construction (now `passes::create_lint_store`)  is more or less left in place.

The incremental stuff is now moved into `fn dep_graph_future`.
This helps us to start loading the dep graph a bit earlier.

The `Session` field initialization is moved to tcx construction point.
Now that tcx is constructed early these fields don't even need to live in `Session`, they can live in tcx instead and be initialized at its creation (see the FIXME).

Three previously existing `rustc_interface` queries are de-querified (`register_plugins`, `dep_graph_future`, `dep_graph`) because they are only used locally in `fn global_ctxt` and their results don't need to be saved elsewhere.

On the other hand, `crate_types` and `stable_crate_id` are querified.
They are used from different places and their use is very similar to the existing `crate_name` query in this regard.

Rollup of 7 pull requests

Successful merges:

 - #114376 (Avoid exporting __rust_alloc_error_handler_should_panic more than once.)
 - #114413 (Warn when #[macro_export] is applied on decl macros)
 - #114497 (Revert #98333 "Re-enable atomic loads and stores for all RISC-V targets")
 - #114500 (Remove arm crypto target feature)
 - #114566 (Store the laziness of type aliases in their `DefKind`)
 - #114594 (Structurally normalize weak and inherent in new solver)
 - #114596 (Rename method in `opt-dist`)

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

Rename method in `opt-dist`

This makes it clearer that the LLVM is the host one (it doesn't necessarily have to be downloaded). On Linux, it comes from the Dockerfile, on Windows it's downloaded.

Suggested here: https://github.com/rust-lang/rust/pull/114344#discussion_r1285596217

r? `@lqd`

Structurally normalize weak and inherent in new solver

It seems pretty obvious to me that we should be normalizing weak and inherent aliases too, since they can always be normalized. This PR still leaves open the question of what to do with opaques, though 💀

**Also**, we need to structurally resolve the target of a coercion, for the UI test to work.

r? `@lcnr`

Store the laziness of type aliases in their `DefKind`

Previously, we would treat paths referring to type aliases as *lazy* type aliases if the current crate had lazy type aliases enabled independently of whether the crate which the alias was defined in had the feature enabled or not.

With this PR, the laziness of a type alias depends on the crate it is defined in. This generally makes more sense to me especially if / once lazy type aliases become the default in a new edition and we need to think about *edition interoperability*:

Consider the hypothetical case where the dependency crate has an older edition (and thus eager type aliases), it exports a type alias with bounds & a where-clause (which are void but technically valid), the dependent crate has the latest edition (and thus lazy type aliases) and it uses that type alias. Arguably, the bounds should *not* be checked since at any time, the dependency crate should be allowed to change the bounds at will with a *non*-major version bump & without negatively affecting downstream crates.

As for the reverse case (dependency: lazy type aliases, dependent: eager type aliases), I guess it rules out anything from slight confusion to mild annoyance from upstream crate authors that would be caused by the compiler ignoring the bounds of their type aliases in downstream crates with older editions.

---

This fixes #114468 since before, my assumption that the type alias associated with a given weak projection was lazy (and therefore had its variances computed) did not necessarily hold in cross-crate scenarios (which [I kinda had a hunch about](https://github.com/rust-lang/rust/pull/114253#discussion_r1278608099)) as outlined above. Now it does hold.

`@rustbot` label F-lazy_type_alias
r? `@oli-obk`

Remove arm crypto target feature

Follow-up to https://github.com/rust-lang/stdarch/pull/1407.

LLVM has moved away from a combined `crypto` feature on both aarch64 and arm, and we did the same on aarch64, but were deferred from doing the same on arm due to compatibility with older LLVM.

As the minimum LLVM version has increased, we can now remove this (unstable) target feature on arm.

r? `@Amanieu`

Revert #98333 "Re-enable atomic loads and stores for all RISC-V targets"

This reverts #98333.

As said in https://github.com/rust-lang/rust/pull/98333#issuecomment-1666375293, `forced-atomics` target feature is also needed to enable atomic load/store on these targets (otherwise, libcalls are generated): https://godbolt.org/z/433qeG7vd

However, `forced-atomics` target feature is currently broken (https://github.com/rust-lang/rust/issues/114153), so AFAIK, there is currently no way to enable atomic load/store (via core::intrinsics) on these targets properly.

r? `@Amanieu`

Warn when #[macro_export] is applied on decl macros

The existing code checks if `#[macro_export]` is being applied to an item other than a macro, and warns in that case, but fails to take into account macros 2.0/decl macros, despite the attribute having no effect on these macros.

This PR adds a special case for decl macros with the aforementioned attribute, so that the warning is a bit more precise. Instead of just saying "this attribute has no effect", hint towards the fact that decl macros get exported and resolved like regular items.
It also removes a `#[macro_export]` attribute which was applied on one of `core`'s decl macros.

- core: Remove #[macro_export] from `debug_assert_matches`
- check_attrs: Warn when #[macro_export] is used on macros 2.0

Avoid exporting __rust_alloc_error_handler_should_panic more than once.

Exporting `__rust_alloc_error_handler_should_panic` multiple times causes `ld.gold` to balk with: `error: version script assignment of  to symbol __rust_alloc_error_handler_should_panic failed: symbol not defined`

Specifically this breaks builds of 1.70.0 and newer on DragonFly and YoctoProject with `ld.gold`.  Builds with `ld.bfd` and `lld` should be unaffected.

http://errors.yoctoproject.org/Errors/Details/708194/

Update to LLVM 17

Expected LLVM 17.0.0 release date: Sep 5th
Rust 1.73 release date: Oct 5th

Compatibility changes in this PR:
 - Drop LLVM_RUSTLLVM check for target-cpu table, which no longer requires a patch with LLVM 17.
 - Update powerpc data layouts, which now include function alignment information. As usual, downgrade for older LLVM versions.
 - Adjust the stack-protector.rs test so that the stack smashing does not get optimized away.
 - Adjust path of crtbegin.c and crtend.c in compiler-rt.
 - Updated dist-riscv64-linux to use binutils 2.36 in order to recognize the zicsr feature, which is no longer part of the base ISA.
 - Fixed symlink for asm include directory on dist-various-2. We should use `/usr/include/x86_64-linux-gnu/asm` for the host, rather than `/usr/include/asm-generic`.

Upstream patches:
 - [x] https://reviews.llvm.org/D156525 (backported)

Perf run: https://perf.rust-lang.org/compare.html?start=f239bb6bea94d16d902c36d72b5cabdddefb3cab&end=8030d71a95a3ea79f5fc95232c32f9b78effb92d&stat=instructions:u

Fixes #109671.

Successful: dist-x86_64-linux, dist-aarch64-linux, dist-s390x-linux, dist-powerpc-linux, armhf-gnu, wasm32

This makes it clearer that the LLVM is the host one (it doesn't necessarily have to be downloaded).

The compiler should emit a more specific error when the `#[macro_export]`
attribute is present on a decl macro, instead of silently ignoring it.

This commit adds the required error message in rustc_passes/messages.ftl,
 as well as a note. A new variant is added to the `errors::MacroExport`
enum, specifically for the case where the attribute is added to a macro
2.0.

The `debug_assert_matches` macro was marked with the `#[macro_export]` attribute,
despite being a declarative macro/macro 2.0, for which the exporting rules are similar
to items. In fact, `#[macro_export]` on a decl macro has no effect on its visibility.

These types changed in LLVM 18, not LLVM 17.

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.

Use the correct `llvm-profdata` binary in `opt-dist`

Turns out that we were probably using the wrong `llvm-profdata` binary in the PGO script all along. This should resolve the performance regressions of switching the host LLVM to 17 ([host `llvm-profdata`](https://github.com/rust-lang/rust/pull/114297#issuecomment-1660521361), [target `llvm-profdata`](https://github.com/rust-lang/rust/pull/114297#issuecomment-1661127032)]).

r? `@nikic`

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