| Age | Commit message (Collapse) | Author | Lines |
|---|
|
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`
|
|
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
|
|
run-make: explaing why fmt-write-bloat is ignore-windows
The trouble here is that libc doesn't exist on Windows. Well it kinda does but it isn't called that so we substitute a name that works. Ideally finding necessary libs for the platform would be done at a higher level but until then this should work.
try-job: x86_64-msvc
try-job: x86_64-mingw
try-job: i686-msvc
try-job: i686-mingw
|
|
|
|
|
|
|
|
|
|
WF-check struct field types at construction site
Fixes #126272.
Fixes #127299.
Rustc of course already WF-checked the field types at the definition
site, but for error tainting of consts to work properly, there needs to
be an error emitted at the use site. Previously, with no use-site error,
we proceeded with CTFE and ran into ICEs since we are running code with
type errors.
Emitting use-site errors also brings struct-like constructors more in
line with fn-like constructors since they already emit use-site errors
for WF issues.
r? `@BoxyUwU`
|
|
This commit adds a new test file 'array-from_fn.rs' to the codegen test suite.
The test checks the behavior of std::array::from_fn under different optimization levels:
1. At opt-level=0 (debug build), it verifies that the core::array::Guard
is present in the generated code.
2. At opt-level=s (size optimization), it ensures that the Guard is
optimized out.
This test helps ensure that the compiler correctly optimizes array::from_fn
calls in release builds while maintaining safety checks in debug builds.
|
|
Add a set of tests for LLVM 19
Close #107681. Close #118306. Close #126585.
r? compiler
|
|
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.
|
|
|
|
|
|
|
|
Enable zstd for debug compression.
Set LLVM_ENABLE_ZSTD alongside LLVM_ENABLE_ZLIB so that --compress-debug-sections=zstd is an option.
See #120953
try-job: x86_64-gnu-tools
|
|
|
|
|
|
Ensure let stmt compound assignment removal suggestion respect codepoint boundaries
Previously we would try to issue a suggestion for `let x <op>= 1`, i.e.
a compound assignment within a `let` binding, to remove the `<op>`. The
suggestion code unfortunately incorrectly assumed that the `<op>` is an
exactly-1-byte ASCII character, but this assumption is incorrect because
we also recover Unicode-confusables like `➖=` as `-=`. In this example,
the suggestion code used a `+ BytePos(1)` to calculate the span of the
`<op>` codepoint that looks like `-` but the mult-byte Unicode
look-alike would cause the suggested removal span to be inside a
multi-byte codepoint boundary, triggering a codepoint boundary
assertion.
The fix is to use `SourceMap::start_point(token_span)` which properly accounts for codepoint boundaries.
Fixes #128845.
cc #128790
r? ````@fmease````
|
|
Use `SourceMap::end_point` instead of `- BytePos(1)` in arg removal suggestion
Previously, we tried to remove extra arg commas when providing extra arg removal suggestions. One of
the edge cases is having to account for an arg that has a closing delimiter `)` following it.
However, the previous suggestion code assumed that the delimiter is in fact exactly the 1-byte `)`
character. This assumption was proven incorrect, because we recover from Unicode-confusable
delimiters in the parser, which means that the ending delimiter could be a multi-byte codepoint
that looks *like* a `)`. Subtracing 1 byte could land us in the middle of a codepoint, triggering a
codepoint boundary assertion.
This is fixed by using `SourceMap::end_point` which properly accounts for codepoint boundaries.
Fixes #128717.
cc ````@fmease```` and #128790
|
|
r=GuillaumeGomez
rustdoc: do not run doctests with invalid langstrings
https://github.com/rust-lang/rust/pull/124577#issuecomment-2276034737
CC ``@decathorpe``
|
|
|
|
|
|
Miscellaneous improvements to struct tail normalization
1. Make checks for foreign tails more accurate by normalizing the struct tail. I didn't write a test for this one.
2. Normalize when computing struct tail for `offset_of` for slice/str. This fixes the new solver only.
3. Normalizing when computing tails for disaligned reference check. This fixes both solvers.
r? lcnr
|
|
For codepoint boundary assertion triggered by a let stmt compound
assignment removal suggestion when encountering recovered multi-byte
compound ops.
Issue: <https://github.com/rust-lang/rust/issues/128845>
|
|
assertion
Issue: <https://github.com/rust-lang/rust/issues/128717>
|
|
run-make: enable msvc for staticlib-dylib-linkage
`-Zstaticlib-allow-rdylib-deps` on MSVC returns things like `/LIBPATH:R:\rust\build\x86_64-pc-windows-msvc\test\run-make\staticlib-dylib-linkage\rmake_out`. That is a linker argument rather than a `cc` argument. Which makes sense because rustc interacts directly with the linker on MSVC targets. So we need to tell the C compiler to pass on the arguments to the linker.
try-job: x86_64-msvc
try-job: i686-msvc
|
|
run-make: enable msvc for redundant-libs
The issue here was that `foo` was not exporting any functions therefore creating an import library was unnecessary and elided by the linker.
I fixed it by exporting the functions.
try-job: x86_64-msvc
try-job: i686-msvc
|
|
Don't inline tainted MIR bodies
Don't inline MIR bodies that are tainted, since they're not necessarily well-formed.
Fixes #128601 (I didn't add a new test, just copied one from the crashes, since they're the same root cause).
Fixes #122909.
|
|
|
|
rustdoc-json: add a test for impls on private & hidden types
Fixes #107278 (or rather just ensures it won't resurface)
r? ``@aDotInTheVoid``
|
|
rustdoc: strip unreachable modules
Modules are now stripped based on the same logic that's used to strip other item kinds
Fixes #101105
|
|
Don't implement `AsyncFn` for `FnDef`/`FnPtr` that wouldnt implement `Fn`
Due to unsafety, ABI, or the presence of target features, some `FnDef`/`FnPtr` types don't implement `Fn*`. Do the same for `AsyncFn*`.
Noticed this due to #128764, but this isn't really related to that ICE, which is fixed in #128792.
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #128306 (Update NonNull::align_offset quarantees)
- #128612 (Make `validate_mir` ensure the final MIR for all bodies)
- #128648 (Add regression test)
- #128749 (Mark `{f32,f64}::{next_up,next_down,midpoint}` inline)
- #128795 (Update E0517 message to reflect RFC 2195.)
- #128825 (rm `declared_features` field in resolver)
- #128826 (Only suggest `#[allow]` for `--warn` and `--deny` lint level flags)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
