docs: Iterator adapters have unspecified results after a panic #67564
Conversation
|
(rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
There was a problem hiding this comment.
Looks good to me. For the record, I also agree that this is the behavior we want (i.e. we do not want to promise anything beyond memory safety).
I'm not sure if I should already r+ this one or if we need to get rfcbot involved? I guess this is a small enough change to directly merge, but I am not entirely sure and don't want to screw up my first assigned review. Soo... @alexcrichton: can I r+? @bors rollup is probably the best command here?
|
You'll want r+ rollup as the arguments to bors, rather than just rollup. I personally don't think we need an FCP here but happy with one as well. |
Mark-Simulacrum
added
the
T-libs-api
|
@bors r+ rollup I decided to simply merge this now. Lib team members already agreed and this is backwards-compatible since we never promised anything. No need to get everyone involved. |
|
📌 Commit 65e3660 has been approved by |
bors
added
S-waiting-on-bors
… r=LukasKalbertodt docs: Iterator adapters have unspecified results after a panic Fixes rust-lang#58170. That issue also has rough consensus from 3 members of the library team for this being the behavior we would like to specify.
Rollup of 10 pull requests Successful merges: - #64273 (Stabilize attribute macros on inline modules) - #67287 (typeck: note other end-point when checking range pats) - #67564 (docs: Iterator adapters have unspecified results after a panic) - #67622 (Some keyword documentation.) - #67657 (Clean up const-hack PRs now that const if / match exist.) - #67677 (resolve: Minor cleanup of duplicate macro reexports) - #67687 (Do not ICE on lifetime error involving closures) - #67698 (Move reachable_set and diagnostic_items to librustc_passes.) - #67701 (tidy: Enforce formatting rather than just check it if `--bless` is specified) - #67715 (Typo fix) Failed merges: r? @ghost
Fixes #58170.
That issue also has rough consensus from 3 members of the library team for this being the behavior we would like to specify.