Merged
Conversation
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: <code>Struct { }</code> After: <code>Struct {}</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<T> Option<T> {
pub fn unwrap_or(self, default: T) -> T {
...
}
<img alt="one eternity later" src="https://user-images.githubusercontent.com/1940490/147780325-ad4e01a4-c971-436e-bdf4-e755f2d35f15.jpg" width="750">
}
impl<T: Default> Option<T> {
pub fn unwrap_or_default(self) -> 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 — these each should be easily individually reviewable.*
rustbot
added
T-compiler
Member
Author
|
@bors r+ rollup=never p=6 |
Collaborator
|
📌 Commit 13e2840 has been approved by |
bors
added
the
S-waiting-on-bors
Collaborator
Collaborator
|
☀️ Test successful - checks-actions |
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).
This was referenced Jan 3, 2022
Merged
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 |
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
9 participants
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:
NullOp::Box#90102 (RemoveNullOp::Box)rustc_macroswhen emitting decode call #92011 (Use field span inrustc_macroswhen emitting decode call)Failed merges:
result_clonedandresult_copied#92483 (Stabilizeresult_clonedandresult_copied)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup