| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
This updates RustWrapper.cpp and tests after
https://github.com/llvm/llvm-project/pull/123181
|
|
optimize slice::ptr_rotate for small rotates
r? `@scottmcm`
This swaps the positions and numberings of algorithms 1 and 2 in `slice::ptr_rotate`, and pulls the entire outer loop into algorithm 3 since it was redundant for the first two. Effectively, `ptr_rotate` now always does the `memcpy`+`memmove`+`memcpy` sequence if the shifts fit into the stack buffer.
With this change, an `IndexMap`-style `move_index` function is optimized correctly.
Assembly comparisons:
- `move_index`, before: https://godbolt.org/z/Kr616KnYM
- `move_index`, after: https://godbolt.org/z/1aoov6j8h
- the code from `#89714`, before: https://godbolt.org/z/Y4zaPxEG6
- the code from `#89714`, after: https://godbolt.org/z/1dPx83axc
related to #89714
some relevant discussion in https://internals.rust-lang.org/t/idea-shift-move-to-efficiently-move-elements-in-a-vec/22184
Behavior tests pass locally. I can't get any consistent microbenchmark results on my machine, but the assembly diffs look promising.
|
|
tests: Port `translation` to rmake.rs
Part of #121876.
This PR partially supersedes #129011 and is co-authored with `@Oneirical.`
## Summary
This PR ports `tests/run-make/translation` to rmake.rs. Notable changes from the Makefile version include:
- We now actually fail if the rustc invocations fail... The Makefile did not have `SHELL=/bin/bash -o pipefail`, so all the piped rustc invocations to grep vacuously succeeded, even if the broken ftl test case actually regressed over time and ICEs on current master.
- That test case is converted to assert it fails with a FIXME backlinking to #135817.
- The test coverage is expanded to not ignore windows. Instead, the test now uses symlink capability detection to gate test execution.
- Added some backlinks to relevant tracking issues and the initial translation infra implementation PR.
## Review advice
Best reviewed commit-by-commit.
r? compiler
try-job: aarch64-apple
try-job: i686-mingw
|
|
Merge `PatKind::Path` into `PatKind::Expr`
Follow-up to #134228
We always had a duplication where `Path`s could be represented as `PatKind::Path` or `PatKind::Lit(ExprKind::Path)`. We had to handle both everywhere, and still do after #134228, so I'm removing it now.
|
|
|
|
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #133382 (Suggest considering casting fn item as fn pointer in more cases)
- #136092 (Test pipes also when not running on Windows and Linux simultaneously)
- #136190 (Remove duplicated code in RISC-V asm bad-reg test)
- #136192 (ci: remove unused windows runner)
- #136205 (Properly check that array length is valid type during built-in unsizing in index)
- #136211 (Update mdbook to 0.4.44)
- #136212 (Tweak `&mut self` suggestion span)
- #136214 (Make crate AST mutation accessible for driver callback)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
|
|
Tweak `&mut self` suggestion span
```
error[E0596]: cannot borrow `*self.s` as mutable, as it is behind a `&` reference
--> $DIR/issue-38147-1.rs:17:9
|
LL | self.s.push('x');
| ^^^^^^ `self` is a `&` reference, so the data it refers to cannot be borrowed as mutable
|
help: consider changing this to be a mutable reference
|
LL | fn f(&mut self) {
| +++
```
Note the suggestion to add `mut` instead of replacing the entire `&self` with `&mut self`.
|
|
Properly check that array length is valid type during built-in unsizing in index
This results in duplicated errors, but this class of errors is not new; in general, we aren't really equipped to detect cases where a WF error due to a field type would be shadowed by the parent struct of that field also not being WF.
This also adds a note for these types of mismatches to make it clear that this is due to an array type.
Fixes #134352
r? boxyuwu
|
|
Remove duplicated code in RISC-V asm bad-reg test
I added this test in https://github.com/rust-lang/rust/pull/132516, but I accidentally repeated the same check twice.
https://github.com/rust-lang/rust/blob/aa6f5ab18e67cb815f73e0d53d217bc54b0da924/tests/ui/asm/riscv/bad-reg.rs#L39-L42
|
|
Suggest considering casting fn item as fn pointer in more cases
Fixes #132648
|
|
|
|
|
|
|
|
Rollup of 9 pull requests
Successful merges:
- #136121 (Deduplicate operand creation between scalars, non-scalars and string patterns)
- #136134 (Fix SIMD codegen tests on LLVM 20)
- #136153 (Locate asan-odr-win with other sanitizer tests)
- #136161 (rustdoc: add nobuild typescript checking to our JS)
- #136166 (interpret: is_alloc_live: check global allocs last)
- #136168 (GCI: Don't try to eval / collect mono items inside overly generic free const items)
- #136170 (Reject unsound toggling of Arm atomics-32 target feature)
- #136176 (Render pattern types nicely in mir dumps)
- #136186 (uefi: process: Fix args)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
in inline assembly, show the supported register classes when an invalid one is found
|
|
|
|
|
|
|
|
Skip const OOM tests on AArch64 Linux through explicit annotations
instead of inside opt-dist.
Intended to avoid confusion in cases like #135952.
Prerequisite for https://github.com/rust-lang/rust/pull/135960.
|
|
Co-authored-by: Oneirical <manchot@videotron.ca>
|
|
Fixes #136103.
Based on the analysis by @jonathan-gruber-jg and @orlp.
|
|
Render pattern types nicely in mir dumps
avoid falling through to the fallback rendering that just does a hex dump
r? ``@scottmcm``
best reviewed commit by commit
|
|
GCI: Don't try to eval / collect mono items inside overly generic free const items
Fixes #136156. Thanks for the pointers, errs!
There's one (preexisting) thing of note (maybe?). There's a difference between `const _: () = panic!();` and `const _<'a>: () = panic!();`: The former is a pre-mono error, the latter is a post-mono error. For comparison, both `fn _f() { const { panic!() } }` and `fn _f<'a: 'a>() { const { panic!() } }` are post-mono errors.
cc `@oli-obk`
r? compiler-errors or reassign
|
|
Locate asan-odr-win with other sanitizer tests
|
|
Fix SIMD codegen tests on LLVM 20
The splat constants are printed differently on LLVM 20.
|
|
Rollup of 7 pull requests
Successful merges:
- #135625 ([cfg_match] Document the use of expressions.)
- #135902 (Do not consider child bound assumptions for rigid alias)
- #135943 (Rename `Piece::String` to `Piece::Lit`)
- #136104 (Add mermaid graphs of NLL regions and SCCs to polonius MIR dump)
- #136143 (Update books)
- #136147 (ABI-required target features: warn when they are missing in base CPU)
- #136164 (Refactor FnKind variant to hold &Fn)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
r=workingjubilee
ABI-required target features: warn when they are missing in base CPU
Part of https://github.com/rust-lang/rust/pull/135408:
instead of adding ABI-required features to the target we build for LLVM, check that they are already there. Crucially we check this after applying `-Ctarget-cpu` and `-Ctarget-feature`, by reading `sess.unstable_target_features`. This means we can tweak the ABI target feature check without changing the behavior for any existing user; they will get warnings but the target features behave as before.
The test changes here show that we are un-doing the "add all required target features" part. Without the full #135408, there is no way to take a way an ABI-required target feature with `-Ctarget-cpu`, so we cannot yet test that part.
Cc ``@workingjubilee``
|
|
r=lcnr
Do not consider child bound assumptions for rigid alias
r? lcnr
See first commit for the important details. For second commit, I also stacked a somewhat opinionated name change, though I can separate that if needed.
Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/149
|
|
Revert #135914: Remove usages of `QueryNormalizer` in the compiler
Reverts #135914.
r? jackh726
|
|
|
|
Rollup of 9 pull requests
Successful merges:
- #135869 (Make docs for AtomicUsize::from_mut platform-independent)
- #135892 (-Znext-solver: "normalize" signature before checking it mentions self in `deduce_closure_signature`)
- #136055 (Implement MIR const trait stability checks)
- #136066 (Pass spans to `perform_locally_in_new_solver`)
- #136071 ([Clippy] Add vec_reserve & vecdeque_reserve diagnostic items)
- #136124 (Arbitrary self types v2: explain test.)
- #136149 (Flip the `rustc-rayon`/`indexmap` dependency order)
- #136173 (Update comments and sort target_arch in c_char_definition)
- #136178 (Update username in build helper example)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
```
error[E0596]: cannot borrow `*self.s` as mutable, as it is behind a `&` reference
--> $DIR/issue-38147-1.rs:17:9
|
LL | self.s.push('x');
| ^^^^^^ `self` is a `&` reference, so the data it refers to cannot be borrowed as mutable
|
help: consider changing this to be a mutable reference
|
LL | fn f(&mut self) {
| +++
```
Note the suggestion to add `mut` instead of replacing the entire `&self` with `&mut self`.
|
|
|
|
|
|
Arbitrary self types v2: explain test.
The purpose of this test wasn't obvious, as ```@traviscross``` noted. Add a comment.
Confession: although this test was added to demonstrate this particular corner-case, I can no longer reproduce the original problem, even if I adjust `rustc` to do the "wrong" thing. I have spent several hours trying to adjust the case to trigger the "faulty" behavior with no success. This test may therefore not be as useful as it originally was. But it still seems worthwhile retaining as a regression test that we don't break things in these quirky circumstances. Ideally we'd find a new test which tests this behavior but I've failed to come up with one.
r? ```@traviscross```
|
|
Implement MIR const trait stability checks
Addresses https://github.com/rust-lang/project-const-traits/issues/16
cc ``@rust-lang/project-const-traits``
r? ``@RalfJung``
|
|
|
|
|
|
|
|
|
|
|
