From the test logs, other extern-fn-* tests have this:
[run-make] tests/run-make/extern-fn-with-packed-struct ... ignored, ignored when cross-compiling
[run-make] tests/run-make/extern-fn-with-union ... ignored, ignored when cross-compiling
[run-make] tests/run-make/extern-multiple-copies ... ignored, ignored when cross-compiling
[run-make] tests/run-make/extern-multiple-copies2 ... ignored, ignored when cross-compiling
[run-make] tests/run-make/extern-overrides-distribution ... ignored, ignored when cross-compiling
[run-make] tests/run-make/extra-filename-with-temp-outputs ... ignored, ignored when cross-compiling
[run-make] tests/run-make/extern-fn-explicit-align ... FAILED
alignment of `byval` on x86 in the process.
Commit 88e4d2c291 from five years ago removed
support for alignment on indirectly-passed arguments because of problems with
the `i686-pc-windows-msvc` target. Unfortunately, the `memcpy` optimizations I
recently added to LLVM 16 depend on this to forward `memcpy`s. This commit
attempts to fix the problems with `byval` parameters on that target and now
correctly adds the `align` attribute.
The problem is summarized in [this comment] by @eddyb. Briefly, 32-bit x86 has
special alignment rules for `byval` parameters: for the most part, their
alignment is forced to 4. This is not well-documented anywhere but in the Clang
source. I looked at the logic in Clang `TargetInfo.cpp` and tried to replicate
it here. The relevant methods in that file are
`X86_32ABIInfo::getIndirectResult()` and
`X86_32ABIInfo::getTypeStackAlignInBytes()`. The `align` parameter attribute
for `byval` parameters in LLVM must match the platform ABI, or miscompilations
will occur. Note that this doesn't use the approach suggested by eddyb, because
I felt it was overkill to store the alignment in `on_stack` when special
handling is really only needed for 32-bit x86.
As a side effect, this should fix#80127, because it will make the `align`
parameter attribute for `byval` parameters match the platform ABI on LLVM
x86-64.
[this comment]: https://github.com/rust-lang/rust/pull/80822#issuecomment-829985417
Don't use serde-derive in the rls shim
The already-small RLS shim can get a little smaller, and faster to
build, if we drop the serde-derive dependency and decode the one
"method" field it needs manually from `serde_json::Value`.
Remove `rustc_llvm` from llvm-stamp nags
LLVM is not *built* by `compiler/rustc_llvm` at all, only bindings on
top of it, so there's no need to bump `download-ci-llvm-stamp` for that.
Dynamically size sigaltstk in rustc
rustc installs a signal stack that assumes that MINSIGSTKSZ is a constant, unchanging value. Newer hardware undermines that assumption greatly, with register files larger than glibc's traditional static MINSIGSTKZ. Properly handle this so that it is correct on all supported Linux versions with all CPUs.
style-guide: Expand example of combinable expressions to include arrays
Arrays are allowed as combinable expressions, but none of the examples
show that.
CI: use `macos-13` runner for Apple jobs
Trying if performance of Apple CI improves with macOS 13 and SIP disabled. Speed-up:
```
x86_64-apple-1: ~2h 20m > ~1h 20m
x86_64-apple-2: ~1h 45m > ~1h 15m
```
r? `@pietroalbini`
This setting was added to match rustfmt, but it's been taking effect on
all file editing, which I notice most on git `COMMIT_EDITMSG`. I want to
keep my default 72-width commit messages, please. :)
The already-small RLS shim can get a little smaller, and faster to
build, if we drop the serde-derive dependency and decode the one
"method" field it needs manually from `serde_json::Value`.
rustc installs a signal stack that assumes that
MINSIGSTKSZ is a constant, unchanging value.
Newer hardware undermines that assumption greatly,
with register files larger than MINSIGSTKZ.
Properly handle this so that it is correct on
all supported Linux versions with all CPUs.
Replace RPITIT current impl with new strategy that lowers as a GAT
This PR replaces the current implementation of RPITITs with the new implementation that we had under -Zlower-impl-trait-in-trait-to-assoc-ty flag that lowers the RPIT as a GAT on the trait and on the impls that implement that trait.
Opening this PR as a draft because this goes after #112682, ~#112981~ and ~#112983~.
As soon as those are merged, I can rebase and we should run perf, crater and test a lot.
r? `@compiler-errors`
Add `Read`, `Write` and `Seek` impls for `Arc<File>` where appropriate
If `&T` implements these traits, `Arc<T>` has no reason not to do so
either. This is useful for operating system handles like `File` or
`TcpStream` which don't need a mutable reference to implement these
traits.
CC #53835.
CC #94744.
Rollup of 2 pull requests
Successful merges:
- #113331 (Add filter with following segment while lookup typo for path)
- #113524 (Remove the library/term exception in tidy's pal checker code)
r? `@ghost`
`@rustbot` modify labels: rollup
Add filter with following segment while lookup typo for path
From the discussion: https://github.com/rust-lang/rust/pull/112917#discussion_r1239150173
Seems we can not get the assoc items for `Struct`, `Enum` in the resolving phase.
A obvious filter is avoid suggesting the same name with the following segment path.
Use `following_seg` can extend the function `smart_resolve_partial_mod_path_errors` for more scenarios, such as `std::sync_error::atomic::AtomicBool` in test case.
r? `@estebank`
