-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Rollup of 6 pull requests #68854
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 #68854
Conversation
It became unnecessary since a06baa5 reformatted the file.
This function has a variable `changed` that is erroneously used for two related-but-different purpose: - to detect if the current element has changed; - to detect if any elements have changed. As a result, its use for the first purpose is broken, because if any prior element changed then the code always thinks the current element has changed. This is only a performance bug, not a correctness bug, because we frequently end up calling `assign_unpacked` unnecessarily to overwrite the element with itself. This commit adds `any_changed` to correctly distinguish between the two purposes. This is a small perf win for some benchmarks.
This is a small perf win.
also refactor `FnKind` and `visit_assoc_item` visitors
Strip unnecessary subexpression It became unnecessary since a06baa5 reformatted the file. The comment is currently a bit misleading.
…henkov Towards unified `fn` grammar Part of rust-lang#68728. - Syntactically, `fn` items in `extern { ... }` blocks can now have bodies (`fn foo() { ... }` as opposed to `fn foo();`). As above, we use semantic restrictions instead. - Syntactically, `fn` items in free contexts (directly in a file or a module) can now be without bodies (`fn foo();` as opposed to `fn foo() { ... }`. As above, we use semantic restrictions instead, including for non-ident parameter patterns. - We move towards unifying the `fn` front matter; this is fully realized in rust-lang#68728. r? @petrochenkov
…, r=nikomatsakis Improve `merge_from_succ` A couple of small performance wins. r? @nikomatsakis
…, r=estebank Clean up E0264, E0267 and E0268 explanations r? @Dylan-DPC
On suggesting `#![recursion_limit = "X"]`, note current crate name This would have saved me much confusion e.g. when reading the log output in rust-lang#68788 (comment). r? @estebank
Fix issue number of `capacity` method Follow-up of rust-lang#68558 (comment) r? @alexcrichton
@bors r+ p=6 rollup=never |
📌 Commit 68d523a has been approved by |
⌛ Testing commit 68d523a with merge 694c3b52c0733a10d3dede27a53399cd439b1179... |
Your PR failed (pretty log, raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem. Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
💔 Test failed - checks-azure |
@bors retry |
⌛ Testing commit 68d523a with merge a16ed032d90cad94bdd6f3483f52a60b3ebd21b1... |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
💔 Test failed - checks-azure |
Successful merges:
fn
grammar #68788 (Towards unifiedfn
grammar)merge_from_succ
#68790 (Improvemerge_from_succ
)#![recursion_limit = "X"]
, note current crate name #68840 (On suggesting#![recursion_limit = "X"]
, note current crate name)capacity
method #68851 (Fix issue number ofcapacity
method)Failed merges:
r? @ghost