-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Rollup of 6 pull requests #92518
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.*
@bors r+ rollup=never p=6 |
📌 Commit 13e2840 has been approved by |
☀️ Test successful - checks-actions |
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).
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 |
Successful merges:
NullOp::Box
#90102 (RemoveNullOp::Box
)rustc_macros
when emitting decode call #92011 (Use field span inrustc_macros
when emitting decode call)Failed merges:
result_cloned
andresult_copied
#92483 (Stabilizeresult_cloned
andresult_copied
)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup