Rollup of 6 pull requests #113420
Closed
Rollup of 6 pull requests #113420
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
…li-obk Simplify duplicate checks for mir validator This removes unnecessary allocations & is less code.
Fix incorrect documented default bufsize in bufreader/writer
…e, r=lcnr Don't call `type_of` on TAIT in defining scope in new solver It's *never* productive to call `consider_auto_trait_candidate` on a TAIT in the defining scope, since it will always lead to a query cycle since we call `type_of` on the TAIT. So let's just don't. I've reserved this behavior just to `SolverMode::Normal` just to avoid any future problems, since this is *technically* incomplete since we're discarding a candidate that could *theoretically* apply. But given such candidate assembly *always* leads to a query cycle, I think it's relatively low risk, and I could be convinced otherwise and make this apply to both solver mode. I assume it's far less likely to be encountered in coherence, though. This is much more likely to encounter in the new solver, though it can also be encountered in the old solver too, so I'm happy to discuss whether this new behavior we even want in the first place... I encountered this in a couple of failing UI tests: * `tests/ui/type-alias-impl-trait/issue-62000-associate-impl-trait-lifetimes.rs` * `tests/ui/type-alias-impl-trait/issue-93411.rs` r? `@lcnr`
…-errors Add a regression test for rust-lang#109054 Closes rust-lang#109054 r? `@compiler-errors`
…new-solver, r=lcnr Reveal opaques in new solver We were testing against the wrong reveal mode 😨 Also a couple of misc commits that I don't want to really put in separate prs r? `@lcnr`
…obj, r=lcnr Prefer object candidates in new selection `dyn Any` shouldn't be using [this implementation](https://doc.rust-lang.org/std/any/trait.Any.html#impl-Any-for-T) during codegen. Prefer object candidates over other candidates, except for other object candidates.
rustbot
added
S-waiting-on-review
|
@bors r+ rollup=never p=6 |
bors
added
S-waiting-on-bors
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
Two of my PRs in this rollup are conflicting each other 😓 |
|
lol |
|
Well, either that, or #112825 just needs blessing. It's kinda old. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
type_ofon TAIT in defining scope in new solver #112825 (Don't calltype_ofon TAIT in defining scope in new solver)type_alias_impl_traitwith lifetime #109054)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup