Skip to content
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

Rollup of 6 pull requests #92518

Merged
merged 30 commits into from
Jan 3, 2022
Merged

Rollup of 6 pull requests #92518

merged 30 commits into from
Jan 3, 2022

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

nbdd0121 and others added 30 commits October 20, 2021 19:42
This will cause backtraces to point to the location of
the field in the struct/enum, rather than the derive macro.

This makes it clear which field was being decoded when the
backtrace was captured (which is especially useful if
there are multiple fields with the same type).
Extends rust-lang#75931 to also detect where the `let` might be missing from `while let` expressions.
The crate name is already set in Cargo.toml. The comment says there is
some logic in the compiler that reads #![crate_name] and not
--crate-name, but I can't find it. Removing it seems to work fine.
Remove `NullOp::Box`

Follow up of rust-lang#89030 and MCP rust-lang/compiler-team#460.

~1 month later nothing seems to be broken, apart from a small regression that rust-lang#89332 (1aac85bb716c09304b313d69d30d74fe7e8e1a8e) shows could be regained by remvoing the diverging path, so it shall be safe to continue and remove `NullOp::Box` completely.

r? `@jonas-schievink`
`@rustbot` label T-compiler
…rister

Use field span in `rustc_macros` when emitting decode call

This will cause backtraces to point to the location of
the field in the struct/enum, rather than the derive macro.

This makes it clear which field was being decoded when the
backtrace was captured (which is especially useful if
there are multiple fields with the same type).
Suggest while let x = y when encountering while x = y

Extends rust-lang#75931 to also detect where the `let` might be missing from `while let` expressions.
Couple of libtest cleanups

Remove the unnecessary `TDynBenchFn` trait and remove a couple of unused attributes and feature gates.
…erister

Fix spacing in pretty printed PatKind::Struct with no fields

Follow-up to rust-lang#92238 fixing one of the FIXMEs.

```rust
macro_rules! repro {
    ($pat:pat) => {
        stringify!($pat)
    };
}

fn main() {
    println!("{}", repro!(Struct {}));
}
```

Before:&ensp;<code>Struct&nbsp;{&nbsp;&nbsp;}</code>
After:&ensp;<code>Struct&nbsp;{}</code>
Consolidate Result's and Option's methods into fewer impl blocks

`Result`'s and `Option`'s methods have historically been separated up into `impl` blocks based on their trait bounds, with the bounds specified on type parameters of the impl block. I find this unhelpful because closely related methods, like `unwrap_or` and `unwrap_or_default`, end up disproportionately far apart in source code and rustdocs:

<pre>
impl&lt;T&gt; Option&lt;T&gt; {
    pub fn unwrap_or(self, default: T) -&gt; T {
        ...
    }

    <img alt="one eternity later" src="https://user-images.githubusercontent.com/1940490/147780325-ad4e01a4-c971-436e-bdf4-e755f2d35f15.jpg" width="750">
}

impl&lt;T: Default&gt; Option&lt;T&gt; {
    pub fn unwrap_or_default(self) -&gt; T {
        ...
    }
}
</pre>

I'd prefer for method to be in as few impl blocks as possible, with the most logical grouping within each impl block. Any bounds needed can be written as `where` clauses on the method instead:

```rust
impl<T> Option<T> {
    pub fn unwrap_or(self, default: T) -> T {
        ...
    }

    pub fn unwrap_or_default(self) -> T
    where
        T: Default,
    {
        ...
    }
}
```

*Warning: the end-to-end diff of this PR is computed confusingly by git / rendered confusingly by GitHub; it's practically impossible to review that way. I've broken the PR into commits that move small groups of methods for which git behaves better &mdash; these each should be easily individually reviewable.*
@rustbot rustbot added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Jan 3, 2022
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=6

@bors
Copy link
Contributor

bors commented Jan 3, 2022

📌 Commit 13e2840 has been approved by matthiaskrgr

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Jan 3, 2022
@bors
Copy link
Contributor

bors commented Jan 3, 2022

⌛ Testing commit 13e2840 with merge ddabe07...

@bors
Copy link
Contributor

bors commented Jan 3, 2022

☀️ Test successful - checks-actions
Approved by: matthiaskrgr
Pushing ddabe07 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jan 3, 2022
@bors bors merged commit ddabe07 into rust-lang:master Jan 3, 2022
@rustbot rustbot added this to the 1.59.0 milestone Jan 3, 2022
@rust-highfive
Copy link
Collaborator

📣 Toolstate changed by #92518!

Tested on commit ddabe07.
Direct link to PR: #92518

💔 miri on windows: test-pass → build-fail (cc @RalfJung @eddyb @oli-obk).
💔 miri on linux: test-pass → build-fail (cc @RalfJung @eddyb @oli-obk).

rust-highfive added a commit to rust-lang-nursery/rust-toolstate that referenced this pull request Jan 3, 2022
Tested on commit rust-lang/rust@ddabe07.
Direct link to PR: <rust-lang/rust#92518>

💔 miri on windows: test-pass → build-fail (cc @RalfJung @eddyb @oli-obk).
💔 miri on linux: test-pass → build-fail (cc @RalfJung @eddyb @oli-obk).
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (ddabe07): comparison url.

Summary: This benchmark run did not return any relevant changes.

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression

@matthiaskrgr matthiaskrgr deleted the rollup-fl8z4e7 branch February 13, 2022 00:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants