| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Ensure floats are returned losslessly by the Rust ABI on 32-bit x86
Solves #115567 for the (default) `"Rust"` ABI. When compiling for 32-bit x86, this PR changes the `"Rust"` ABI to return floats indirectly instead of in x87 registers (with the exception of single `f32`s, which this PR returns in general purpose registers as they are small enough to fit in one). No change is made to the `"C"` ABI as that ABI requires x87 register usage and therefore will need a different solution.
|
|
Fix `Parser::look_ahead`
`Parser::look_ahead` has a slow but simple general case, and a fast special case that is hit most of the time. But the special case is buggy and behaves differently to the general case. There are also no unit tests. This PR fixes all of this, resulting in a `Parser::look_ahead` that is equally fast, slightly simpler, more correct, and better tested.
r? `@davidtwco`
|
|
Rollup of 8 pull requests
Successful merges:
- #124980 (Generalize `fn allocator` for Rc/Arc.)
- #126639 (Add AMX target-features and `x86_amx_intrinsics` feature flag)
- #126827 (Use pidfd_spawn for faster process spawning when a PidFd is requested)
- #127433 (Stabilize const_cstr_from_ptr (CStr::from_ptr, CStr::count_bytes))
- #127552 (remove unnecessary `git` usages)
- #127613 (Update dist-riscv64-linux to binutils 2.40)
- #127627 (generalize search graph to enable fuzzing)
- #127648 (Lower timeout of CI jobs to 4 hours)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Lower timeout of CI jobs to 4 hours
The previous value, 10 hours, is unnecessarily long, since most of our jobs finish within 2.5 hours currently. This could help us detect abnormally long CI runs.
r? ``@pietroalbini``
|
|
generalize search graph to enable fuzzing
I do not believe it to be feasible to correctly implement the search graph without fuzzing. This PR enables this by requiring a fuzzer to only implement three new traits:
- `Cx`: implemented by all `I: Interner`
- `ProofTreeBuilder`: implemented by `struct ProofTreeBuilder<D>` for all `D: SolverDelegate`
- `Delegate`: implemented for a new `struct SearchGraphDelegate<D>` for all `D: SolverDelegate`
It also moves the evaluation cache implementation into `rustc_type_ir`, requiring `Interner` to provide methods to create and access arbitrary `WithDepNode<T>` and to provide mutable access to a given `GlobalCache`. It otherwise does not change the API surface for users of the shared library.
This change should not impact behavior in any way.
r? ``@compiler-errors``
|
|
Update dist-riscv64-linux to binutils 2.40
binutils 2.40 is required by LLVM 19, as older versions do not know about the zmmul extension.
I've had to backport some patches to glibc and gcc as well, as they don't build with binutils 2.40. Alternatively, we could also switch to glibc 2.35 and gcc 10 (I think). I figured we'd want to avoid the glibc version change, but if that's fine for riscv I can go with that instead.
r? `````@cuviper`````
try-job: dist-riscv64-linux
|
|
remove unnecessary `git` usages
`Config::src` already contains the top-level path, so we don't need to add git overhead just to reach this path.
|
|
Stabilize const_cstr_from_ptr (CStr::from_ptr, CStr::count_bytes)
Completed the pair of FCPs https://github.com/rust-lang/rust/issues/113219#issuecomment-2016939401 + https://github.com/rust-lang/rust/issues/114441#issuecomment-2016942566.
`CStr::from_ptr` is covered by just the first FCP on its own. `CStr::count_bytes` requires the approval of both FCPs. The second paragraph of the first link and the last paragraph of the second link explain the relationship between the two FCPs. As both have been approved, we can proceed with stabilizing `const` on both of these already-stable functions.
|
|
Use pidfd_spawn for faster process spawning when a PidFd is requested
glibc 2.39 added `pidfd_spawnp` and `pidfd_getpid` which makes it possible to get pidfds while staying on the CLONE_VFORK path.
verified that vfork gets used with strace:
```
$ strace -ff -e pidfd_open,clone3,openat,execve,waitid,close ./x test std --no-doc -- pidfd
[...]
[pid 2820532] clone3({flags=CLONE_VM|CLONE_PIDFD|CLONE_VFORK|CLONE_CLEAR_SIGHAND, pidfd=0x7b7f885fec6c, exit_signal=SIGCHLD, stack=0x7b7f88aff000, stack_size=0x9000}strace: Process 2820533 attached
<unfinished ...>
[pid 2820533] execve("/home/the8472/bin/sleep", ["sleep", "1000"], 0x7ffdd0e268d8 /* 107 vars */) = -1 ENOENT (No such file or directory)
[pid 2820533] execve("/home/the8472/.cargo/bin/sleep", ["sleep", "1000"], 0x7ffdd0e268d8 /* 107 vars */) = -1 ENOENT (No such file or directory)
[pid 2820533] execve("/usr/local/bin/sleep", ["sleep", "1000"], 0x7ffdd0e268d8 /* 107 vars */) = -1 ENOENT (No such file or directory)
[pid 2820533] execve("/usr/bin/sleep", ["sleep", "1000"], 0x7ffdd0e268d8 /* 107 vars */ <unfinished ...>
[pid 2820532] <... clone3 resumed> => {pidfd=[3]}, 88) = 2820533
[pid 2820533] <... execve resumed>) = 0
[pid 2820532] openat(AT_FDCWD, "/proc/self/fdinfo/3", O_RDONLY|O_CLOEXEC) = 4
[pid 2820532] close(4) = 0
```
Tracking issue: #82971
|
|
Add AMX target-features and `x86_amx_intrinsics` feature flag
This is an effort towards #126622. This adds support for all 5 target-features for `AMX`, and introduces the feature flag `x86_amx_intrinsics`, which would gate these target-features and the yet-to-be-implemented amx intrinsics in stdarch.
|
|
Generalize `fn allocator` for Rc/Arc.
Split out from #119761
- For `Rc`/`Arc`, the existing associated `fn`s are changed to allow unsized pointees.
- For `Weak`s, new methods are added.
`````@rustbot````` label +A-allocators
|
|
Use rustc-stable-hash in the compiler
Following https://github.com/rust-lang/compiler-team/issues/755 and the release of the crate on crates.io, let's now use it in the compiler and remove the old implementation.
cc `@michaelwoerister`
r? ghost
|
|
fully move it into `rustc_type_ir` and make it
independent of `Interner`.
|
|
|
|
The previous value, 10 hours, is unnecessarily long, since most of our jobs finish within 2.5 hours currently.
|
|
A `rustc_const_stable` attribute by itself has nonintuitive purpose when
placed in a public module.
Separately, it would probably be okay to rename `const_strlen` to just
`strlen` to make it more clear this is our general-purpose
implementation of strlen now, not something specifically for const
(avoiding confusion like in PR 127444).
|
|
Rollup of 6 pull requests
Successful merges:
- #127164 (match lowering: Clarify the main loop of the algorithm)
- #127422 (as_simd: fix doc comment to be in line with align_to)
- #127596 (More suggestion for converting `Option<&Vec<T>>` to `Option<&[T]>`)
- #127607 (compiletest: Better error message for bad `normalize-*` headers)
- #127622 (Mark `builtin_syntax` as internal)
- #127625 (Revert accidental comment deletion)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
This new special case is simpler than the old special case because it
only is used when `dist == 1`. But that's still enough to cover ~98% of
cases. This results in equivalent performance to the old special case,
and identical behaviour as the general case.
|
|
The general case at the bottom of `look_ahead` is slow, because it
clones the token cursor. Above it there is a special case for
performance that is hit most of the time and avoids the cloning.
Unfortunately, its behaviour differs from the general case in two ways.
- When within a pair of delimiters, if you look any distance past the
closing delimiter you get the closing delimiter instead of what comes
after the closing delimiter.
- It uses `tree_cursor.look_ahead(dist - 1)` which totally confuses
tokens with token trees. This means that only the first token in a
token tree will be seen. E.g. in a sequence like `{ a }` the `a` and
`}` will be skipped over. Bad!
It's likely that these differences weren't noticed before now because
the use of `look_ahead` in the parser is limited to small distances and
relatively few contexts.
Removing the special case causes slowdowns up of to 2% on a range of
benchmarks. The next commit will add a new, correct special case to
regain that lost performance.
|
|
It's currently buggy, so some of the test results are surprising, as
described in the `FIXME` comments. The bugs will be fixed in subsequent
commits.
|
|
|
|
Revert accidental comment deletion
This reverts an accidental comment deletion made in #113128
See also https://github.com/rust-lang/rust/pull/113128#discussion_r1674614882
|
|
Mark `builtin_syntax` as internal
Tracking issue literally says:
> There will never be a general stabilization.
cc #110680 `@est31`
|
|
compiletest: Better error message for bad `normalize-*` headers
Follow-up to #126777.
Example of the new error message in context:
```text
---- [ui] tests/ui/rfcs/rfc-2632-const-trait-impl/effects/minicore.rs stdout ----
thread '[ui] tests/ui/rfcs/rfc-2632-const-trait-impl/effects/minicore.rs' panicked at src/tools/compiletest/src/header.rs:1001:13:
couldn't parse custom normalization rule: `normalize-stderr-test ".*note: .*\n\n" -> ""`
help: expected syntax is: `normalize-stderr-test: "REGEX" -> "REPLACEMENT"`
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
|
|
More suggestion for converting `Option<&Vec<T>>` to `Option<&[T]>`
Please review commit-by-commit.
|
|
as_simd: fix doc comment to be in line with align_to
In #121201, the guarantees about `align_offset` and `align_to` were changed. This PR aims to correct the doc comment of `as_simd` to be in line with the new `align_to`.
Tagging #86656 for good measure.
|
|
match lowering: Clarify the main loop of the algorithm
Now that we expand or-patterns in a single place in the algorithm, we can move it (back) to the main part of the loop. This makes the call-graph of the main loop rather simple: `match_candidates` has three branches that each call back to `match_candidates`. The remaining tricky part is `finalize_or_candidate`.
I also factored out the whole "process a prefix of the candidates then process the rest" thing which I think helps legibility.
The first two commits are a fix for an indexing mistake I introduced in https://github.com/rust-lang/rust/pull/126553, already sumitted in https://github.com/rust-lang/rust/pull/127028 but feel free to merge this first.
r? `@matthewjasper`
|
|
Use verbose style when suggesting changing `const` with `let`
|
|
Rollup of 8 pull requests
Successful merges:
- #124599 (Suggest borrowing on fn argument that is `impl AsRef`)
- #127572 (Don't mark `DEBUG_EVENT` struct as `repr(packed)`)
- #127588 (core: Limit remaining f16 doctests to x86_64 linux)
- #127591 (Make sure that labels are defined after the primary span in diagnostics)
- #127598 (Allows `#[diagnostic::do_not_recommend]` to supress trait impls in suggestions as well)
- #127599 (Rename `lazy_cell_consume` to `lazy_cell_into_inner`)
- #127601 (check is_ident before parse_ident)
- #127605 (Remove extern "wasm" ABI)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
|
|
Clippy subtree update
r? `@Manishearth`
|
|
|
|
|
|
|
|
|
|
|
|
Remove extern "wasm" ABI
Remove the unstable `extern "wasm"` ABI (`wasm_abi` feature tracked in #83788).
As discussed in https://github.com/rust-lang/rust/pull/127513#issuecomment-2220410679 and following, this ABI is a failed experiment that did not end up being used for anything. Keeping support for this ABI in LLVM 19 would require us to switch wasm targets to the `experimental-mv` ABI, which we do not want to do.
It should be noted that `Abi::Wasm` was internally used for two things: The `-Z wasm-c-abi=legacy` ABI that is still used by default on some wasm targets, and the `extern "wasm"` ABI. Despite both being `Abi::Wasm` internally, they were not the same. An explicit `extern "wasm"` additionally enabled the `+multivalue` feature.
I've opted to remove `Abi::Wasm` in this patch entirely, instead of keeping it as an ABI with only internal usage. Both `-Z wasm-c-abi` variants are now treated as part of the normal C ABI, just with different different treatment in
adjust_for_foreign_abi.
|
|
check is_ident before parse_ident
Closes #127600
|
|
Rename `lazy_cell_consume` to `lazy_cell_into_inner`
Name this something that is less confusable with an atomic consume API for `{Lazy,Once}Lock`.
|
|
weiznich:diagnostic_do_not_recommend_also_skips_help, r=compiler-errors
Allows `#[diagnostic::do_not_recommend]` to supress trait impls in suggestions as well
This commit changes the error reporting mechanism for not implemented traits to skip impl marked as `#[diagnostic::do_not_recommend]` in the help part of the error message ("the following other types implement trait `Foo`:"). The main use case here is to allow crate authors to skip non-meaningful confusing suggestions. A common example for this are fully generic impls on tuples.
Related to https://github.com/rust-lang/rust/issues/51992
r? `@compiler-errors`
|
|
Make sure that labels are defined after the primary span in diagnostics
Putting a `#[label]` before a `#[primary_span]` results in that label being overwritten, due to the semantics of `Diagnostic::span` and the fact that labels are stored in the `MultiSpan` of the diagnostic.
This isn't possible to fix in general, since a lot of code actually *relies* in this overwriting behavior (e.g. `rustc_on_unimplemented`). However, it's useful to enforce this for derive-diagnostics, since this is certainly never what you intend to do in a derived diagnostic, where all the fields are meaningful parts of the diagnostic being rendered.
This only matters for `#[label]`, since those are the ones stored in the `MultiSpan` of the error.
We could also make this "just work" by sorting the attrs or processing the primary span attr first, however I think it's kinda pointless to do.
There was 1 case where this mattered, but we literally didn't have a test exercising that diagnostic 🙃
|
|
core: Limit remaining f16 doctests to x86_64 linux
On s390x, every use of the f16 data type will currently ICE due to https://github.com/llvm/llvm-project/issues/50374, causing doctest failures on the platform.
Most doctests were already restricted to certain platforms, so fix this by likewise restricting the remaining five.
|
|
Don't mark `DEBUG_EVENT` struct as `repr(packed)`
That would give it alignment of 1 which is ABI-incompatible with its C definition.
|
|
Suggest borrowing on fn argument that is `impl AsRef`
When encountering a move conflict, on an expression that is `!Copy` passed as an argument to an `fn` that is `impl AsRef`, suggest borrowing the expression.
```
error[E0382]: use of moved value: `bar`
--> f204.rs:14:15
|
12 | let bar = Bar;
| --- move occurs because `bar` has type `Bar`, which does not implement the `Copy` trait
13 | foo(bar);
| --- value moved here
14 | let baa = bar;
| ^^^ value used here after move
|
help: borrow the value to avoid moving it
|
13 | foo(&bar);
| +
```
Fix #41708
|
|
binutils 2.40 is required by LLVM 19, as older versions do not
know about the zmmull extension.
I've had to backport some patches to glibc and gcc as well,
as they don't build with binutils 2.40. Alternatively, we could
also switch to glibc 2.35 and gcc 12 (I think). I figured we'd
want to avoid the glibc version change, but if that's fine for
riscv I can go with that instead.
|
|
|
|
Add `f16` and `f128` as simd types in LLVM
`@sayantn` is working on adding SIMD for `f16` and hitting the `FloatingPointVector` error. This should fix it and unblock adding support for `simd_fma` and `simd_fabs` in stdarch.
|
|
clippy-subtree-update
|
