Change back prelude headline

:arrow_up: rust-analyzer

Remove a FIXME resolved by #73578

ffi::c_str smaller as_bytes

Auto merge of #83637 - bjorn3:sync_cg_clif-2021-03-29, r=bjorn3

Sync rustc_codegen_cranelift

The main highlight of this sync is support for cross-compiling to Windows using MinGW. Native compilation with MinGW would also work I think, but using the MSVC toolchain is not yet supported as PE TLS is not yet implemented. Another nice improvement is that crate metadata is now loaded using mmap instead of by reading files. This improves compilation time a bit.

r? `@ghost`

`@rustbot` label +A-codegen +A-cranelift +T-compiler

Replace tabs in err messages before rendering

This is done in other call sites, but was missing in one place.

Fixes #83638

Merge commit '0969bc6dde001e01e7e1f58c8ccd7750f8a49ae1' into sync_cg_clif-2021-03-29

Prefer 4 spaces

Add a regression test for issue-82792

Auto merge of #83565 - RalfJung:miri, r=oli-obk

update Miri, and also run test suite with mir-opt-level=4

In the Miri repo, we run the Miri test suite once with default flags and once with `-O -Zmir-opt-level=4`. This helps identify and document situations where MIR optimizations mask UB -- it is okay for that to happen, but it might be god to look into it when it does happen. Recently these tests failed fairly frequently as new MIR optimizations were added, and since we only run them on the Miri side, it is not even clear which rustc PR introduced the change. So I propose we also run these tests in the rustc repo, such that toolstate tracking will tell us the exact PR (or at least the rollup) that caused the change.

r? `@oli-obk`
Fixes https://github.com/rust-lang/rust/issues/83590

Rustup to rustc 1.53.0-nightly (4a20eb6a9 2021-03-28)

Inline `find_suffix` closure that's only used once

Add test for weird backticks placement

Point to disambiguator instead of whole link

And, now that we do that, we can remove the explanatory note since the
error span should make it clear what the disambiguator is.

Auto merge of #83605 - RalfJung:unaligned, r=petrochenkov

unaligned_references: align(N) fields in packed(N) structs are fine

This removes some false positives from the unaligned_references lint: in a `repr(packed(2))` struct, fields of alignment 2 (and less) are guaranteed to be properly aligned, so we do not have to consider them "disaligned".

Add escape_default method to u8 and [u8]

Auto merge of #83619 - petrochenkov:nx, r=nagisa

linker: Use data execution prevention options by default when linker supports them

Do it in a centralized way in `link.rs` instead of individual target specs.
r? `@nagisa`

linker: Use data execution prevention options by default when linker supports them

Auto merge of #83602 - JohnTitor:cloudabi-flag-is-unnecessary, r=Xanewok

Remove unnecessary `ignore-cloudabi` flag

...since we dropped the CloudABI support.

ffi::c_str added tests for empty strings

test: run-make: skip tests on unsupported platforms

The tests issue-36710 and incr-prev-body-beyond-eof were changed in a
previous commit so that the correct target was passed to rustc
(previously rustc was building for the host not for the specific
target).

Since that change it turns out that these platforms never worked (they
only appeared to work because rustc was actually building for the host
architecture).

The wasm architectures fall over trying to build the C++ file in
issue-36710. They look for clang (which isn't installed in the
test-various docker container). If clang is installed, they can't find
a wasm c++ standard library to link to.

nvtptx64-nvidia-cuda fails in rustc saying it can't find std. The rust
platforms support page says that std is supported on cuda so this is
surprising.

dist-i586-gnu-i586-i686-musl can't find the C++ compiler. There is only
a musl-gcc and no musl-g++ in /musl-i586/bin/. The Docker image probably
needs tweaking.

test: run-make: flag tests which won't work in no-std environments

ci: docker: x86_64: specify host explicitly

bootstrap: don't run linkcheck when crosscompiling

When we cross compile, some things (and their documentation) are built
for the host (e.g. rustc), while others (and their documentation) are built
for the target. This generated documentation will have broken links
between documentation for different platforms e.g. between rustc and
cargo.

ci: docker: riscv64gc: specify host explicitly

run-make: skip issue-36710 on riscv64 and armhf

