-
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
Rollup of 8 pull requests #123381
Rollup of 8 pull requests #123381
Conversation
Because `HashMap::with_hasher` constness is being stabilized this will in turn allow creating empty HashMap<K,V,BuildHasherDefault<H>> in const context for any H: Default + Hasher.
This is just one part of the MCP, but it's the one that IMHO removes the most noise from the standard library code. Seems net simpler this way, since MIR already supported heterogeneous shifts anyway, and thus it's not more work for backends than before.
Co-authored-by: Waffle Maybe <[email protected]>
Previously, we assumed all `ty::Coroutine` were general coroutines and attempted to generalize them through the `Coroutine` trait. Select appropriate traits for each kind of coroutine.
…ew, r=Amanieu Add fn const BuildHasherDefault::new See [tracking issue](rust-lang#123197) for justification.
De-LLVM the unchecked shifts [MCP#693] This is just one part of the MCP (rust-lang/compiler-team#693), but it's the one that IMHO removes the most noise from the standard library code. Seems net simpler this way, since MIR already supported heterogeneous shifts anyway, and thus it's not more work for backends than before. r? WaffleLapkin
… r=estebank Make sure to insert `Sized` bound first into clauses list rust-lang#120323 made it so that we don't insert an implicit `Sized` bound whenever we see an *explicit* `Sized` bound. However, since the code that inserts implicit sized bounds puts the bound as the *first* in the list, that means that it had the **side-effect** of possibly meaning we check `Sized` *after* checking other trait bounds. If those trait bounds result in ambiguity or overflow or something, it may change how we winnow candidates. (**edit: SEE** rust-lang#123303) This is likely the cause for the regression in rust-lang#123279 (comment), since the impl... ```rust impl<T: Job + Sized> AsJob for T { // <----- changing this to `Sized + Job` or just `Job` (which turns into `Sized + Job`) will FIX the issue. } ``` ...looks incredibly suspicious. Fixes [after beta-backport] rust-lang#123279. Alternative is to revert rust-lang#120323. I don't have a strong opinion about this, but think it may be nice to keep the diagnostic changes around.
…tests, r=GuillaumeGomez rustdoc: add a couple of regression tests Fixes rust-lang#114657. Fixes rust-lang#112828. Fixes rust-lang#107715. r? rustdoc
…ures, r=oli-obk Fix capture analysis for by-move closure bodies The check we were doing to figure out if a coroutine was borrowing from its parent coroutine-closure was flat-out wrong -- a misunderstanding of mine of the way that `tcx.closure_captures` represents its captures. Fixes rust-lang#123251 (the miri/ui test I added should more than cover that issue) r? `@oli-obk` -- I recognize that this PR may be underdocumented, so please ask me what I should explain further.
…s, r=estebank Check that nested statics in thread locals are duplicated per thread. follow-up to rust-lang#123310 cc `@compiler-errors` `@RalfJung` fwiw: I have no idea how thread local statics make that work under LLVM, and miri fails on this example, which I would have expected to be the correct behaviour. Since the `#[thread_local]` attribute is just an internal implementation detail, I'm just going to start hard erroring on nested mutable statics in thread locals.
… r=compiler-errors CFI: Support non-general coroutines Previously, we assumed all `ty::Coroutine` were general coroutines and attempted to generalize them through the `Coroutine` trait. Select appropriate traits for each kind of coroutine. I have this marked as a draft because it currently only fixes async coroutines, and I think it make sense to try to fix gen/async gen coroutines before this is merged. If the issue [mentioned](rust-lang#123106 (comment)) in the original PR is actually affecting someone, we can land this as is to remedy it.
…uillaumeGomez rustdoc: synthetic auto trait impls: accept unresolved region vars for now rust-lang#123348 (comment): > Right, [in rust-lang#123340] I've intentionally changed a `vid_map.get(vid).unwrap_or(r)` to a `vid_map[vid]` making rustdoc panic if `rustc::AutoTraitFinder` returns a region inference variable that cannot be resolved because that is really fishy. I can change it back with a `FIXME: investigate` […]. [O]nce I [fully] understand [the arcane] `rustc::AutoTraitFinder` [I] can fix the underlying issue if there's one. > > `rustc::AutoTraitFinder` can also return placeholder regions `RePlaceholder` which doesn't seem right either and which makes rustdoc ICE, too (we have a GitHub issue for that already[, namely rust-lang#120606]). Fixes rust-lang#123370. Fixes rust-lang#112242. r? `@GuillaumeGomez`
@bors r+ rollup=never p=8 |
🔒 Merge conflict This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again. How do I rebase?Assuming
You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial. Please avoid the "Resolve conflicts" button on GitHub. It uses Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Error message
|
Successful merges:
Sized
bound first into clauses list #123302 (Make sure to insertSized
bound first into clauses list)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup