`ptr` of `slice::Iter` and `slice::IterMut` can never be null, but this
fact wasn't exploited for layout optimizations. By changing `ptr` from
`*<mutability> T` to `NonNull<T>`, the compiler can now optimize layout
of `Option<Iter<'a, T>>`.
Prepare for lowering or-patterns
This is probably best reviewed commit-by-commit.
* Rustfmt `rustc_mir::build::{self, matches}`
* Remove `-Znll-dont-emit-read-for-match`
* Split `match_expr` into smaller functions
* Feature gate or-patterns in const contexts
cc https://github.com/rust-lang/rust/issues/54883
r? @Centril
Tweak errors for missing associated types and type parameters
* On `dyn Trait` missing associated types, provide a structured suggestion for them
* On missing type parameters, provide structured suggestion for them
* Point at trait definition when missing required type parameter
* Tweak output of E0658
* Tweak wording of E0719
* Account for `Trait1 + Trait2` case
Fix#66380, fix#60595. CC #63711.
Deprecate Error::description for real
`description` has been documented as soft-deprecated since 1.27.0 (17 months ago). There is no longer any reason to call it or implement it.
This PR:
- adds `#[rustc_deprecated(since = "1.41.0")]` to `Error::description`;
- moves `description` (and `cause`, which is also deprecated) below the `source` and `backtrace` methods in the Error trait;
- reduces documentation of `description` and `cause` to take up much less vertical real estate in rustdocs, while preserving the example that shows how to render errors without needing to call `description`;
- removes the description function of all *currently unstable* Error impls in the standard library;
- marks `#[allow(deprecated)]` the description function of all *stable* Error impls in the standard library;
- replaces miscellaneous uses of `description` in example code and the compiler.
---
![description](https://user-images.githubusercontent.com/1940490/69910369-3bbaca80-13bf-11ea-94f7-2fe27a7ea333.png)
Generalize `array_into_iter` lint to also lint for boxed arrays
`Box` is special in that a method call on a box can move the value out
of the box. Thus, the same backwards-compatibility problem can arise
for boxed arrays as for simple arrays.
---
CC #66145
r? @matthewjasper (as you reviewed the first PR)