-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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 9 pull requests #114294
Rollup of 9 pull requests #114294
Conversation
refactor builtin unsize handling, extend comments r? `@compiler-errors`
Check lazy type aliases for well-formedness Previously we didn't check if `T: Mul` holds given lazy `type Alias<T> = <T as Mul>::Output;`. Now we do. It only makes sense. `@rustbot` label F-lazy_type_alias r? `@oli-obk`
…ds, r=spastorino Map RPITIT's opaque type bounds back from projections to opaques An RPITIT in a program's AST is eventually translated into both a projection GAT and an opaque. The opaque is used for default trait methods, like: ``` trait Foo { fn bar() -> impl Sized { 0i32 } } ``` The item bounds for both the projection and opaque are identical, and both have a *projection* self ty. This is mostly okay, since we can normalize this projection within the default trait method body to the opaque, but it does two things: 1. it leads to bugs in places where we don't normalize item bounds, like `deduce_future_output_from_obligations` 2. it leads to extra match arms that are both suspicious looking and also easy to miss This PR maps the opaque type bounds of the RPITIT's *opaque* back to the opaque's self type to avoid this quirk. Then we can fix the UI test for rust-lang#108304 (1.) and also remove a bunch of match arms (2.). Fixes rust-lang#108304 r? `@spastorino`
…lor-24, r=notriddle Migrate GUI colors test to original CSS color format Follow-up of rust-lang#111459. r? `@notriddle`
Add missing feature gate in multiple_supertrait_upcastable doc Fix rust-lang#112424
@bors r+ rollup=never p=9 |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR:
previous master: 3114eb1fa5 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Why did like half of those PRs not get included in the rollup 💀 |
Yeah something is weird, just noticed it now :| |
I guess it's fine, as long as those other PRs weren't closed by bors, they're just sitting waiting for the next rollup I guess. Maybe bors just didn't detect an unsuccessful merge, or something. |
Finished benchmarking commit (b3df56a): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 649.988s -> 651.412s (0.22%) |
Successful merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup