| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
That test causes a large amount of crashes. If a system
has a /proc/sys/kernel/core_pattern that uploads core dumps enabled,
it will take a long time to complete. Set dumpable to 0 to avoid that.
Before:
$ time ./panic-uninitialized-zeroed
real 0m47.457s
user 0m0.023s
sys 0m0.021s
After:
$ ./panic-uninitialized-zeroed
real 0m0.029s
user 0m0.019s
sys 0m0.010s
|
|
Sort mono items by symbol name
Trying to claw back cycles/branch/cache miss losses from https://github.com/rust-lang/rust/pull/144722.
|
|
|
|
r=compiler-errors
Fix test intrinsic-raw_eq-const-bad for big-endian
The test fails on s390x and presumably other big-endian systems, due to print of raw values. To fix the tests remove the raw output values in the error note with normalize-stderr.
|
|
|
|
atomicrmw on pointers: move integer-pointer cast hacks into backend
Conceptually, we want to have atomic operations on pointers of the form `fn atomic_add(ptr: *mut T, offset: usize, ...)`. However, LLVM does not directly support such operations (https://github.com/llvm/llvm-project/issues/120837), so we have to cast the `offset` to a pointer somewhere.
This PR moves that hack into the LLVM backend, so that the standard library, intrinsic, and Miri all work with the conceptual operation we actually want. Hopefully, one day LLVM will gain a way to represent these operations without integer-pointer casts, and then the hack will disappear entirely.
Cc ```@nikic``` -- this is the best we can do right now, right?
Fixes https://github.com/rust-lang/rust/issues/134617
|
|
`panic!` does not print any identifying information for threads that are
unnamed. However, in many cases, the thread ID can be determined.
This changes the panic message from something like this:
thread '<unnamed>' panicked at src/main.rs:3:5:
explicit panic
To something like this:
thread '<unnamed>' (0xff9bf) panicked at src/main.rs:3:5:
explicit panic
Stack overflow messages are updated as well.
This change applies to both named and unnamed threads. The ID printed is
the OS integer thread ID rather than the Rust thread ID, which should
also be what debuggers print.
|
|
The tests fail on s390x and presumably other big-endian systems,
due to print of raw values and padding bytes.
To fix the tests remove the raw output values in the error note
with `normalize-stderr`.
|
|
|
|
|
|
|
|
|
|
|
|
Rollup of 12 pull requests
Successful merges:
- rust-lang/rust#141803 (Remove rustc's notion of "preferred" alignment AKA `__alignof`)
- rust-lang/rust#142053 (Add new Tier-3 targets: `loongarch32-unknown-none*`)
- rust-lang/rust#142089 (Replace all uses of sysroot_candidates with get_or_default_sysroot)
- rust-lang/rust#142108 (compiler: Add track_caller to AbiMapping::unwrap)
- rust-lang/rust#142132 (`tests/ui`: A New Order [6/N])
- rust-lang/rust#142162 (UnsafePinned: update get() docs and signature to allow shared mutation)
- rust-lang/rust#142171 (`tests/ui`: A New Order [7/N])
- rust-lang/rust#142179 (store `target.min_global_align` as an `Align`)
- rust-lang/rust#142183 (Added test for 30904)
- rust-lang/rust#142194 (Remove all unused feature gates from the compiler)
- rust-lang/rust#142199 (Do not free disk space in the `mingw-check-tidy` job)
- rust-lang/rust#142210 (Run `mingw-check-tidy` on auto builds)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
In PR 90877 T-lang decided not to remove `intrinsics::pref_align_of`.
However, the intrinsic and its supporting code
1. is a nightly feature, so can be removed at compiler/libs discretion
2. requires considerable effort in the compiler to support, as it
necessarily complicates every single site reasoning about alignment
3. has been justified based on relevance to codegen, but it is only a
requirement for C++ (not C, not Rust) stack frame layout for AIX,
in ways Rust would not consider even with increased C++ interop
4. is only used by rustc to overalign some globals, not correctness
5. can be adequately replaced by other rules for globals, as it mostly
affects alignments for a few types under 16 bytes of alignment
6. has only one clear benefactor: automating C -> Rust translation
for GNU extensions like `__alignof`
7. such code was likely intended to be `alignof` or `_Alignof`,
because the GNU extension is a "false friend" of the C keyword,
which makes the choice to support such a mapping very questionable
8. makes it easy to do incorrect codegen in the compiler by its mere
presence as usual Rust rules of alignment (e.g. `size == align * N`)
do not hold with preferred alignment
The implementation is clearly damaging the code quality of the compiler.
Thus it is within the compiler team's purview to simply rip it out.
If T-lang wishes to have this intrinsic restored for c2rust's benefit,
it would have to use a radically different implementation that somehow
does not cause internal incorrectness.
Until then, remove the intrinsic and its supporting code, as one tool
and an ill-considered GCC extension cannot justify risking correctness.
Because we touch a fair amount of the compiler to change this at all,
and unfortunately the duplication of AbiAndPrefAlign is deep-rooted,
we keep an "AbiAlign" type which we can wean code off later.
|
|
const-eval error: always say in which item the error occurred
I don't see why "is this generic" should make a difference. It may be reasonable to key this on whether the error occurs in a `const fn` that was invoked by a const (making it non-obvious which constant it is) vs inside the body of the const.
r? `@oli-obk`
|
|
|
|
|
|
also adjust the wording a little so that we don't say "the error occurred here" for two different spans
|
|
r=compiler-errors
Use non-2015 edition paths in tests that do not test for their resolution
This allows for testing these tests on editions other than 2015
|
|
Use the informative error as the main const eval error message
r? `@RalfJung`
I only did the minimal changes necessary to the const eval error machinery. I'd prefer not to mix test changes with refactorings 😆
|
|
This allows for testing these tests on editions other than 2015
|
|
|
|
|
|
This ensures that these tests can be run on editions other than 2015
|
|
|
|
|
|
|
|
|
|
|
|
instead, we can just import the intrinsics from core
|
|
|
|
intrinsics: unify rint, roundeven, nearbyint in a single round_ties_even intrinsic
LLVM has three intrinsics here that all do the same thing (when used in the default FP environment). There's no reason Rust needs to copy that historically-grown mess -- let's just have one intrinsic and leave it up to the LLVM backend to decide how to lower that.
Suggested by `@hanna-kruppe` in https://github.com/rust-lang/rust/issues/136459; Cc `@tgross35`
try-job: test-various
|
|
|
|
intrinsic
|
|
```
error: expected `{closure@...}` to return `Ret`, but it returns `Other`
```
instead of
```
error: expected `{closure@...}` to be a closure that returns `Ret`, but it returns `Other`
```
|
|
Implement `needs-subprocess` directive, and cleanup a bunch of tests to use `needs-{subprocess,threads}`
### Summary
Closes #128295.
- Implements `//@ needs-subprocess` directive in compiletest as requested in #128295. However, compiletest is a host tool, so we can't just try to spawn process because that spawns the process on *host*, not the *target*, under cross-compilation scenarios.
- The short-term solution is to add *Yet Another* list of allow-list targets.
- The long-term solution is to first check if a `$target` supports std, then try to run a binary to do run-time capability detection *on the target*. But that is tricky because you have to build-and-run a binary *for the target*.
- This PR picks the short-term solution, because the long-term solution is highly non-trivial, and it's already an improvement over individual `ignore-*`s all over the place.
- Opened an issue about the long-term solution in #135928.
- Documents `//@ needs-subprocess` in rustc-dev-guide.
- Replace `ignore-{wasm,wasm32,emscripten,sgx}` with `needs-{subprocess,threads}` where suitable in tests.
- Some drive-by test changes as I was trying to figure out if I could use `needs-{subprocess,threads}` and found some bits needlessly distracting.
Count of tests that use `ignore-{wasm,wasm32,emscripten,sgx}` before and after this PR:
| State | `ignore-sgx` | `ignore-wasm` | `ignore-emscripten` |
| - | - | - | - |
| Before this PR | 96 | 88 | 207 |
| After this PR | 36 | 38 | 61 |
<details>
<summary>Commands used to find out locally</summary>
```
--- before
[17:40] Joe:rust (fresh) | rg --no-ignore -l "ignore-sgx" tests | wc -l
96
[17:40] Joe:rust (fresh) | rg --no-ignore -l "ignore-wasm" tests | wc -l
88
[17:40] Joe:rust (fresh) | rg --no-ignore -l "ignore-emscripten" tests | wc -l
207
--- after
[17:39] Joe:rust (needs-subprocess-thread) | rg --no-ignore -l "ignore-sgx" tests | wc -l
36
[17:39] Joe:rust (needs-subprocess-thread) | rg --no-ignore -l "ignore-wasm" tests | wc -l
38
[17:39] Joe:rust (needs-subprocess-thread) | rg --no-ignore -l "ignore-emscripten" tests | wc -l
61
```
</details>
### Review advice
- Best reviewed commit-by-commit.
- Non-trivial test changes (not mechanically simple replacements) are split into individual commits to help with review. Their individual commit messages give some basic description of the changes.
- I *could* split some test changes out into another PR, but I found that I needed to change some tests to `needs-threads`, some to `needs-subprocess`, and some needed to use *both*, so they might conflict and become very annoying.
---
r? ``@ghost`` (need to run try jobs)
try-job: x86_64-msvc-1
try-job: i686-msvc-1
try-job: i686-mingw
try-job: x86_64-mingw-1
try-job: x86_64-apple-1
try-job: aarch64-apple
try-job: aarch64-gnu
try-job: test-various
try-job: armhf-gnu
|
|
|
|
|
|
rustc_intrinsic: support functions without body
We synthesize a HIR body `loop {}` but such bodyless intrinsics.
Most of the diff is due to turning `ItemKind::Fn` into a brace (named-field) enum variant, because it carries a `bool`-typed field now. This is to remember whether the function has a body. MIR building panics to avoid ever translating the fake `loop {}` body, and the intrinsic logic uses the lack of a body to implicitly mark that intrinsic as must-be-overridden.
I first tried actually having no body rather than generating the fake body, but there's a *lot* of code that assumes that all function items have HIR and MIR, so this didn't work very well. Then I noticed that even `rustc_intrinsic_must_be_overridden` intrinsics have MIR generated (they are filled with an `Unreachable` terminator) so I guess I am not the first to discover this. ;)
r? `@oli-obk`
|
|
as must-be-overridden
|
|
|
|
|
|
|
|
blesses tests/ui/intrinsics
blesses tests/ui/intrinsics
|
|
|
|
functions instead
|
|
|
|
|
