rustdoc: render generic params & where-clauses of cross-crate assoc tys in impls
We used to only ever render generic parameters & where-clauses of cross-crate associated types when the item was located inside of a trait and we used to just drop them when it was inside of an impl block (trait or inherent).
Fixes#112904.
`@rustbot` label A-cross-crate-reexports
`hir`: Add `Become` expression kind (explicit tail calls experiment)
This adds `hir::ExprKind::Become` alongside ast lowering. During hir-thir lowering we currently lower `become` as `return`, so that we can partially test `become` without ICEing.
cc `@scottmcm`
r? `@Nilstrieb`
Rollup of 5 pull requests
Successful merges:
- #112976 (Add test for futures with HRTB)
- #113013 (rustdoc: get rid of extra line when line-wrapping fn decls with empty arg list)
- #113030 (Add a regression test for #109071)
- #113031 (Add a regression test for #110933)
- #113036 (Accept `ReStatic` for RPITIT)
r? `@ghost`
`@rustbot` modify labels: rollup
rustdoc: handle assoc const equalities in cross-crate impl-Trait-in-arg-pos
Fixes FIXME (the added test previously lead to an ICE).
`@rustbot` label A-cross-crate-reexports
Revert "Structurally resolve correctly in check_pat_lit"
This reverts commit 54fb5a48b9. Also adds a couple of tests, and downgrades the existing `-Ztrait-solver=next` test to a known-bug.
Fixes#112993
Fix test for #96258#98644 did not properly test enabling the problematic lint as a warning due to improper use of `compile-flags:` (missing `:`). This makes it use `#![warn]` instead, like in the reproducer.
cc #96258
rustdoc: Align search results horizontally for easy scanning
The recent PR #110688 added info about an item's kind before its name in
search results. However, because the kind and name are inline with no
alignment, it's now hard to visually scan downward through the search
results, looking at item names. This PR fixes that by horizontally
aligning search results such that there are now two columns of
information.
r? `@GuillaumeGomez`
[-Ztrait-solver=next, mir-typeck] instantiate hidden types in the root universe
Fixes an ICE in the test `member-constraints-in-root-universe`.
Main motivation is to make #112691 pass under the new solver.
r? ``@compiler-errors``
Fix return type notation associated type suggestion when -Zlower-impl-trait-in-trait-to-assoc-ty
This avoid suggesting the associated types generated for RPITITs when the one the code refers to doesn't exist and rustc looks for a suggestion.
r? `@compiler-errors`
Fix return type notation errors with -Zlower-impl-trait-in-trait-to-assoc-ty
This just adjust the way we check for RPITITs and uses the new helper method to do the "old" and "new" check at once.
r? `@compiler-errors`
Don't emit same goal as input during `wf::unnormalized_obligations`
r? `@aliemjay` cc `@lcnr`
I accidentally pruned the logic to handle `WF(?0)` when writing `wf::unnormalized_obligations`.
idk if you wanted to construct a test first, but this is an obvious fix. Copied the comment from above.
Fixesrust-lang/trait-system-refactor-initiative#36
Implement `Sync` for `mpsc::Sender`
`mpsc::Sender` is currently `!Sync` because the previous implementation contained an optimization where the channel started out as single-producer and was dynamically upgraded on the first clone, which relied on a unique reference to the sender. This optimization is one of the main reasons the old implementation was so complex and was removed in #93563. `mpsc::Sender` can now soundly implement `Sync`.
Note for any potential confusion, this chance does *not* add MPMC behavior. This only affects the already `Send + Clone` *sender*, not *receiver*.
It's technically possible to rely on the `!Sync` behavior in the same way as a `PhantomData<*mut T>`, but that seems very unlikely in practice. Either way, this change is insta-stable and needs an FCP.
`@rustbot` label +T-libs-api -T-libs
Various impl trait in assoc tys cleanups
r? `@compiler-errors`
All commits except for the last are pure refactorings. 274dab5bd658c97886a8987340bf50ae57900c39 allows struct fields to participate in deciding whether a function has an opaque in its signature.
best reviewed commit by commit
