On usize=u64 platforms, the 4th iteration would overflow the `mod_gate`
back to 0. Similarly for usize=u32 platforms, the 3rd iteration would
overflow much the same way.

I tested various approaches to resolving this, including approaches with
`saturating_mul` and `widening_mul` to a double usize. Turns out LLVM
likes `mul_with_overflow` the best. In fact now, that LLVM can see the
iteration count is limited, it will happily unroll the loop into a nice
linear sequence.

You will also notice that the code around the loop got simplified
somewhat. Now that LLVM is handling the loop nicely, there isn’t any
more reasons to manually unroll the first iteration out of the loop
(though looking at the code today I’m not sure all that complexity was
necessary in the first place).

Fixes rust-lang#103361

Clarify that the diagnostic can be retrieved with `steal_diagnostic`.

The font size and weights should be exactly the same after this commit,
but the spacing is changed to be exactly the same as methods.

remove HRTB from `[T]::is_sorted_by{,_key}`

Changes the signature of `[T]::is_sorted_by{,_key}` to match `[T]::binary_search_by{,_key}` and make code like rust-lang#53485 (comment) compile.

Tracking issue: rust-lang#53485

~~Do we need an ACP for something like this?~~ Edit: Filed ACP here: rust-lang/libs-team#121

…tmcm

Fix mod_inv termination for the last iteration

On usize=u64 platforms, the 4th iteration would overflow the `mod_gate` back to 0. Similarly for usize=u32 platforms, the 3rd iteration would overflow much the same way.

I tested various approaches to resolving this, including approaches with `saturating_mul` and `widening_mul` to a double usize. Turns out LLVM likes `mul_with_overflow` the best. In fact now, that LLVM can see the iteration count is limited, it will happily unroll the loop into a nice linear sequence.

You will also notice that the code around the loop got simplified somewhat. Now that LLVM is handling the loop nicely, there isn’t any more reasons to manually unroll the first iteration out of the loop (though looking at the code today I’m not sure all that complexity was necessary in the first place).

Fixes rust-lang#103361

…cottmcm

`unchecked_{shl|shr}` should use `u32` as the RHS

The other shift methods, such as https://doc.rust-lang.org/nightly/std/primitive.u64.html#method.checked_shr and https://doc.rust-lang.org/nightly/std/primitive.i16.html#method.wrapping_shl, use `u32` for the shift amount.  That's consistent with other things, like `count_ones`, which also always use `u32` for a bit count, regardless of the size of the type.

This PR changes `unchecked_shl` and `unchecked_shr` to also use `u32` for the shift amount (rather than Self).

cc rust-lang#85122, the `unchecked_math` tracking issue

…ation__--this-can-be-simplified, r=scottmcm

Simplify some pointer method implementations

- Make `pointer::with_metadata_of` const (+simplify implementation) (cc rust-lang#75091)
- Simplify implementation of various pointer methods

r? ```@scottmcm```

----

`from_raw_parts::<T>(this, metadata(self))` was annoying me for a while and I've finally figured out how it should _actually_ be done.

…, r=davidtwco

Diagnostics `icu4x` based list formatting.

This adds a new kind of `DiagnosticArg` and add the ability to convert it to a `FluentValue::Custom`. When emitting fluent output, it makes use of `ListFormatter` from `icu4x` project to convert it to localized version of list following the fluent locale, as a kind of eager translation.

Tested locally with locales like `en`, `ja`, etc, and they work fine. <del>Though neither `zh-CN` nor `zh-Hans` works correctly, it seems they fallback to `und` locale somehow, emitting only comma-based list. I believe this is an internal issue of `icu4x` itself.</del>(Works fine after rust-lang#104047 (comment))

Would love to hear what others think.

r? `@davidtwco`
cc `@Manishearth`

…holk

Enforce that `dyn*` coercions are actually pointer-sized

Implement a perma-unstable, rudimentary `PointerSized` trait to enforce `dyn*` casts are `usize`-sized for now, at least to prevent ICEs and weird codegen issues from cropping up after monomorphization since currently we enforce *nothing*.

This probably can/should be removed in favor of a more sophisticated trait for handling `dyn*` conversions when we decide on one, but I just want to get something up for discussion and experimentation for now.

r? ```@eholk``` cc ```@tmandry``` (though feel free to claim/reassign)

Fixes rust-lang#102141
Fixes rust-lang#102173

…er-errors

Edit docs for `rustc_errors::Handler::stash_diagnostic`

Clarify that the diagnostic can be retrieved with `steal_diagnostic`.

r? ```@compiler-errors```

…llaumeGomez

rustdoc: use `code-header` class to format enum variants

The font size and weights should be exactly the same after this PR, but the spacing is changed to be the same as methods.

Preview: http://notriddle.com/notriddle-rustdoc-demos/variant/test_dingus_enum/enum.TestEnum.html