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/
Fix#90546 by filtering out global value function pointer types from the
type tests, and adding the LowerTypeTests pass to the rustc LTO
optimization pipelines.
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:uFixes#109671.
Successful: dist-x86_64-linux, dist-aarch64-linux, dist-s390x-linux, dist-powerpc-linux, armhf-gnu, wasm32
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.
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.
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
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`
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
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`
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`
