-
Notifications
You must be signed in to change notification settings - Fork 341
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rustup #3403
Merged
Merged
Rustup #3403
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
Let codegen decide when to `mem::swap` with immediates Making `libcore` decide this is silly; the backend has so much better information about when it's a good idea. Thus this PR introduces a new `typed_swap` intrinsic with a fallback body, and replaces that fallback implementation when swapping immediates or scalar pairs. r? oli-obk Replaces #111744, and means we'll never need more libs PRs like #111803 or #107140
Stabilize slice_split_at_unchecked Greetings! I took the opportunity, and I tried to stabilize the `slice_split_at_unchecked` feature. I followed the guidelines, and I hope everything was done correctly 🤞 . Closes #76014
…lacrum Cancel `cargo update` job if there's no updates Previously there were always updates so we didn't hit this. Since #122489, this job runs on a more frequent schedule and causes errors if there have been no changes in that timespan. This led to a weird error on rust-lang/rust#122646 (comment) - because of this I've replaced the `exit 1`s here with `gh run cancel` so we don't have false 'failed' jobs in the logs.
Rename `hir::Local` into `hir::LetStmt` Follow-up of #122776. As discussed on [zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Improve.20naming.20of.20.60ExprKind.3A.3ALet.60.3F). I made this change into a separate PR because I'm less sure about this change as is. For example, we have `visit_local` and `LocalSource` items. Is it fine to keep these two as is (I supposed it is but I prefer to ask) or not? Having `Node::Local(LetStmt)` makes things more explicit but is it going too far? r? ```@oli-obk```
…er-errors Delay a bug if no RPITITs were found Fixes #122655. See the issue for context. r? compiler-errors or compiler
docs(sync): normalize dot in fn summaries All other functions in e.g. [`Mutex`](https://doc.rust-lang.org/std/sync/struct.Mutex.html) have a dot at the end of their first doc line, except for the newly stabilized [`Mutex::clear_poison`](https://doc.rust-lang.org/std/sync/struct.Mutex.html#method.clear_poison) (and its friend [`RwLock::clear_poison`](https://doc.rust-lang.org/std/sync/struct.RwLock.html#method.clear_poison)). This PR remedies that by adding a normalizing dot.
…ulacrum Enable more mir-opt tests in debug builds This is rust-lang/rust#121531 but for the mir-opt test suite.
-Zprint-type-sizes: print the types of awaitees and unnamed coroutine locals. This should assist comprehending the size of coroutines. In particular, whenever a future is suspended while awaiting another future, the latter is given the special name `__awaitee`, and now the type of the awaited future will be printed, allowing identifying caller/callee — er, I mean, poller/pollee — relationships. It would be possible to include the type name in more cases, but I thought that that might be overly verbose (`print-type-sizes` is already a lot of text) and ordinary named fields or variables are easier for readers to discover the types of. This change will also synergize with my other PR #122923 which changes type printing to print the path of the `async fn` instead of the span. Implementation note: I'm not sure if `Symbol::intern` is appropriate for this application, but it was the obvious way to not have to remove the `Copy` implementation from `FieldInfo`, or add a `'tcx` lifetime, while avoiding keeping a lot of possibly redundant strings in memory. I don't know what the proper tradeoff to make here is (though presumably it is not too important for a `-Z` debugging option).
add panic location to 'panicked while processing panic' Fixes rust-lang/rust#97181 r? `@Amanieu`
Rollup of 11 pull requests Successful merges: - #120577 (Stabilize slice_split_at_unchecked) - #122698 (Cancel `cargo update` job if there's no updates) - #122780 (Rename `hir::Local` into `hir::LetStmt`) - #122915 (Delay a bug if no RPITITs were found) - #122916 (docs(sync): normalize dot in fn summaries) - #122921 (Enable more mir-opt tests in debug builds) - #122922 (-Zprint-type-sizes: print the types of awaitees and unnamed coroutine locals.) - #122927 (Change an ICE regression test to use the original reproducer) - #122930 (add panic location to 'panicked while processing panic') - #122931 (Fix some typos in the pin.rs) - #122933 (tag_for_variant follow-ups) r? `@ghost` `@rustbot` modify labels: rollup
Miri subtree update r? `@ghost`
refactor check_{lang,library}_ub: use a single intrinsic This enacts the plan I laid out [here](rust-lang/rust#122282 (comment)): use a single intrinsic, called `ub_checks` (in aniticpation of rust-lang/compiler-team#725), that just exposes the value of `debug_assertions` (consistently implemented in both codegen and the interpreter). Put the language vs library UB logic into the library. This makes it easier to do something like rust-lang/rust#122282 in the future: that just slightly alters the semantics of `ub_checks` (making it more approximating when crates built with different flags are mixed), but it no longer affects whether these checks can happen in Miri or compile-time. The first commit just moves things around; I don't think these macros and functions belong into `intrinsics.rs` as they are not intrinsics. r? `@saethlin`
…orkingjubilee Portable SIMD subtree update Syncs nightly to the latest changes from rust-lang/portable-simd r? `@calebzulawski`
@bors r+ |
☀️ Test successful - checks-actions |
1 similar comment
☀️ 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.