Rollup of 7 pull requests #94860
Merged
Rollup of 7 pull requests #94860
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
The current structure makes it hard to tell that there are just four distinct code paths, depending on how many items there are in `bb_items` and `next_items`. This commit introduces a `match` that clarifies things.
They should only appear in transcribers.
Also rename `inner_parse_loop` as `parse_tt_inner`, because it's no longer just a loop.
For consistency, and to make the code slightly nicer.
…r=jyn514,camelid Add missing documentation for std::char types
…, r=notriddle Collapse blanket and auto-trait impls by default Blocked on rust-lang#94740 (the two first commits come from it). This behaviour was changed in rust-lang#88490 and apparently wasn't caught since then. You can test it [here](https://rustdoc.crud.net/imperio/collapsed-by-default/test_docs/struct.Foo.html#blanket-implementations). r? ``@notriddle``
…trochenkov `parse_tt` refactorings Some readability improvements. r? ``@petrochenkov``
…type, r=joshtriplett Rename `IntoFuture::Future` to `IntoFuture::IntoFuture` Ref: rust-lang#67644 (comment) This renames `IntoFuture::Future` to `IntoFuture::IntoFuture`. This adds the `Into*` prefix to the associated type, similar to the [`IntoIterator::IntoIter`](https://doc.rust-lang.org/std/iter/trait.IntoIterator.html#associatedtype.IntoIter) associated type. It's my mistake we didn't do so in the first place. This fixes that and brings the two closer together. Thanks! ### References __`IntoIterator` trait def__ ```rust pub trait IntoIterator { type Item; type IntoIter: Iterator<Item = Self::Item>; fn into_iter(self) -> Self::IntoIter; } ``` __`IntoFuture` trait def__ ```rust pub trait IntoFuture { type Output; type IntoFuture: Future<Output = Self::Output>; // Prior to this PR: `type Future:` fn into_future(self) -> Self::IntoFuture; } ``` cc/ `@eholk` `@rust-lang/wg-async`
CTFE/Miri: detect out-of-bounds pointers in offset_from Also I became uneasy with aggressively doing `try_to_int` here -- this will always succeed on Miri, leading to the wrong codepath being taken. We should rather try to convert them both to pointers, and use the integer path as a fallback, so that's what I implemented now. Hiding whitespaces helps with the diff. Fixes rust-lang/miri#1950 r? ``@oli-obk``
…an-DPC Make float parsing docs more comprehensive I was working on some code with some specialized restrictions on float parsing. I noticed the doc comments for `f32::from_str` and `f64::from_str` were missing several cases of valid inputs that are otherwise difficult to discover without looking at source code. I'm not sure if the doc comments were initially intended to contain a comprehensive description of valid inputs, but I figured it's useful to include these extra cases for reference.
…for-struct-field-type, r=cjgillot Suggest using double colon when a struct field type include single colon rust-lang#92685
rustbot
added
T-compiler
|
@bors r+ rollup=never p=5 |
|
📌 Commit 298c9a0 has been approved by |
bors
added
the
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
rust-highfive
added a commit
to rust-lang-nursery/rust-toolstate
that referenced
this pull request
Mar 12, 2022
Tested on commit rust-lang/rust@2c6a29a. Direct link to PR: <rust-lang/rust#94860> 💔 miri on windows: test-pass → test-fail (cc @eddyb @RalfJung @oli-obk). 💔 miri on linux: test-pass → test-fail (cc @eddyb @RalfJung @oli-obk).
|
Finished benchmarking commit (2c6a29a): comparison url. Summary: This benchmark run shows 10 relevant regressions 😿 to instruction counts.
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression |
|
Nothing jumps out as a likely regression here. This rollup was on the border of what we flag as a significant enough change to label as a regression. Given the regressions are small enough and are almost exclusively occurring in secondary benchmarks, I'm going to mark this as triaged. In general, I'd like for us to get better at handling regressions in rollups, but we're not quite there yet. @rustbot label: +perf-regression-triaged |
rustbot
added
the
perf-regression-triaged
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.
Successful merges:
parse_ttrefactorings #94798 (parse_ttrefactorings)IntoFuture::FuturetoIntoFuture::IntoFuture#94818 (RenameIntoFuture::FuturetoIntoFuture::IntoFuture)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup