| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
run-make API
|
|
|
|
|
|
|
|
of merged doctest
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
rcvalle:rust-cfi-move-cfi-ui-tests-to-cfi-directory, r=compiler-errors
CFI: Move CFI ui tests to cfi directory
Move the CFI ui tests to the cfi directory and removes the cfi prefix from tests file names similarly to how the cfi codegen tests are organized.
|
|
Refactor `powerpc64` call ABI handling
As the [specification](https://openpowerfoundation.org/specifications/64bitelfabi/) for the ELFv2 ABI states that returned aggregates are returned like arguments as long as they are at most two doublewords, I've merged the `classify_arg` and `classify_ret` functions to reduce code duplication. The only functional change is to fix #128579: the `classify_ret` function was incorrectly handling aggregates where `bits > 64 && bits < 128`. I've used the aggregate handling implementation from `classify_arg` which doesn't have this issue.
`@awilfox` could you test this on `powerpc64-unknown-linux-musl`? I'm only able to cross-test on `powerpc64-unknown-linux-gnu` and `powerpc64le-unknown-linux-gnu` locally at the moment, and as a tier 3 target `powerpc64-unknown-linux-musl` has zero CI coverage.
Fixes: #128579
|
|
miri: make vtable addresses not globally unique
Miri currently gives vtables a unique global address. That's not actually matching reality though. So this PR enables Miri to generate different addresses for the same type-trait pair.
To avoid generating an unbounded number of `AllocId` (and consuming unbounded amounts of memory), we use the "salt" technique that we also already use for giving constants non-unique addresses: the cache is keyed on a "salt" value n top of the actually relevant key, and Miri picks a random salt (currently in the range `0..16`) each time it needs to choose an `AllocId` for one of these globals -- that means we'll get up to 16 different addresses for each vtable. The salt scheme is integrated into the global allocation deduplication logic in `tcx`, and also used for functions and string literals. (So this also fixes the problem that casting the same function to a fn ptr over and over will consume unbounded memory.)
r? `@saethlin`
Fixes https://github.com/rust-lang/miri/issues/3737
|
|
Moves the CFI ui tests to the cfi directory and removes the cfi prefix
from tests file names similarly to how the cfi codegen tests are
organized.
|
|
Remove unused script from run-make tests
Its last usage was removed in https://github.com/rust-lang/rust/pull/128636.
Tracking issue: https://github.com/rust-lang/rust/issues/121876
r? jieyouxu
|
|
Store `do_not_recommend`-ness in impl header
Alternative to #128674
It's less flexible, but also less invasive. Hopefully it's also performant. I'd recommend we think separately about the design for how to gate arbitrary diagnostic attributes moving forward.
|
|
Normalize struct tail properly for `dyn` ptr-to-ptr casting in new solver
Realized that the new solver didn't handle ptr-to-ptr casting correctly.
r? lcnr
Built on #128694
|
|
|
|
r=compiler-errors
Fix bug in `Parser::look_ahead`.
The special case was failing to handle invisible delimiters on one path.
Fixes (but doesn't close until beta backported) #128895.
r? `@davidtwco`
|
|
Fix warnings in rmake tests on `x86_64-unknown-linux-gnu`
r? `@jieyouxu`
This PR fixes some warnings I saw in rmake tests. I didn't deny more warnings in this PR until `@jieyouxu` gives their opinion, but maybe we should actually deny all warnings in `rmake.rs` files?
I've also only looked at non-ignored tests on `x86_64-unknown-linux-gnu`, and denying warnings would require a try build for all targets 😓.
|
|
Fix codegen-units tests that were disabled 8 years ago
I don't know if any of these tests still have value. They were disabled by https://github.com/rust-lang/rust/pull/33890, and we've survived without them for a while. But considering how small this test suite is, maybe it's worth having them.
I also had to add some normalization to the codegen-units tests output. I think the fact that I had to add some underscores how poor our test coverage is.
|
|
Get rid of some `#[allow(rustc::untranslatable_diagnostic)]`
`@rustbot` label +A-translation
cc https://github.com/rust-lang/rust/issues/100717
|
|
const vector passed through to codegen
This allows constant vectors using a repr(simd) type to be propagated
through to the backend by reusing the functionality used to do a similar
thing for the simd_shuffle intrinsic
#118209
r? RalfJung
|
|
Unify run button display with "copy code" button and with mdbook buttons
Follow-up of https://github.com/rust-lang/rust/pull/128339.
It looks like this (coherency++, yeay!):
Can be tested [here](https://rustdoc.crud.net/imperio/run-button/foo/struct.Bar.html).
r? `@notriddle`
|
|
nontemporal_store: make sure that the intrinsic is truly just a hint
The `!nontemporal` flag for stores in LLVM *sounds* like it is just a hint, but actually, it is not -- at least on x86, non-temporal stores need very special treatment by the programmer or else the Rust memory model breaks down. LLVM still treats these stores as-if they were normal stores for optimizations, which is [highly dubious](https://github.com/llvm/llvm-project/issues/64521). Let's avoid all that dubiousness by making our own non-temporal stores be truly just a hint, which is possible on some targets (e.g. ARM). On all other targets, non-temporal stores become regular stores.
~~Blocked on https://github.com/rust-lang/stdarch/pull/1541 propagating to the rustc repo, to make sure the `_mm_stream` intrinsics are unaffected by this change.~~
Fixes https://github.com/rust-lang/rust/issues/114582
Cc `@Amanieu` `@workingjubilee`
|
|
Add range attribute to scalar function results and arguments
as LLVM 19 adds the range attribute this starts to use it for better optimization.
hade been interesting to see a perf run with the https://github.com/rust-lang/rust/pull/127513
closes https://github.com/rust-lang/rust/issues/50156
cc https://github.com/rust-lang/rust/issues/49572 shall be fixed but not possible to see as there is asserts that already trigger the optimization.
|
|
|
|
fix: #128855 Ensure `Guard`'s `drop` method is removed at `opt-level=s` for `…
fix: #128855
…Copy` types
Added `#[inline]` to the `drop` method in the `Guard` implementation to ensure that the method is removed by the compiler at optimization level `opt-level=s` for `Copy` types. This change aims to align the method's behavior with optimization expectations and ensure it does not affect performance.
r? `@scottmcm`
|
|
The special case was failing to handle invisible delimiters on one path.
Fixes #128895.
|
|
Apply "polymorphization at home" to RawVec
The idea here is to move all the logic in RawVec into functions with explicit size and alignment parameters. This should eliminate all the fussing about how tweaking RawVec code produces large swings in compile times.
This uncovered https://github.com/rust-lang/rust-clippy/issues/12979, so I've modified the relevant test in a way that tries to preserve the spirit of the test without tripping the ICE.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
r=saethlin
Fix `ElaborateBoxDerefs` on debug varinfo
Slightly simplifies the `ElaborateBoxDerefs` pass to fix cases where it was applying the wrong projections to debug var infos containing places that deref boxes.
From what I can tell[^1], we don't actually have any tests (or code anywhere, really) that exercise `debug x => *(...: Box<T>)`, and it's very difficult to trigger this in surface Rust, so I wrote a custom MIR test.
What happens is that the pass was turning `*(SOME_PLACE: Box<T>)` into `*(*((((SOME_PLACE).0: Unique<T>).0: NonNull<T>).0: *const T))` in debug var infos. In particular, notice the *double deref*, which was wrong.
This is the root cause of #128554, so this PR fixes #128554 as well. The reason that async closures was affected is because of the way that we compute the [`ByMove` body](https://github.com/rust-lang/rust/blob/master/compiler/rustc_mir_transform/src/coroutine/by_move_body.rs), which resulted in `*(...: Box<T>)` in debug var info. But this really has nothing to do with async closures.
[^1]: Validated by literally replacing the `if elem == PlaceElem::Deref && base_ty.is_box() { ... }` innards with a `panic!()`, which compiled all of stage2 without panicking.
|
|
|
|
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #128273 (Improve `Ord` violation help)
- #128807 (run-make: explaing why fmt-write-bloat is ignore-windows)
- #128903 (rustdoc-json-types `Discriminant`: fix typo)
- #128905 (gitignore: Add Zed and Helix editors)
- #128908 (diagnostics: do not warn when a lifetime bound infers itself)
- #128909 (Fix dump-ice-to-disk for RUSTC_ICE=0 users)
- #128910 (Differentiate between methods and associated functions in diagnostics)
- #128923 ([rustdoc] Stop showing impl items for negative impls)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
[rustdoc] Stop showing impl items for negative impls
Fixes https://github.com/rust-lang/rust/issues/128799.
As discussed with `@fmease,` they have a broader patch in progress, so this (small) PR will at least allow for them to have a regression test. :)
r? `@fmease`
|
|
Differentiate between methods and associated functions in diagnostics
Accurately refer to assoc fn without receiver as assoc fn instead of methods. Add `AssocItem::descr` method to centralize where we call methods and associated functions.
|
|
Fix dump-ice-to-disk for RUSTC_ICE=0 users
Before this change, the test fails if you run it with `RUSTC_ICE=0`.
|
|
r=compiler-errors
diagnostics: do not warn when a lifetime bound infers itself
Fixes #119228
|
