Automatic sync from rustc #3087
Merged
Conversation
This file contains 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
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Do not create a DerefLen place for `Box<[T]>`. Fixes rust-lang/rust#115789
Document panics on unsigned wrapping_div/rem calls (#116063) Add missing `# Panics` sections to the `uint_impl!` macro, documenting that the `wrapping_rem/div` calls will panic if passed zero.
Add Minimal Std implementation for UEFI # Implemented modules: 1. alloc 2. os_str 3. env 4. math # Related Links Tracking Issue: rust-lang/rust#100499 API Change Proposal: rust-lang/libs-team#87 # Additional Information This was originally part of rust-lang/rust#100316. Since that PR was becoming too unwieldy and cluttered, and with suggestion from `@dvdhrm,` I have extracted a minimal std implementation to this PR. The example in `src/doc/rustc/src/platform-support/unknown-uefi.md` has been tested for `x86_64-unknown-uefi` and `i686-unknown-uefi` in OVMF. It would be great if someone more familiar with AARCH64 can help with testing for that target. Signed-off-by: Ayush Singh <[email protected]>
…=cjgillot Add Zba, Zbb, and Zbs as target features for riscv64-linux-android This pull request adds the Zba, Zbb, and Zbs target features to the `riscv64-linux-android` target specification. These features have been enabled and tested internally in Android infrastructure.
Fix debug printing of tuple Self-explanatory. Didn't create a UI test, but I guess I could -- not sure where debug output shows up in rustc_attrs to make a sufficient test, tho.
…errors Add regression test for #102467 Fixes #102467. r? `@compiler-errors`
fix OS-specific I/O safety docs since the io_safety feature is stable Looks like this text was forgotten to be updated when `io_safety` got stabilized: it still says "once the io_safety feature is stable". Also adjust the wording a bit for how these docs relate to the general concept of I/O safety.
Clarify example in `Pin::new_unchecked` docs This example in the docs of `Pin::new_unchecked` puzzled me for a relatively long time. Now I understand that it comes down to the difference between dropping the `Pin` vs dropping the pinned value. I have extended the explanation to highlight this difference. In my opinion it is clearer now, and I hope it helps others understand `Pin` better.
…ark-Simulacrum Add assembly test to make sure that inlining works as expected when closures inherit target features Closes rust-lang/rust#108338 (the added test proves that it is working correctly)
Miri subtree update r? `@ghost`
Update crates for better MIPS R6 support Update crates to remove dependency on old versions of rustix and linux-raw-sys. Update libc, rustix, and linux-raw-sys to enhance support for MIPS R6 introduced by #112374 Commands that do the update: ```shell cargo +nightly update tempfile clap cargo +nightly update linux-raw-sys rustix ```
Fix jq in CI r? `@Mark-Simulacrum`
…ime_binders, r=compiler-errors Don't ICE when no bound vars found while doing closure hir type check The problem was that we were not visiting the const generic default argument in a bound where predicate when the HIR gets traversed in hir_analysis -> collect -> resolve_bound_vars. Fixes [112574](rust-lang/rust#112574)
… r=Mark-Simulacrum Avoid overflow in `IoSlice::advance_slices` Noticed in rust-lang/rust#62726 (comment).
…umeGomez rustdoc: correctly render the return type of cross-crate async fns Fixes #115760.
…mjay Use placeholders to prevent using inferred RPITIT types to imply their own well-formedness The issue here is that we use the same signature to do RPITIT inference as we do to compute implied bounds. To fix this, when gathering the assumed wf types for the method, we replace all of the infer vars (that will be eventually used to infer RPITIT types) with type placeholders, which imply nothing about lifetime bounds. This solution kind of sucks, but I'm not certain there's another feasible way to fix this. If anyone has a better solution, I'd be glad to hear it. My naive first solution was, instead of using placeholders, to replace the signature with the RPITIT projections that it originally started out with. But turns out that we can't just use the unnormalized signature of the trait method in `implied_outlives_bounds` since we normalize during WF computation -- that would cause a query cycle in `collect_return_position_impl_trait_in_trait_tys`. idk who to request review... r? `@lcnr` or `@aliemjay` i guess. Fixes #116060
…, r=compiler-errors Properly print cstr literals in `proc_macro::Literal::to_string` Previously we printed the contents of the string, rather than the actual string literal (e.g. `the c string` instead of `c"the c string"`). Fixes #112820 cc #105723
ConstParamTy: require Eq as supertrait As discussed with `@BoxyUwu` [on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/.60ConstParamTy.60.20and.20.60Eq.60). We want to say that valtree equality on const generic params agrees with `==`, but that only makes sense if `==` actually exists, hence we should have an appropriate bound. Valtree equality is an equivalence relation, so such a type can always be `Eq` and not just `PartialEq`.
Clippy subtree update r? `@Manishearth`
Don't use a thread to load the dep graph This removes the use of a thread to load the dep graph. It's not currently useful as we immediately block on it. r? `@oli-obk`
lint towards rejecting consts in patterns that do not implement PartialEq I think we definitely don't want to allow such consts, so even while the general plan around structural matching is up in the air, we can start the process of getting non-PartialEq matches out of the ecosystem.
Use Vec::retain in remove_dead_blocks. r? `@ghost`
Correct codegen of `ConstValue::Indirect` scalar and scalar pair This concerns 3 tricky cases with `ConstValue::Indirect`: - if we want a non-pointer scalar; - if we have non-zero offset; - if offset points to uninit memory => generate `poison` instead of an ICE. This case could happen in unreachable code, trying to extract a field from the wrong variant. Those cases are not currently emitted by the compiler, but are exercised by rust-lang/rust#116012.
Only prevent field projections into opaque types, not types containing opaque types fixes rust-lang/rust#115778 I did not think that original condition through properly... I'll also need to check the similar check around the other `ProjectionKind::OpaqueCast` creation site (this one is in hir, the other one is in mir), but I'll do that change in another PR that doesn't go into a beta backport.
|
@bors r+ |
|
☀️ Test successful - checks-actions |
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.
No description provided.