minor: Rustc pull update #20740
Merged
minor: Rustc pull update #20740
+11
−46
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![workflows-rust-analyzer[bot]](https://avatars.githubusercontent.com/u/5430905?s=80&v=4){kind=small}
Set dead_on_return attribute for indirect arguments Set the dead_on_return attribute (added in LLVM 21) for arguments that are passed indirectly, but not byval. This indicates that the value of the argument on return does not matter, enabling additional dead store elimination. From LangRef: > This attribute indicates that the memory pointed to by the argument is dead upon function return, both upon normal return and if the calls unwinds, meaning that the caller will not depend on its contents. Stores that would be observable either on the return path or on the unwind path may be elided. > > Specifically, the behavior is as-if any memory written through the pointer during the execution of the function is overwritten with a poison value upon function return. The caller may access the memory, but any load not preceded by a store will return poison. > > This attribute does not imply aliasing properties. For pointer arguments that do not alias other memory locations, noalias attribute may be used in conjunction. Conversely, this attribute always implies dead_on_unwind. > > This attribute cannot be applied to return values. This fixes parts of rust-lang/rust#96497.
`apply_member_constraints`: fix placeholder check Checking whether the member region is *an existential region from a higher universe* is just wrong and I am pretty sure we've added that check by accident as the naming was just horribly confusing before rust-lang/rust#140466. I've encountered this issue separately while working on rust-lang/rust#139587, but feel like it's probably easier to separately FCP this change. This allows the following code to compile ```rust trait Proj<'a> { type Assoc; } impl<'a, 'b, F: FnOnce() -> &'b ()> Proj<'a> for F { type Assoc = (); } fn is_proj<F: for<'a> Proj<'a>>(f: F) {} fn define<'a>() -> impl Sized + use<'a> { // This adds a use of `opaque::<'a>` with hidden type `&'unconstrained_b ()`. // 'unconstrained_b is an inference variable from a higher universe as it gets // created inside of the binder of `F: for<'a> Proj<'a>`. This previously // caused us to not apply member constraints. We now do, constraining // it to `'a`. is_proj(define::<'a>); &() } fn main() {} ``` This should not be breaking change, even in theory. Applying member constraints is incomplete in rare circumstances which means that applying them in more cases can cause spurious errors, cc rust-lang/rust#140569/rust-lang/rust#142073. However, as we always skipped these member regions in `apply_member_constraints` the skipped region is guaranteed to cause an error in `check_member_constraints` later on.
const-eval: full support for pointer fragments This fixes rust-lang/const-eval#72 and makes `swap_nonoverlapping` fully work in const-eval by enhancing per-byte provenance tracking with tracking of *which* of the bytes of the pointer this one is. Later, if we see all the same bytes in the exact same order, we can treat it like a whole pointer again without ever risking a leak of the data bytes (that encode the offset into the allocation). This lifts the limitation that was discussed quite a bit in rust-lang/rust#137280. For a concrete piece of code that used to fail and now works properly consider this example doing a byte-for-byte memcpy in const without using intrinsics: ```rust use std::{mem::{self, MaybeUninit}, ptr}; type Byte = MaybeUninit<u8>; const unsafe fn memcpy(dst: *mut Byte, src: *const Byte, n: usize) { let mut i = 0; while i < n { *dst.add(i) = *src.add(i); i += 1; } } const _MEMCPY: () = unsafe { let ptr = &42; let mut ptr2 = ptr::null::<i32>(); // Copy from ptr to ptr2. memcpy(&mut ptr2 as *mut _ as *mut _, &ptr as *const _ as *const _, mem::size_of::<&i32>()); assert!(*ptr2 == 42); }; ``` What makes this code tricky is that pointers are "opaque blobs" in const-eval, we cannot just let people look at the individual bytes since *we don't know what those bytes look like* -- that depends on the absolute address the pointed-to object will be placed at. The code above "breaks apart" a pointer into individual bytes, and then puts them back together in the same order elsewhere. This PR implements the logic to properly track how those individual bytes relate to the original pointer, and to recognize when they are in the right order again. We still reject constants where the final value contains a not-fully-put-together pointer: I have no idea how one could construct an LLVM global where one byte is defined as "the 3rd byte of a pointer to that other global over there" -- and even if LLVM supports this somehow, we can leave implementing that to a future PR. It seems unlikely to me anyone would even want this, but who knows.^^ This also changes the behavior of Miri, by tracking the order of bytes with provenance and only considering a pointer to have valid provenance if all bytes are in the original order again. This is related to rust-lang/unsafe-code-guidelines#558. It means one cannot implement XOR linked lists with strict provenance any more, which is however only of theoretical interest. Practically I am curious if anyone will show up with any code that Miri now complains about - that would be interesting data. Cc `@rust-lang/opsem`
… r=petrochenkov Sometimes skip over tokens in `parse_token_tree`. r? `@petrochenkov`
Access less HIR attributes from typeck Typeck relies on attributes to modify its own behaviour. This is a problem, as this means that `typeck(some function)` may depend on the span and doc-comments of many other functions. This PR attempts to reduce such accesses to attributes. This yields to a sizeable perf improvement: rust-lang/rust#144841 (comment) Fixes rust-lang/rust#124352
…owLii fix `#[loop_match]` on diverging loop tracking issue: rust-lang/rust#132306 fixes rust-lang/rust#144492 fixes rust-lang/rust#144493 fixes rust-lang/rust#144781 this generated invalid MIR before. issue rust-lang/rust#143806 still has an issue where we assign `state = state` which is invalid in MIR. Fixing that problem is tricky, so I'd like to do that separately. r? `@bjorn3`
Fix `env::ArgsOs` for zkVM The zkVM implementation of `env::ArgsOs` incorrectly reports the full length even after having iterated. Instead, use a range approach which works out to be simpler. Also, implement more iterator methods like the other platforms in #139847. cc `@flaub` `@jbruestle` `@SchmErik`
`rust-analyzer` subtree update Subtree update of `rust-analyzer` to 0c62c01. Created using https://github.com/rust-lang/josh-sync. r? `@ghost`
…ol,jieyouxu Ignore tests in `tests/ui/abi` for the GCC backend Needed for rust-lang/rust#146414. Currently we ignore them in the GCC backend and until this situation changes, it'll block rust-lang/rust#146414. r? `@Kobzol`
Consider errors in MIR as impossible predicates to empty the body. The ICEs come from elaborating drops or performing state transform in MIR bodies that fail typeck or borrowck. If the body is tainted, replace it with `unreachable`. Fixes rust-lang/rust#122630 Fixes rust-lang/rust#122904 Fixes rust-lang/rust#125185 Fixes rust-lang/rust#139556
Mark float intrinsics with no preconditions as safe Note: for ease of reviewing, the list of safe intrinsics is sorted in the first commit, and then safe intrinsics are added in the second commit. All *recently added* float intrinsics have been correctly marked as safe to call due to the fact that they have no preconditions. This adds the remaining float intrinsics which are safe to call to the safe intrinsic list, and removes the unsafe blocks around their calls. --- Side note: this may want a try run before being added to the queue, since I'm not sure if there's any tier-2 code that uses these intrinsics that might not be tested on the usual PR flow. We've already uncovered a few places in subtrees that do this, and it's worth double-checking before clogging up the queue.
…Urgau,davidtwco Extends AArch64 branch protection support to include GCS Extends existing support for AArch64 branch protection to include support for [Guarded Control Stacks](https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/arm-a-profile-architecture-2022#guarded-control-stack-gcs:~:text=Extraction%20or%20tracking.-,Guarded%20Control%20Stack%20(GCS),-With%20the%202022).
fix 2 borrowck issues fixes rust-lang/rust#146467 cc ``@amandasystems`` our understanding here is as follows: region constraints from computing implied bounds gets `ConstraintCategory::Internal`. If there's a higher-ranked subtyping errors while computing implied bounds we then ended up with only `ConstraintCategory::Internal` and `ConstraintCategory::OutlivesUnnameablePlaceholder(_)` constraints. The path was something like - `'placeholderU2: 'placeholderU1` (`Internal`) - `'placeholderU1: 'static` (`OutlivesUnnameablePlaceholder('placeholderU2)`) It's generally somewhat subtle here as ideally relating placeholders doesn't introduce `'static` constraints. Relating the placeholders themselves will always error regardless, cc rust-lang/rust#142623. --- separately fixes rust-lang/rust#145925 (comment) by updating the location for deferred closure requirements inside of promoteds. I am not updating their category as doing so is 1) effort and 2) imo actually undesirable 🤔 see the comments in `TypeChecker::check_promoted` cc ``@lqd`` r? lqd
Switch next-solver related rustc dependencies of r-a to crates.io ones r? ``@ghost`` cc ``@lnicola`` ``@lcnr``
temporary-lifetime-extension-tuple-ctor.rs: make usable on all editions Also - add Reference id - fix typo
library: std: sys: pal: uefi: Add some comments I seemed to have forgotten that since I am using GET_PROTOCOL attribute for the std usecases, I did not need to close the protocols explicitly. So adding these comments as a note to future self not to waste time on the same thing again.
const-eval: better wording for errors involving maybe-null pointers Fixes rust-lang/rust#146748 r? ``@oli-obk``
Rollup of 8 pull requests Successful merges: - rust-lang/rust#146711 (fix 2 borrowck issues) - rust-lang/rust#146857 (revert change removing `has_infer` check. Commit conservatively patch…) - rust-lang/rust#146897 (fix ICE in rustdoc::invalid_html_tags) - rust-lang/rust#146915 (Make missed precondition-free float intrinsics safe) - rust-lang/rust#146932 (Switch next-solver related rustc dependencies of r-a to crates.io ones) - rust-lang/rust#146959 (temporary-lifetime-extension-tuple-ctor.rs: make usable on all editions) - rust-lang/rust#146964 (library: std: sys: pal: uefi: Add some comments) - rust-lang/rust#146969 (const-eval: better wording for errors involving maybe-null pointers) r? `@ghost` `@rustbot` modify labels: rollup
This updates the rust-version file to caccb4d.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: caccb4d Filtered ref: 0f345ed Upstream diff: rust-lang/rust@21a19c2...caccb4d This merge was created using https://github.com/rust-lang/josh-sync.
rustbot
added
the
S-waiting-on-review
rustbot
removed
the
S-waiting-on-review
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Latest update from rustc.