Initial implementation of return-position `impl Trait` in traits
* Create a new item kind, called `ImplTraitPlaceholder`, which is used to lower `ast::TyKind::ImplTrait` in trait method returns.
* This item is the child of the trait method, which simplifies the way we calculate bounds and stuff.
* Use the def-id of this type to construct a projection type that we use during astconv for the return type of the trait method signature.
* Implement logic to normalize this `ImplTraitPlaceholder` projection type when we know its concrete impl (this is pretty limited currently, but really there are no other selection candidates that make sense -- for now!)
* Check that the `impl Trait`'s bounds are satisfied on the concrete type provided in the impl.
This is obviously nowhere near complete, but I wanted to at least get some initial support landed so we can start playing around with it.
What works:
* async fn in trait and RPITIT, including multiple `impl Trait`s and `impl Trait` nested in associated type bindings, like `impl Future<Output = impl Sized>`
Reimplement `carrying_add` and `borrowing_sub` for signed integers.
As per the discussion in #85532, this PR reimplements `carrying_add` and `borrowing_sub` for signed integers.
It also adds unit tests for both unsigned and signed integers, emphasing on the behaviours of the methods.
Fix `range_{plus,minus}_one` bad suggestions
Fixes#9431.
The current `range_plus_one` and `range_minus_one` suggestions are completely incorrect when macros are involved.
This commit resolves this by disabling the lints for any range expression that is expanded from a macro. The reasons for this are that it is very difficult to create a correct suggestion in this case and that false negatives are less important for pedantic lints.
changelog: Fix `range_{plus,minus}_one` bad suggestions
Make `Debug` impl for `Term` useful
because `Term { ptr: 78942378998734298342, maker: PhantomData, }` does not excel at communicating the necessary information
rustdoc: remove unused CSS `div.impl-items > div`
This was added in 9077d540da to override the style on `<div>` tags that were acting as headers. These `<div>` tags were replaced with `<section>` tags in 32f62607c3, but this CSS was probably already redundant even then (the headers had already been replaced with real `<h3>` and `<h4>` tags in 76a3b609d0).
rustdoc: remove unused CSS `#implementations-list > h3 > span.in-band`
This was added in 51f26acaea to help with the display of an `<h3>` tag that has a `<span class='in-band'>` inside.
The way implementation lists were rendered was changed in 34bd2b845b to have `<code class='in-band'>`, making this CSS unused.
Then it was turned into a `<div>` in 9077d540da without issue.
Finally, the header itself acquired the `in-band` class in 76a3b609d0.
Normalize before erasing late-bound regions in `equal_up_to_regions`
Normalize erasing regions **first**, before passing the type through a `BottomUpFolder` which erases late-bound regions too.
The root cause of this issue is due to 96d4137dee, which removes a `normalize_erasing_regions` that happens before this call to `equal_up_to_regions`. While reverting that commit might be a fix, I think it was suspicious to be erasing late-bound regions first _then_ normalizing types in the first place in `equal_up_to_regions`.
-----
I am tempted to ask the reviewer to review and `r+` this without a UI test, since the existing issues that I think this fixes are all incredibly difficult to minimize (anything hyper/warp related, given the nature of those libraries 😓) or impossible to reproduce locally (the miri test), namely:
* This recently reported issue with tokio + warp: #101430
* This issue from `@RalfJung` about Miri being broken: #101344
* This additional issue reported in a comment by `@tmandry` (issue with fuchsia + hyper): https://github.com/rust-lang/rust/issues/101344#issuecomment-1235974564
I have locally verified that the repro in #101430 is fixed with this PR, but after a couple of hours of attempting to minimize this error and either failing to actually repro the ICE, or being overwhelmed with the number of traits and functions I need to inline into a UI test, I have basically given up. Thoughts are appreciated on how best to handle this.
r? `@oli-obk` who is at the intersection of MIR and types-related stuff who may be able to give advice 😅
Fixes#9431.
The current `range_plus_one` and `range_minus_one` suggestions
are completely incorrect when macros are involved.
This commit resolves this by disabling the lints for any range
expression that is expanded from a macro. The reasons for this
are that it is very difficult to create a correct suggestion in
this case and that false negatives are less important for
pedantic lints.
This CSS was added in 5e01ba36c9, and served to
override CSS right above it that set a 5px padding for several kinds of
buttons in the same toolbar.
The CSS that it overrode is still there, but now it only applies to
`#settings-menu > a`, so there's nothing to override.