The test assumes it can run target binaries on the host. This not true
for riscv64 CI (or for other platforms using remote-test-server).

run-make: Specify --target to rustc

Resolves #78911

The target's linker was used but rustc wasn't told to build for that
target (instead defaulting to the host). This led to the host instead of
the target getting tested and to the linker getting inappropriate
arguments.

Auto merge of #83582 - jyn514:might-not, r=joshtriplett

may not -> might not

may not -> might not

"may not" has two possible meanings:
1. A command: "You may not stay up past your bedtime."
2. A fact that's only sometimes true: "Some cities may not have bike lanes."

In some cases, the meaning is ambiguous: "Some cars may not have snow
tires." (do the cars *happen* to not have snow tires, or is it
physically impossible for them to have snow tires?)

This changes places where the standard library uses the "description of
fact" meaning to say "might not" instead.

This is just `std::vec` for now - if you think this is a good idea I can
convert the rest of the standard library.

adjust old test

Auto merge of #83577 - geeklint:slice_to_ascii_case_doc_links, r=m-ou-se

Adjust documentation links for slice::make_ascii_*case

The documentation for the functions `slice::to_ascii_lowercase` and `slice::to_ascii_uppercase` contain the suggestion

> To lowercase the value in-place, use `make_ascii_lowercase`

however the link to the suggested method takes you to the page for `u8`, rather than the method of that name on the same page.

unaligned_references: align(N) fields in packed(N) structs are fine

update Miri

Auto merge of #83593 - petrochenkov:nounwrap, r=nagisa

rustc_target: Avoid unwraps when adding linker flags

These `unwrap`s assume that some linker flags were already added by `*_base::opts()` methods, but that's doesn't necessarily remain the case when we are reducing the number of flags hardcoded in targets, as https://github.com/rust-lang/rust/pull/83587 shows.

r? `@nagisa`

Remove unnecessary `ignore-cloudabi` flag

Auto merge of #81728 - Qwaz:fix-80335, r=joshtriplett

Fixes API soundness issue in join()

Fixes #80335

Auto merge of #81354 - SkiFire13:binary-search-assume, r=nagisa

Instruct LLVM that binary_search returns a valid index

This allows removing bound checks when the return value of `binary_search` is used to index into the slice it was call on. I also added a codegen test for this, not sure if it's the right thing to do (I didn't find anything on the dev guide), but it felt so.

Address more review comments

- Add back various diagnostic methods on `Session`.

  It seems unfortunate to duplicate these in so many places, but in the
  meantime, making the API inconsistent between `Session` and `Diagnostic`
  also seems unfortunate.

- Add back TyCtxtAt methods

  These will hopefully be used in the near future.

- Add back `with_const`, it would need to be added soon after anyway.
- Add back `split()` and `get_mut()`, they're useful.

Fix compiler docs

Address review comments

- Add back `HirIdVec`, with a comment that it will soon be used.
- Add back `*_region` functions, with a comment they may soon be used.
- Remove `-Z borrowck_stats` completely. It didn't do anything.
- Remove `make_nop` completely.
- Add back `current_loc`, which is used by an out-of-tree tool.
- Fix style nits
- Remove `AtomicCell` with `cfg(parallel_compiler)` for consistency.

Remove (lots of) dead code

Found with https://github.com/est31/warnalyzer.

Dubious changes:
- Is anyone else using rustc_apfloat? I feel weird completely deleting
  x87 support.
- Maybe some of the dead code in rustc_data_structures, in case someone
  wants to use it in the future?
- Don't change rustc_serialize

  I plan to scrap most of the json module in the near future (see
  https://github.com/rust-lang/compiler-team/issues/418) and fixing the
  tests needed more work than I expected.

TODO: check if any of the comments on the deleted code should be kept.

Remove unused `DiagnosticBuilder::sub` function

`Diagnostic::sub` is only ever used directly; it doesn't need to be
included in the builder.

Auto merge of #83587 - petrochenkov:asneeded, r=nagisa

linker: Use `--as-needed` by default when linker supports it

Do it in a centralized way in `link.rs` instead of individual target specs.
Majority of relevant target specs were already passing it.

rustc_target: Avoid unwraps when adding linker flags

linker: Use `--as-needed` by default when linker supports it

Auto merge of #83103 - petrochenkov:unilex, r=Aaron1011

resolve: Partially unify early and late scope-relative identifier resolution

Reuse `early_resolve_ident_in_lexical_scope` instead of a chunk of code in `resolve_ident_in_lexical_scope` doing the same job.

`early_resolve_ident_in_lexical_scope`/`visit_scopes` had to be slightly extended to be able to 1) start from a specific module instead of the current parent scope and 2) report one deprecation lint.
`early_resolve_ident_in_lexical_scope` still doesn't support walking through "ribs", that part is left in `resolve_ident_in_lexical_scope` (moreover, I'm pretty sure it's buggy, but that's a separate issue, cc https://github.com/rust-lang/rust/issues/52389 at least).

resolve: Partially unify early and late scope-relative ident resolution

may not -> might not

"may not" has two possible meanings:
1. A command: "You may not stay up past your bedtime."
2. A fact that's only sometimes true: "Some cities may not have bike lanes."

In some cases, the meaning is ambiguous: "Some cars may not have snow
tires." (do the cars *happen* to not have snow tires, or is it
physically impossible for them to have snow tires?)

This changes places where the standard library uses the "description of
fact" meaning to say "might not" instead.

This is just `std::vec` for now - if you think this is a good idea I can
convert the rest of the standard library.

Auto merge of #83580 - Dylan-DPC:rollup-1zod4p7, r=Dylan-DPC

Rollup of 8 pull requests

Successful merges:

 - #81351 (combine: stop eagerly evaluating consts)
 - #82525 (make unaligned_references future-incompat lint warn-by-default)
 - #82626 (update array missing `IntoIterator` msg)
 - #82917 (Add function core::iter::zip)
 - #82993 (rustdoc: Use diagnostics for error when including sources)
 - #83522 (Improve fs error open_from unix)
 - #83548 (Always preserve `None`-delimited groups in a captured `TokenStream`)
 - #83555 (Add #[inline] to io::Error methods)

Failed merges:

 - #83130 (escape_ascii take 2)

r? `@ghost`
`@rustbot` modify labels: rollup

Rollup merge of #83555 - m-ou-se:inline-io-error-new-const, r=jackh726

Add #[inline] to io::Error methods

Fixes #82812

Rollup merge of #83548 - Aaron1011:capture-none-delims, r=petrochenkov

Always preserve `None`-delimited groups in a captured `TokenStream`

Previously, we would silently remove any `None`-delimiters when
capturing a `TokenStream`, 'flattenting' them to their inner tokens.
This was not normally visible, since we usually have
`TokenKind::Interpolated` (which gets converted to a `None`-delimited
group during macro invocation) instead of an actual `None`-delimited
group.

However, there are a couple of cases where this becomes visible to
proc-macros:
1. A cross-crate `macro_rules!` macro has a `None`-delimited group
   stored in its body (as a result of being produced by another
   `macro_rules!` macro). The cross-crate `macro_rules!` invocation
   can then expand to an attribute macro invocation, which needs
   to be able to see the `None`-delimited group.
2. A proc-macro can invoke an attribute proc-macro with its re-collected
   input. If there are any nonterminals present in the input, they will
   get re-collected to `None`-delimited groups, which will then get
   captured as part of the attribute macro invocation.

Both of these cases are incredibly obscure, so there hopefully won't be
any breakage. This change will allow more agressive 'flattenting' of
nonterminals in #82608 without losing `None`-delimited groups.

Rollup merge of #83522 - pickfire:patch-6, r=JohnTitor

Improve fs error open_from unix

Consistency for #79399
Suggested by JohnTitor

r? `@JohnTitor`

Not user if the error is too long now, do we handle long errors well?

Rollup merge of #82993 - camelid:source-use-diag, r=jyn514

rustdoc: Use diagnostics for error when including sources

This error probably almost never happens, but we should still use the
diagnostic infrastructure. My guess is that the error was added back
before rustdoc used the rustc diagnostic infrastructure (it was all
`println!` and `eprintln!` back then!) and since it likely rarely occurs
and this code doesn't change that much, no one thought to transition it
to using diagnostics.

