Rustc pull update #1902
Closed
Rustc pull update #1902
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-stdarch[bot]](https://avatars.githubusercontent.com/u/5430905?s=60&v=4){kind=small}
Perform check_private_in_public by module. Based on rust-lang/rust#116316
Add release notes for 1.89.0 r? `@BoxyUwU` cc `@rust-lang/release` `@rustbot` ping relnotes-interest-group
stdarch subtree update Subtree update of `stdarch` to 97bf36d. Created using https://github.com/rust-lang/josh-sync. r? `@folkertdev`
move `type_check` out of `compute_regions` A step towards rust-lang/rust#139587. I don't think there's a clear reason for why MIR type check should be in `compute_regions` and this simplifies future PRs here.
…n, r=petrochenkov Prevent name collisions with internal implementation details The implementation of the linkage attribute inside extern blocks defines symbols starting with _rust_extern_with_linkage_. If someone tries to also define this symbol you will get a symbol conflict or even an ICE. By adding an unpredictable component to the symbol name, this becomes less of an issue. Spawned from the discussion at [#t-compiler > About static variables `_rust_extern_with_linkage_*`](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/About.20static.20variables.20.60_rust_extern_with_linkage_*.60) cc `@ywxt` Fixes rust-lang/rust#144940
Add a lot of NLL `known-bug` tests r? ``@jackh726`` As requested in rust-lang/rust#143093 (review) this extracts most tests from that PR and expands upon them as described. The handful of linked-list cursor-like tests will also turn into polonius=next known-bugs in rust-lang/rust#143093 where the behavior w/r/t kills changes of course.
Move metadata symbol export from exported_non_generic_symbols to exported_symbols The metadata symbol must not be encoded in the crate metadata, and must be exported from proc-macros. Handling the export of the metadata symbol in exported_symbols handles both things at once without requiring manual fixups elsewhere.
…etrochenkov Clean up some resolved test regressions of const trait removals in std cc rust-lang/rust#143871
Readd myself to review queue r? `@ghost` (self review)
Add minimal `armv7a-vex-v5` tier three target This PR adds minimal, `no_std` support for the VEX V5 Brain, a robotics microcontroller used in educational contexts. In comparison to rust-lang/rust#131530, which aimed to add this same target, these changes are limited in scope to the compiler. ## Tier 3 Target Policy Compliance > A tier 3 target must have a designated developer or developers (the "target maintainers") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.) Lewis McClelland (`@lewisfm),` `@Tropix126,` Gavin Niederman (`@Gavin-Niederman),` and Max Niederman (`@max-niederman)` will be the designated maintainers for `armv7a-vex-v5` support. > Targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive, especially once the target reaches a higher tier, so getting the name right is important even for a tier 3 target. `armv7a-vex-v5` follows the cpu-vendor-model convention used by most tier three targets. For example: `armv76k-nintendo-3ds` or `armv7k-apple-watchos`. > Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example, if the name of the target makes people extremely likely to form incorrect beliefs about what it targets, the name should be changed or augmented to disambiguate it. > If possible, use only letters, numbers, dashes and underscores for the name. Periods (.) are known to cause issues in Cargo. This target name is not confusing. > Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users. It's using open source tools only. > The target must not introduce license incompatibilities. > > Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0). Understood. > The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository), or whether the dependency is a native library or binary. In other words, the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements. There are no new dependencies/features required in the current state of this target. Porting the standard library will likely require depending on the crate `vex-sdk` which is MIT-licensed and contains bindings to the VEX SDK runtime (which is included in VEXos). > Compiling, linking, and emitting functional binaries, libraries, or other code for the target (whether hosted on the target itself or cross-compiling from another target) must not depend on proprietary (non-FOSS) libraries. Host tools built for the target itself may depend on the ordinary runtime libraries supplied by the platform and commonly used by other applications built for the target, but those libraries must not be required for code generation for the target; cross-compilation to the target must not require such libraries at all. For instance, rustc built for the target may depend on a common proprietary C runtime library or console output library, but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations, but the Rust project has no interest in maintaining such combinations within the scope of Rust itself, even at tier 3. > > "onerous" here is an intentionally subjective term. At a minimum, "onerous" legal/licensing terms include but are not limited to: non-disclosure requirements, non-compete requirements, contributor license agreements (CLAs) or equivalent, "non-commercial"/"research-only"/etc terms, requirements conditional on the employer or employment of any particular Rust developers, revocable terms, any requirements that create liability for the Rust project or its developers or users, or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users. Although the VEX V5 Brain and its SDK are proprietary, this target does not link to any proprietary binaries or libraries, and is based solely on publicly available information about the VEX SDK. > Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target, or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target, they must recuse themselves from any approval decisions regarding the target's tier status, though they may otherwise participate in discussions. > > This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval, even if such judgment involves subjective matters or goes beyond the letter of these requirements. I understand. > Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets, alloc for targets that can support dynamic memory allocation, std for targets with an operating system or equivalent layer of system-provided functionality), but may leave some code unimplemented (either unavailable or stubbed out as appropriate), whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions. This initial PR only contains a compiler target definition to teach the `cc` crate about this target. Porting the standard library is the next step for this target. > The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible. If the target supports running binaries, or running tests (even if they do not pass), the documentation must explain how to run such binaries or tests for the target, using emulation if possible or dedicated hardware if necessary. This target is documented in `src/doc/rustc/src/platform-support/armv7a-vex-v5.md`. > Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium, including via `@)` to a PR author or others involved with a PR regarding a tier 3 target, unless they have opted into such messages. > > Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy, within reason. However, such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications. I understand and assent. > Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. > > In particular, this may come up when working on closely related targets, such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection, as appropriate, to let each target run code supported by that target. I understand and assent. > Tier 3 targets must be able to produce assembly using at least one of rustc's supported backends from any host target. (Having support in a fork of the backend is not sufficient, it must be upstream.) `armv7a-vex-v5` has nearly identical codegen to `armv7a-none-eabihf`, so this is not an issue. > If a tier 3 target stops meeting these requirements, or the target maintainers no longer have interest or time, or the target shows no signs of activity and has not built for some time, or removing the target would improve the quality of the Rust codebase, we may post a PR to remove it; any such PR will be CCed to the target maintainers (and potentially other people who have previously worked on the target), to check potential interest in improving the situation. I understand.
Rollup of 19 pull requests Successful merges: - rust-lang/rust#144400 (`tests/ui/issues/`: The Issues Strike Back [3/N]) - rust-lang/rust#144764 ([codegen] assume the tag, not the relative discriminant) - rust-lang/rust#144807 (Streamline config in bootstrap) - rust-lang/rust#144899 (Print CGU reuse statistics in `-Zprint-mono-items`) - rust-lang/rust#144909 (Add new `test::print_merged_doctests_times` used by rustdoc to display more detailed time information) - rust-lang/rust#144912 (Resolver: introduce a conditionally mutable Resolver for (non-)speculative resolution.) - rust-lang/rust#144914 (Add support for `ty::Instance` path shortening in diagnostics) - rust-lang/rust#144931 ([win][arm64ec] Fix msvc-wholearchive for Arm64EC) - rust-lang/rust#144999 (coverage: Remove all unstable support for MC/DC instrumentation) - rust-lang/rust#145009 (A couple small changes for rust-analyzer next-solver work) - rust-lang/rust#145030 (GVN: Do not flatten derefs with ProjectionElem::Index. ) - rust-lang/rust#145042 (stdarch subtree update) - rust-lang/rust#145047 (move `type_check` out of `compute_regions`) - rust-lang/rust#145051 (Prevent name collisions with internal implementation details) - rust-lang/rust#145053 (Add a lot of NLL `known-bug` tests) - rust-lang/rust#145055 (Move metadata symbol export from exported_non_generic_symbols to exported_symbols) - rust-lang/rust#145057 (Clean up some resolved test regressions of const trait removals in std) - rust-lang/rust#145068 (Readd myself to review queue) - rust-lang/rust#145070 (Add minimal `armv7a-vex-v5` tier three target) r? `@ghost` `@rustbot` modify labels: rollup
add a scope for `if let` guard temporaries and bindings This fixes my concern with `if let` guard drop order, namely that the guard's bindings and temporaries were being dropped after their arm's pattern's bindings, instead of before (rust-lang/rust#141295 (comment)). The guard's bindings and temporaries now live in a new scope, which extends until (but not past) the end of the arm, guaranteeing they're dropped before the arm's pattern's bindings. This only introduces a new scope for match arms with guards. Perf results (rust-lang/rust#143376 (comment)) seemed to indicate there wasn't a significant hit to introduce a new scope on all match arms, but guard patterns (rust-lang/rust#129967) will likely benefit from only adding new scopes when necessary (with some patterns requiring multiple nested scopes). Tracking issue for `if_let_guard`: rust-lang/rust#51114 Tests are adapted from examples by `@traviscross,` `@est31,` and myself on rust-lang/rust#141295.
Implement `stability_implications` without a visitor. Since rust-lang/rust#143845, the `Annotator` visitor was a no-op when the crate is not staged_api. This PR avoids using a visitor altogether, making `stability_implications` truly a no-op in most cases.
- remove some stabilized target features from `gate.rs`
…cross Stabilize `sse4a` and `tbm` target features This PR stabilizes the feature flag `sse4a_target_feature` and `tbm_target_feature` (tracking issue rust-lang/rust#44839). # Public API The 2 `x86` target features `sse4a` and `tbm` Also, these were added in LLVM2.6 and LLVM3.4-rc1, respectively, and as the minimum LLVM required for rustc is LLVM19, we are safe in that front too! As all of the required tasks have been done (adding the target features to rustc, implementing their runtime detection in std_detect and implementing the associated intrinsics in core_arch), these target features can be stabilized now. The intrinsics were stabilized *long* ago, in 1.27.0 Reference PR: - rust-lang/reference#1949 cc `@rust-lang/lang` `@rustbot` label I-lang-nominated r? lang
Rework target checking for built-in attributes This is a refactoring of target checking for built-in attributes. This PR has the following goals: - Only refactor the 80% of the attributes that are simple to target check. More complicated ones like `#[repr]` will be in a future PR. Tho I have written the code in such a way that this will be possible to add in the future. - No breaking changes. - This part of the codebase is not very well tested though, we can do a crater run if we want to be sure. - I've spotted quite a few weird situations (like I don't think an impl block should be deprecated?). We can propose fixing these to in a future PR Fixes rust-lang/rust#143780 Fixes rust-lang/rust#138510 I've split it in commits and left a description on some of the commits to help review. r? `@jdonszelmann`
Patterns: represent constants as valtrees Const patterns are always valtrees now. Let's represent that in the types. We use `ty::Value` for this since it nicely packages value and type, and has some convenient methods. Cc `@Nadrieril` `@BoxyUwU`
…=BoxyUwU ignore head usages from ignored candidates Fixes rust-lang/trait-system-refactor-initiative#210. The test now takes 0.8s to compile, which seems good enough to me. We are actually still walking the entire graph here, we're just avoiding unnecessary reruns. The basic idea is that if we've only accessed a cycle head inside of a candidate which didn't impact the final result of our goal, we don't need to rerun that cycle head even if is the used provisional result differs from the final result. We also use this information when rebasing goals over their cycle heads. If a goal doesn't actually depend on the result of that cycle head, rebasing always succeeds. However, we still need to make sure we track the fact that we relied on the cycle head at all to avoid query instability. It is implemented by tracking the number of `HeadUsages` for every head while evaluating goals. We then also track the head usages while evaluating a single candidate, which the search graph returns as `CandidateHeadUsages`. If there is now an always applicable candidate candidate we know that all other candidates with that source did not matter. We then call `fn ignore_candidate_head_usages` to remove the usages while evaluating this single candidate from the total. If the final `HeadUsages` end up empty, we know that the result of this cycle head did not matter when evaluating its nested goals.
`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.
Revert "Partially outline code inside the panic! macro". This reverts rust-lang/rust#115670 Without any tests/benchmarks that show some improvement, it's hard to know whether the change had any positive effect. (And if it did, whether that effect is still achieved today.)
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`
Print regions in `type_name`. Currently they are skipped, which is a bit weird, and it sometimes causes malformed output like `Foo<>` and `dyn Bar<, A = u32>`. Most regions are erased by the time `type_name` does its work. So all regions are now printed as `'_` in non-optional places. Not perfect, but better than the status quo. `c_name` is updated to trim lifetimes from MIR pass names, so that the `PASS_NAMES` sanity check still works. It is also renamed as `simplify_pass_type_name` and made non-const, because it doesn't need to be const and the non-const implementation is much shorter. The commit also renames `should_print_region` as `should_print_optional_region`, which makes it clearer that it only applies to some regions. Fixes rust-lang/rust#145168. r? `@lcnr`
This updates the rust-version file to 425a9c0a0e365c0b8c6cfd00c2ded83a73bed9a0.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: 425a9c0a0e365c0b8c6cfd00c2ded83a73bed9a0 Filtered ref: 4f47825 This merge was created using https://github.com/rust-lang/josh-sync.
|
We already made these changes on our end (and it looks like this PR being open blocks a new PR from being created?) |
1bb58b1 doesn't seem to have made it to this tree?
It shouldn't, usually it force pushes. The workflow can also be run manually from https://github.com/rust-lang/stdarch/actions/workflows/rustc-pull.yml |
|
Oh, I see 9810ae9 did the same change. That's going to need a manual resolution. Edit: maybe not? Just tested locally and it says there is nothing to pull |
|
Yeah the CI action seems to say the same: I guess that PR that removed |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.