-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
[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 fixes rust-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! Closes rust-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. Fixes rust-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. Closes rust-lang#42808
r? @pnkfelix (rust_highfive has picked a reviewer for you, use r? to override) |
Note that not everything is approved just yet, so I'm going to wait for all these backports to get approved |
@bors: r+ p=10 |
📌 Commit 7c076fc has been approved by |
@bors: r+ p=10 |
📌 Commit 0e9969c has been approved by |
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. |
☀️ Test successful - status-appveyor, status-travis |
Includes:
for_all_relevant_impls
O(1) again #43723