Note that the old error was actually a warning (it didn't stop the rest
of doc building). It seems very unlikely that this would fail without
the rest of the doc build failing, so it makes more sense for it to be a
hard error.

The error looks like this:

    error: failed to render source code for `src/test/rustdoc/smart-punct.rs`: "bar": foo
      --> src/test/rustdoc/smart-punct.rs:3:1
       |
    3  | / #![crate_name = "foo"]
    4  | |
    5  | | //! This is the "start" of the 'document'! How'd you know that "it's" ...
    6  | | //!
    ...  |
    22 | | //! I say "don't smart-punct me -- please!"
    23 | | //! ```
       | |_______^

I wasn't sure how to trigger the error, so to create that message I
temporarily made rustdoc always emit it. That's also why it says "bar"
and "foo" instead of a real error message.

Note that the span of the diagnostic starts at line 3 because line 1 of
that file is a (non-doc) comment and line 2 is a blank line.

Rollup merge of #82917 - cuviper:iter-zip, r=m-ou-se

Add function core::iter::zip

This makes it a little easier to `zip` iterators:

```rust
for (x, y) in zip(xs, ys) {}
// vs.
for (x, y) in xs.into_iter().zip(ys) {}
```

You can `zip(&mut xs, &ys)` for the conventional `iter_mut()` and
`iter()`, respectively. This can also support arbitrary nesting, where
it's easier to see the item layout than with arbitrary `zip` chains:

```rust
for ((x, y), z) in zip(zip(xs, ys), zs) {}
for (x, (y, z)) in zip(xs, zip(ys, zs)) {}
// vs.
for ((x, y), z) in xs.into_iter().zip(ys).zip(xz) {}
for (x, (y, z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {}
```

It may also format more nicely, especially when the first iterator is a
longer chain of methods -- for example:

```rust
    iter::zip(
        trait_ref.substs.types().skip(1),
        impl_trait_ref.substs.types().skip(1),
    )
    // vs.
    trait_ref
        .substs
        .types()
        .skip(1)
        .zip(impl_trait_ref.substs.types().skip(1))
```

This replaces the tuple-pair `IntoIterator` in #78204.
There is prior art for the utility of this in [`itertools::zip`].

