Co-Authored-By: xfix <konrad@borowski.pw>

…nvocation

…);` and potentially instantiated at different types.

(Updated to reflect changes in diagnostic output and compiletest infrastructure.)

…:…` in stdlib docs

The use-case of `todo!()` macro is to be a much easier to type
alternative to `unimplemented!()` macro.

- Closes rust-lang#51476

This functionality was added in 1.35.0, not 1.34.0.

Add todo!() macro

The primary use-case of `todo!()` macro is to be a much easier to type
alternative to `unimplemented!()` macro.

EDIT: hide unpopular proposal about re-purposing unimplemented

<details>
However, instead of just replacing `unimplemented!()`, it gives it a
more nuanced meaning: a thing which is intentionally left
unimplemented and which should not be called at runtime. Usually,
you'd like to prevent such cases statically, but sometimes you, for
example, have to implement a trait only some methods of which are
applicable. There are examples in the wild of code doing this thing,
and in this case, the current message of `unimplemented`, "not *yet*
implemented" is slightly misleading.

With the addition of TODO, you have three nuanced choices for a
`!`-returning macro (in addition to a good-old panic we all love):

  * todo!()
  * unreachable!()
  * unimplemented!()

Here's a rough guideline what each one means:

- `todo`: use it during development, as a "hole" or placeholder. It
  might be a good idea to add a pre-commit hook which checks that
  `todo` is not accidentally committed.

- `unreachable!()`: use it when your code can statically guarantee
  that some situation can not happen. If you use a library and hit
  `unreachable!()` in the library's code, it's definitely a bug in the
  library. It's OK to have `unreachable!()` in the code base,
  although, if possible, it's better to replace it with
  compiler-verified exhaustive checks.

- `unimplemented!()`: use it when the type checker forces you to
  handle some situation, but there's a contract that a callee must not
  actually call the code. If you use a library and hit
  `unimplemented!()`, it's probably a bug in your code, though
  it *could* be a bug in the library (or library docs) as well. It is
  ok-ish to see an `unimplemented!()` in real code, but it usually
  signifies a clunky, eyebrow-rising API.
</details>

…constraints-on-bindings-too, r=nikomatsakis

extra testing of how NLL handles wildcard type `_`

test that wildcard type `_` is not duplicated by `type Foo<X> = (X, X);` and potentially instantiated at different types when used in type ascriptions in let bindings.

(NLL's handling of this for the type ascription *expression form* is currently broken, or at least differs from what AST-borrowck does. I'll file a separate bug about that. Its not something critical to address since that expression is guarded by `#![feature(type_ascription)]`.)

cc rust-lang#55748

dbg!() without parameters

Fixes rust-lang#57845.

…r=SimonSapin

Implement ExactSizeIterator for ToLowercase and ToUppercase

Clarify distinction between floor() and trunc()

`floor()` rounds towards `-INF`, `trunc()` rounds towards 0.
This PR clarifies this in the examples.

Fix a tiny error in documentation of std::pin.

`new_unmoved` must be `mut` for passing to `std::mem::swap`.

Be more discerning on when to attempt suggesting a comma in a macro invocation

Fix rust-lang#58796.

add self to mailmap

Replaced self-reflective explicit types with clearer `Self` or `Self::…` in stdlib docs

Many docs examples use explicit types instead of the semantically more clear `Self`/`Self::…` aliases.

By using the latter it's clear that the value's type depends on either `Self`, or an associated type of `Self`, instead of some constant type. It's also more consistent (and I'd argue correct), as the current docs aren't really consistent in this, as can be seen from the diff.

This is a best effort PR, as I was basically going through the docs manually, looking for offending examples. I'm sure I missed a few. Gotta start somewhere.

…cell-map-split, r=cramertj,Centril

Stabilize refcell_map_split feature

Closes rust-lang#51476.

Run branch cleanup after copy prop

This is preliminary work for rust-lang#59288 (comment) which gets rid of `if` in the HIR.

cc @rust-lang/wg-mir-opt 	@Centril