Uh oh!
There was an error while loading. Please reload this page.
[beta] Final round of beta backports - #44062
Conversation
A change in rust-lang#41911 had made `for_all_relevant_impls` do a linear scan over all impls, instead of using an HashMap. Use an HashMap again to avoid quadratic blowup when there is a large number of structs with impls. I think this fixesrust-lang#43141 completely, but I want better measurements in order to be sure. As a perf patch, please don't roll this up.
Historically many `Display` and `Debug` implementations for `OsStr`-like abstractions have gone through `String::from_utf8_lossy`, but this was updated in rust-lang#42613 to use an internal `Utf8Lossy` abstraction instead. This had the unfortunate side effect of causing a regression (rust-lang#43765) in code which relied on these `fmt` trait implementations respecting the various formatting flags specified. This commit opportunistically adds back interpretation of formatting trait flags in the "common case" where where `OsStr`-like "thing" is all valid utf-8 and can delegate to the formatting implementation for `str`. This doesn't entirely solve the regression as non-utf8 paths will format differently than they did before still (in that they will not respect formatting flags), but this should solve the regression for all "real world" use cases of paths and such. The door's also still open for handling these flags in the future! Closesrust-lang#43765
Since rust-lang#42886, macros can create "nonstandard" PatKind::Lit patterns, that contain path expressions instead of the usual literal expr. These can cause trouble, including ICEs. We *could* map these nonstandard patterns to PatKind::Path patterns during HIR lowering, but that would be much effort for little gain, and I think is too risky for beta. So let's just forbid them during AST validation. Fixesrust-lang#43250.
No test cases for these ones, but they would all ICE if they ever run with a non-empty set of obligations.
This commit flags all allocation-related functions in liballoc as "this can't unwind" which should largely resolve the size-related issues found on rust-lang#42808. The documentation on the trait was updated with such a restriction (they can't panic) as well as some other words about the relative instability about implementing a bullet-proof allocator. Closesrust-lang#42808
rust-highfive
commented
Aug 23, 2017
r? @pnkfelix (rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
commented
Aug 23, 2017
alexcrichton
commented
Aug 23, 2017
Note that not everything is approved just yet, so I'm going to wait for all these backports to get approved |
alexcrichton
commented
Aug 23, 2017
@bors: r+ p=10 |
bors
commented
Aug 23, 2017
📌 Commit 7c076fc has been approved by |
alexcrichton
commented
Aug 23, 2017
@bors: r+ p=10 |
bors
commented
Aug 23, 2017
📌 Commit 0e9969c has been approved by |
bors
commented
Aug 23, 2017
Never mind, it actually started, after sleeping for 1.5 hours. Let's wait 2 more hours on this. Update: It is now stuck at Update 2: The job is currently at the documentation stage. So it is Travis's logger being stuck, not the job itself. Letting it to continue. |
bors
commented
Aug 23, 2017
☀️ Test successful - status-appveyor, status-travis |
Includes:
for_all_relevant_implsO(1) again #43723