Consider NonNull as a pointer type
PR 1/2 for issue #8045. Add `NonNull` as a pointer class to suppress false positives like `UnsafeCell<NonNull<()>>`. However, this change is not sufficient to handle the cases shared in gtk-rs and Rug in the issue.
changelog: none
r? `@xFrednet`
Currently, we check if the returned type equals to `tcx.ty_error()` not to emit
erroneous types, but this has a pitfall; for example,
`Option<[type error]> != tcx.ty_error()` holds.
Rollup of 3 pull requests
Successful merges:
- #87054 (Add a `try_reduce` method to the Iterator trait)
- #89701 (Updated error message for accidental uses of derive attribute as a crate attribute)
- #90519 (Keep spans for generics in `#[derive(_)]` desugaring)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Keep spans for generics in `#[derive(_)]` desugaring
Keep the spans for generics coming from a `derive`d Item, so that errors
and suggestions have better detail.
Fix#84003.
Updated error message for accidental uses of derive attribute as a crate attribute
This partially fixes the original issue #89566 by adding derive to the list of invalid crate attributes and then providing an updated error message however I'm not sure how to prevent the resolution error message from emitting without causing the compiler to just abort when it finds an invalid crate attribute (which I'd prefer not to do so we can find and emit other errors).
`@petrochenkov` I have been told you may have some insight on why it's emitting the resolution error though honestly I'm not sure if we need to worry about fixing it as long as we can provide the invalid crate attribute error also (which happens first anyway)
Rationale:
* The name was confusing.
* It was only used in one place.
* That place didn't actually need all the functionality of `get_type`;
rather, removing `get_type` makes that code clearer.
Rollup of 7 pull requests
Successful merges:
- #90538 (Document how recursion is handled for `ty::Ty`)
- #90851 (Add unchecked downcast methods)
- #91209 (Implement ``@snapshot`` check for htmldocck)
- #91385 (Suggest the `pat_param` specifier before `|` on 2021 edition )
- #91478 (Remove incorrect newline from float cast suggestion)
- #91481 (Use let_else in some more places in rustc_lint)
- #91488 (Fix ICE when `yield`ing in function returning `impl Trait`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Fix ICE when `yield`ing in function returning `impl Trait`
Change an assert to a `delay_span_bug` and remove an unwrap, that should fix it.
Fixes#91477
Adds the minimial repro test case from #85360. The fix for #85360 was
supposed to be #85868 however the repro was resolved in the 2021-07-05
nightly while #85360 didn't land until 2021-09-03. The reason for that
is d34a3a401b **also** resolves that
issue.
To test if #85868 actually fixes#85360, I reverted
d34a3a401b and found that #85868 does
indeed resolve#85360.
With that question resolved, add a test case to our incremental test
suite for the original Ok(EvaluatedToOkModuloRegions) ICE.
Thanks to @lqd for helping track this down!
rustdoc: Remove Clean impls for tuples
This PR removes all nine Clean impls on tuples, converting them to
functions instead.
The fact that these are impls causes several problems:
1. They are nameless, so it's unclear what they do.
2. It's hard to find where they're used apart from removing them and
seeing what errors occur (this applies to all Clean impls, not just
the tuple ones).
3. Rustc doesn't currently warn when impls are unused, so dead code
can accumulate easily (all Clean impls).
4. Their bodies often use tuple field indexing syntax (e.g., `self.1`)
to refer to their "arguments", which makes reading the code more
difficult.
As I noted, some of these problems apply to all Clean impls, but even
those problems are exacerbated by the tuple impls since they make
general understanding of the code harder.
Converting the impls to functions solves all four of these problems.
r? `@GuillaumeGomez`