[`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html

Rollup merge of #82626 - lcnr:encode_with_shorthandb, r=estebank

update array missing `IntoIterator` msg

fixes #82602

r? ```@estebank``` do you know whether we can use the expr span in `rustc_on_unimplemented`? The label isn't too great rn

Rollup merge of #82525 - RalfJung:unaligned-ref-warn, r=petrochenkov

make unaligned_references future-incompat lint warn-by-default

and also remove the safe_packed_borrows lint that it replaces.

`std::ptr::addr_of!` has hit beta now and will hit stable in a month, so I propose we start fixing https://github.com/rust-lang/rust/issues/27060 for real: creating a reference to a field of a packed struct needs to eventually become a hard error; this PR makes it a warn-by-default future-incompat lint. (The lint already existed, this just raises its default level.) At the same time I removed the corresponding code from unsafety checking; really there's no reason an `unsafe` block should make any difference here.

For references to packed fields outside `unsafe` blocks, this means `unaligned_refereces` replaces the previous `safe_packed_borrows` warning with a link to https://github.com/rust-lang/rust/issues/82523 (and no more talk about unsafe blocks making any difference). So behavior barely changes, the warning is just worded differently. For references to packed fields inside `unsafe` blocks, this PR shows a new future-incompat warning.

Closes https://github.com/rust-lang/rust/issues/46043 because that lint no longer exists.

Rollup merge of #81351 - lcnr:big-money-big-prices, r=oli-obk

combine: stop eagerly evaluating consts

`super_relate_consts` eagerly evaluates constants which doesn't seem too great.

I now also finally understand why all of the unused substs test passed. The reason being
that we just evaluated the constants in `super_relate_consts` :laughing:

While this change isn't strictly necessary as evaluating consts here doesn't hurt, it still feels a lot cleaner to do it this way

r? `@oli-obk` `@nikomatsakis`

revert rustdoc links in core to use #method. because they link to alloc, which may not be available

clarify 'remains attached', and remove recommendation to use integer arithmetic

add definition of 'allocated object', and link it from relevant method docs

adjust documentation links for slice ascii case functions to use newer rustdoc link format

update links to make_ascii_lowercase for slice to point to methods on the same type, rather than on u8

Add the tracking issue for `#![feature(iter_zip)]`

Auto merge of #83573 - JohnTitor:rollup-28jnzsr, r=JohnTitor

Rollup of 10 pull requests

Successful merges:

 - #79399 (Use detailed and shorter fs error explaination)
 - #83348 (format macro argument parsing fix)
 - #83462 (ExitStatus: print "exit status: {}" rather than "exit code: {}" on unix)
 - #83526 (lazily calls some fns)
 - #83558 (Use DebugStruct::finish_non_exhaustive() in std.)
 - #83559 (Fix Debug implementation for RwLock{Read,Write}Guard.)
 - #83560 (Derive Debug for io::Chain instead of manually implementing it.)
 - #83561 (Improve Debug implementations of Mutex and RwLock.)
 - #83567 (Update rustup cross-compilation docs link)
 - #83569 (Add regression tests for #56445)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup

Rollup merge of #83569 - sjakobi:issue56445-regression-test, r=jackh726

Add regression tests for #56445

Closes #56445.

Rollup merge of #83567 - jonjensen:patch-1, r=GuillaumeGomez

Update rustup cross-compilation docs link

Rollup merge of #83561 - m-ou-se:lock-debug, r=jackh726

Improve Debug implementations of Mutex and RwLock.

This improves the Debug implementations of Mutex and RwLock.

They now show the poison flag and use debug_non_exhaustive. (See #67364.)

Rollup merge of #83560 - m-ou-se:io-chain-debug, r=sfackler

Derive Debug for io::Chain instead of manually implementing it.

This derives Debug for io::Chain instead of manually implementing it.

The manual implementation has the same bounds, so I don't think there's any reason for a manual implementation. The names used in the derive implementation are even nicer (`first`/`second`) than the manual implementation (`t`/`u`), and include the `done_first` field too.

Rollup merge of #83559 - m-ou-se:rwlock-guard-debug-fix, r=jackh726

Fix Debug implementation for RwLock{Read,Write}Guard.

This would attempt to print the Debug representation of the lock that the guard has locked, which will try to lock again, fail, and just print `"<locked>"` unhelpfully.

After this change, this just prints the contents of the mutex, like the other smart pointers (and MutexGuard) do.

MutexGuard had this problem too: https://github.com/rust-lang/rust/issues/57702

Rollup merge of #83558 - m-ou-se:use-finish-non-exhaustive, r=jackh726

Use DebugStruct::finish_non_exhaustive() in std.

See https://github.com/rust-lang/rust/issues/67364

Rollup merge of #83526 - klensy:lazy-too, r=petrochenkov

lazily calls some fns

Replaced some fn's with it's lazy variants.

Rollup merge of #83462 - ijackson:exitstatus-message-wording, r=joshtriplett

ExitStatus: print "exit status: {}" rather than "exit code: {}" on unix

Proper Unix terminology is "exit status" (vs "wait status").  "exit
code" is imprecise on Unix and therefore unclear.  (As far as I can
tell, "exit code" is correct terminology on Windows.)

This new wording is unfortunately inconsistent with the identifier
names in the Rust stdlib.

It is the identifier names that are wrong, as discussed at length in eg
  https://doc.rust-lang.org/nightly/std/process/struct.ExitStatus.html
  https://doc.rust-lang.org/nightly/std/os/unix/process/trait.ExitStatusExt.html

Unfortunately for API stability reasons it would be a lot of work, and
a lot of disruption, to change the names in the stdlib (eg to rename
`std::process::ExitStatus` to `std::process::ChildStatus` or
something), but we should fix the message output.  Many (probably
most) readers of these messages about exit statuses will be users and
system administrators, not programmers, who won't even know that Rust
has this wrong terminology.

So I think the right thing is to fix the documentation (as I have
already done) and, now, the terminology in the implementation.

This is a user-visible change to the behaviour of all Rust programs
which run Unix subprocesses.  Hopefully no-one is matching against the
exit status string, except perhaps in tests.

Rollup merge of #83348 - osa1:issue83344, r=jackh726

format macro argument parsing fix

When the character next to `{}` is "shifted" (when mapping a byte index
in the format string to span) we should avoid shifting the span end
index, so first map the index of `}` to span, then bump the span,
instead of first mapping the next byte index to a span (which causes
bumping the end span too much).

Regression test added.

Fixes #83344

---

r? ```@estebank```

Rollup merge of #79399 - pickfire:patch-3, r=JohnTitor

Use detailed and shorter fs error explaination

Includes suggestion from `@the8472` https://github.com/rust-lang/rust/issues/79390#issuecomment-733263336

Make all compiler-builtins symbols hidden

This matches cg_llvm

Fixes #1152

make unaligned_refereces future-incompat lint warn-by-default, and remove the safe_packed_borrows lint that it replaces

update tests

combine: stop eagerly evaluating consts

Constantify some slice methods

Add regression tests for #56445

Closes #56445.

update comment at MaybeUninit::uninit_array

Update rustup cross-compilation docs link

Auto merge of #83245 - the8472:generalize-slice-fill, r=m-ou-se

Generalize and inline slice::fill specializations

This makes the memset specialization applicable to more types. And since the code now lives in a generic method it is also eligible for cross-crate inlining which  should fix #83235

Improve fs error open_from unix

Consistency for #79399
Suggested by JohnTitor

Improve fs error invaild input for sys_common

The text was duplicated from unix.

Run Miri test suite with mir-opt-level=4

Use detailed and shorter fs error explaination

Includes suggestion from the8472 https://github.com/rust-lang/rust/issues/79390#issuecomment-733263336

More detail error explanation in fs doc

Improve Debug implementations of Mutex and RwLock.

They now show the poison flag and use debug_non_exhaustive.

Derive Debug for io::Chain instead of manually implementing it.

The manual implementation has the same bounds, so I don't think there's
any reason for a manual implementation. The names used in the derive
implementation are even nicer (`first`/`second`) than the manual
implementation (`t`/`u`), and include the `done_first` field too.

Fix Debug implementation for RwLock{Read,Write}Guard.

This would attempt to print the Debug representation of the lock that
the guard has locked, which will try to lock again, fail, and just print
"<locked>" unhelpfully.

After this change, this just prints the contents of the mutex, like the
other smart pointers (and MutexGuard) do.

Use DebugStruct::finish_non_exhaustive() in std.

Add #[inline] to io::Error methods.

Auto merge of #78618 - workingjubilee:ieee754-fmt, r=m-ou-se

Add IEEE 754 compliant fmt/parse of -0, infinity, NaN

This pull request improves the Rust float formatting/parsing libraries to comply with IEEE 754's formatting expectations around certain special values, namely signed zero, the infinities, and NaN. It also adds IEEE 754 compliance tests that, while less stringent in certain places than many of the existing flt2dec/dec2flt capability tests, are intended to serve as the beginning of a roadmap to future compliance with the standard. Some relevant documentation is also adjusted with clarifying remarks.

This PR follows from discussion in https://github.com/rust-lang/rfcs/issues/1074, and closes #24623.

The most controversial change here is likely to be that -0 is now printed as -0. Allow me to explain: While there appears to be community support for an opt-in toggle of printing floats as if they exist in the naively expected domain of numbers, i.e. not the extended reals (where floats live), IEEE 754-2019 is clear that a float converted to a string should be capable of being transformed into the original floating point bit-pattern when it satisfies certain conditions (namely, when it is an actual numeric value i.e. not a NaN and the original and destination float width are the same). -0 is given special attention here as a value that should have its sign preserved. In addition, the vast majority of other programming languages not only output `-0` but output `-0.0` here.

While IEEE 754 offers a broad leeway in how to handle producing what it calls a "decimal character sequence", it is clear that the operations a language provides should be capable of round tripping, and it is confusing to advertise the f32 and f64 types as binary32 and binary64 yet have the most basic way of producing a string and then reading it back into a floating point number be non-conformant with the standard. Further, existing documentation suggested that e.g. -0 would be printed with -0 regardless of the presence of the `+` fmt character, but it prints "+0" instead if given such (which was what led to the opening of #24623).

There are other parsing and formatting issues for floating point numbers which prevent Rust from complying with the standard, as well as other well-documented challenges on the arithmetic level, but I hope that this can be the beginning of motion towards solving those challenges.

format macro argument parsing fix

When the character next to `{}` is "shifted" (when mapping a byte index
in the format string to span) we should avoid shifting the span end
index, so first map the index of `}` to span, then bump the span,
instead of first mapping the next byte index to a span (which causes
bumping the end span too much).

Regression test added.

Fixes #83344

Auto merge of #83547 - JohnTitor:rollup-qh7j6hg, r=JohnTitor

Rollup of 9 pull requests

Successful merges:

 - #83239 (Remove/replace some outdated crates from the dependency tree)
 - #83328 (Fixes to inline assmebly tests)
 - #83343 (Simplify and fix byte skipping in format! string parser)
 - #83388 (Make # pretty print format easier to discover)
 - #83431 (Tell GitHub to highlight `config.toml.example` as TOML)
 - #83508 (Use the direct link to the platform support page)
 - #83511 (compiletest: handle llvm_version with suffix like "12.0.0libcxx")
 - #83524 (Document that the SocketAddr memory representation is not stable)
 - #83525 (fix doc comment for `ty::Dynamic`)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup

lazily calls some fns

Rollup merge of #83525 - rust-lang:lcnr-doc-patch, r=jonas-schievink

fix doc comment for `ty::Dynamic`

Rollup merge of #83524 - faern:document-socketaddr-mem-layout, r=sfackler

Document that the SocketAddr memory representation is not stable

Intended to help out with #78802. Work has been put into finding and fixing code that assumes the memory layout of `SocketAddrV4` and `SocketAddrV6`. But it turns out there are cases where new code continues to make the same assumption ([example](https://github.com/spacejam/seaslug/commit/96927dc2b7b918860a79c4eb6336051e52c6137a#diff-917db3d8ca6f862ebf42726b23c72a12b35e584e497ebdb24e474348d7c6ffb6R610-R621)).

The memory layout of a type in `std` is never part of the public API. Unless explicitly stated I guess. But since that is invalidly relied upon by a considerable amount of code for these particular types, it might make sense to explicitly document this. This can be temporary. Once #78802 lands it does not make sense to rely on the layout any longer, and this documentation can also be removed.

Rollup merge of #83511 - 12101111:fix-llvm-version-suffix, r=Mark-Simulacrum

compiletest: handle llvm_version with suffix like "12.0.0libcxx"

The previous code only remove the suffix begin with `-`, but Gentoo Linux [define `LLVM_VERSION_SUFFIX="libcxx"`](https://github.com/gentoo/gentoo/blob/604d79f327176eecb05293d7154e24231229cb31/sys-devel/llvm/llvm-11.1.0.ebuild#L378) when llvm is linked to libc++ and lead to a panic:

```
thread 'main' panicked at 'Malformed version component: ParseIntError { kind: InvalidDigit }', src/tools/compiletest/src/header.rs:968:28
```

This new code will handle all suffix not beginning with digit or dot.

Rollup merge of #83508 - JohnTitor:platform-support-link, r=joshtriplett

Use the direct link to the platform support page

Rollup merge of #83431 - camelid:config-example-gitattributes, r=Mark-Simulacrum

Tell GitHub to highlight `config.toml.example` as TOML

This should be a nice small quality of life improvement when looking at
`config.toml.example` on GitHub or looking at diffs of it in PRs.

Rollup merge of #83388 - alamb:alamb/fmt-dcs, r=Mark-Simulacrum

Make # pretty print format easier to discover

# Rationale:

I use (cargo cult?) three formats in rust:  `{}`, debug `{:?}`, and pretty-print debug `{:#?}`. I discovered `{:#?}` in some blog post or guide when I started working in Rust. While `#` is documented I think it is hard to discover. So taking the good advice of ```@carols10cents```  I am trying to improve the docs with a PR

As a reminder "pretty print" means that where `{:?}` will print something like
```
foo: { b1: 1, b2: 2}
```

`{:#?}` will prints something like
```
foo {
  b1: 1
  b2: 3
}
```

# Changes
Add an example to `fmt` to try and make it easier to discover `#`