Provide a better diagnostic if ninja isn't installed

Let people know that they can set ninja=false if they don't want to
install ninja.

Install ninja on CI builders

Windows CI builds already install ninja. Install it in all the
Docker-based builds as well.

Disable ninja on macOS CI

Should be re-enabled when we have a recipe for installing ninja on
macOS.

Set ninja=true by default

Ninja substantially improves LLVM build time. On a 96-way system, using
Make took 248s, and using Ninja took 161s, a 35% improvement.

We already require a variety of tools to build Rust. If someone wants to
build without Ninja (for instance, to minimize the set of packages
required to bootstrap a new target), they can easily set `ninja=false`
in `config.toml`.  Our defaults should help people build Rust (and LLVM)
faster, to speed up development.

Auto merge of #75912 - scottmcm:manuallydrop-vs-forget, r=Mark-Simulacrum

Suggest `mem::forget` if `mem::ManuallyDrop::new` isn't used

I think this communicates the intent more idiomatically, and is shorter anyway.

Inspired because [it came up on URLO](https://users.rust-lang.org/t/validity-of-memory-area-after-std-forget/47730/7?u=scottmcm), and it turns out that std had done it too in one spot:

Auto merge of #75903 - jyn514:lint-refactor, r=GuillaumeGomez

Warn about unknown or renamed lints in rustdoc

Fixes https://github.com/rust-lang/rust/issues/75884.
This is best reviewed one commit at a time.
r? @GuillaumeGomez

Originally I tried to do a much broader refactoring that got rid of `init_lints` altogether. My reasoning is that now the lints aren't being run anymore (after https://github.com/rust-lang/rust/pull/73566), there's no need to ignore them explicitly. But it seems there are still some lints that aren't affected by setting `lint_mod` to a no-op:

```
deny(pub_use_of_private_extern_crate)
deny(const_err)
warn(unused_imports)
```

(there are possibly more, these are just the ones that failed in the rustdoc test suite).

Some of these seem like we really should be warning about, but that's a much larger change and I don't propose to make it here. So for the time being, this just adds the `unknown_lints` and `renamed_or_removed_lints` passes to the list of lints rustdoc warns about.

Auto merge of #75893 - Dylan-DPC:fix/offset-to-u64, r=oli-obk

change offset from u32 to u64

References #71696

r? @oli-obk

(closed the earlier pr because the rebase got messed up)

Auto merge of #75687 - TimDiekmann:realloc-align, r=Amanieu

Allow reallocation to different alignment in `AllocRef`

The allocator-wg [has decided](https://github.com/rust-lang/wg-allocators/issues/5#issuecomment-672591112) to support reallocating to a different alignment in `AllocRef`. For more details please see the linked issue.

r? @Amanieu

closes https://github.com/rust-lang/wg-allocators/issues/5

Auto merge of #75843 - hermitcore:devel, r=nagisa

HermitCore switchs to relocatable binaries

- switch to relocatbale binaries to realize ASLR
- remove all dependencies to gcc

Auto merge of #75811 - ecstatic-morse:better-dlerror, r=nagisa

Refactor dynamic library error checking on *nix

The old code was checking `dlerror` more often than necessary, since (unlike `dlsym`) checking the return value of [`dlopen`](https://www.man7.org/linux/man-pages/man3/dlopen.3.html) is enough to indicate whether an error occurred. In the first commit, I've refactored the code to minimize the number of system calls needed. It should be strictly better than the old version.

The second commit is an optional addendum which fixes the issue observed on illumos in #74469, a PR I reviewed that was ultimately closed due to inactivity. I'm not sure how hard we try to work around platform-specific bugs like this, and I believe that, due to the way that `dlerror` is specified in the POSIX standard, libc implementations that want to run on conforming systems cannot call `dlsym` in multi-threaded programs.

Auto merge of #75302 - Aaron1011:feature/partial-move-diag, r=estebank

Be consistent when describing a move as a 'partial' in diagnostics

When an error occurs due to a partial move, we would use the world
"partial" in some parts of the error message, but not in others. This
commit ensures that we use the word 'partial' in either all or none of
the diagnostic messages.

Additionally, we no longer describe a move out of a `Box` via `*` as
a 'partial move'. This was a pre-existing issue, but became more
noticable when the word 'partial' is used in more places.

Explicitly pass `RTLD_LOCAL` to `dlopen`

This happens to be the default on Linux, but the default is unspecified
in the POSIX standard. Also switches to `cast` to keep line lengths in
check.

Always treat `dlsym` returning NULL as an error

This simplifies the code somewhat. Also updates comments to reflect
notes from reviw about thread-safety of `dlerror`.

Auto merge of #74275 - wesleywiser:break_up_partitioning_rs, r=pnkfelix

Refactor the partitioning module to make it easier to introduce new algorithms

I've split the `librustc_mir::monomorphize::partitioning` module into a few files and introduced a `Partitioner` trait which allows us to decouple the partitioning algorithm from the code which integrates it into the query system. This should allow us to introduce new partitioning algorithms much more easily. I've also gone ahead and added a `-Z` flag to control which algorithm is used (currently there is only the `default`).

I left a few comments in places where things might be improved further.

r? @pnkfelix cc @rust-lang/wg-incr-comp

Suggest `mem::forget` if `mem::ManuallyDrop::new` isn't used

I think this communicates the intent better, and is shorter anyway.

Auto merge of #75908 - pietroalbini:ci-bump-llvm, r=Mark-Simulacrum

Bump LLVM on CI to 10.0.0

This PR bumps the LLVM version we use on our macOS and Windows CI to 10.0.0, fixing a breakage we noticed today:

```
2020-08-25T14:24:28.5939568Z FAILED: lib/Support/CMakeFiles/LLVMSupport.dir/AMDGPUMetadata.cpp.obj
2020-08-25T14:24:28.5940317Z D:\a\rust\rust\build\bootstrap\debug\sccache-plus-cl.exe  /nologo -TP -DGTEST_HAS_RTTI=0 -DUNICODE -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NONSTDC_NO_WARNINGS -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS -D_HAS_EXCEPTIONS=0 -D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -D_UNICODE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib\Support -ID:\a\rust\rust\src\llvm-project\llvm\lib\Support -Iinclude -ID:\a\rust\rust\src\llvm-project\llvm\include -nologo -MT -Brepro --target=x86_64-pc-windows-msvc /Zc:inline /Zc:strictStrings /Oi /Zc:rvalueCast /Brepro /W4  -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wno-noexcept-type -Wno-comment /Gw /MT /O2 /Ob2 -UNDEBUG -std:c++14  /EHs-c- /GR- /showIncludes /Folib\Support\CMakeFiles\LLVMSupport.dir\AMDGPUMetadata.cpp.obj /Fdlib\Support\CMakeFiles\LLVMSupport.dir\LLVMSupport.pdb -c D:\a\rust\rust\src\llvm-project\llvm\lib\Support\AMDGPUMetadata.cpp
2020-08-25T14:24:28.5940861Z clang-cl: warning: argument unused during compilation: '-Brepro' [-Wunused-command-line-argument]
2020-08-25T14:24:28.5941076Z clang-cl: warning: argument unused during compilation: '-Brepro' [-Wunused-command-line-argument]
2020-08-25T14:24:28.5941321Z In file included from D:\a\rust\rust\src\llvm-project\llvm\lib\Support\AMDGPUMetadata.cpp:15:
2020-08-25T14:24:28.5941545Z In file included from D:\a\rust\rust\src\llvm-project\llvm\include\llvm/ADT/Twine.h:12:
2020-08-25T14:24:28.5941774Z In file included from D:\a\rust\rust\src\llvm-project\llvm\include\llvm/ADT/SmallVector.h:16:
2020-08-25T14:24:28.5942016Z In file included from D:\a\rust\rust\src\llvm-project\llvm\include\llvm/ADT/iterator_range.h:21:
2020-08-25T14:24:28.5942257Z In file included from C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.27.29110\include\iterator:9:
2020-08-25T14:24:28.5942542Z C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.27.29110\include\yvals_core.h(494,2): error: STL1000: Unexpected compiler version, expected Clang 10.0.0 or newer.
```

I uploaded both the new tarballs to our mirrors bucket.

ci: fix macOS target name for LLVM 10

ci: bump LLVM source tarball on Linux to 10.0.0

ci: bump prebuilt LLVM on macOS and Windows to 10.0.0

Don't special case `warnings`

Warn about unknown or renamed lints

Originally I tried to do a much broader refactoring that got rid of `init_lints` altogether. My reasoning is that now the lints aren't being run anymore (after https://github.com/rust-lang/rust/pull/73566), there's no need to ignore them explicitly. But it seems there are still some lints that aren't affected by setting `lint_mod` to a no-op:

```
deny(pub_use_of_private_extern_crate)
deny(const_err)
warn(unused_imports)
```

(there are possibly more, these are just the ones that failed in the rustdoc test suite).

Some of these seem like we really should be warning about, but that's a much larger change and I don't propose to make it here. So for the time being, this just adds the `unknown_lints` and `renamed_or_removed_lints` passes to the list of lints rustdoc warns about.

Rename debugging_options -> debugging_opts to match rustc

This way the rustdoc field names are the same as the rustc field names.

Minor refactors

Auto merge of #75838 - mati865:profiler-atomics, r=Amanieu

Profiler: reenable atomics after #65214

Auto merge of #75773 - matklad:snapshot-tests, r=Mark-Simulacrum

Introduce expect snapshot testing library into rustc

Snapshot testing is a technique for writing maintainable unit tests.
Unlike usual `assert_eq!` tests, snapshot tests allow
to *automatically* upgrade expected values on test failure.
In a sense, snapshot tests are inline-version of our beloved
UI-tests.

Example:


A particular library we use, `expect_test` provides an `expect!`
macro, which creates a sort of self-updating string literal (by using
`file!` macro). Self-update is triggered by setting `UPDATE_EXPECT`
environmental variable (this info is printed during the test failure).
This library was extracted from rust-analyzer, where we use it for
most of our tests.

There are some other, more popular snapshot testing libraries:

* https://github.com/mitsuhiko/insta
* https://github.com/aaronabramov/k9

The main differences of `expect` are:

* first-class snapshot objects (so, tests can be written as functions,
  rather than as macros)
* focus on inline-snapshots (but file snapshots are also supported)
* restricted feature set (only `assert_eq` and `assert_debug_eq`)
* no extra runtime (ie, no `cargo insta`)

See rust-analyzer/rust-analyzer#5101 for a
an extended comparison.

It is unclear if this testing style will stick with rustc in the long
run. At the moment, rustc is mainly tested via integrated UI tests.
But in the library-ified world, unit-tests will become somewhat more
important (that's why use use `rustc_lexer` library-ified library as
an example in this PR). Given that the cost of removal shouldn't be
too high, it probably makes sense to just see if this flies!

Auto merge of #75364 - rylev:libpanic-abort-failfast, r=alexcrichton

Call into fastfail on abort in libpanic_abort on Windows x86(_64)

This partially resolves #73215 though this is only for x86 targets. This code is directly lifted from [libstd](https://github.com/rust-lang/rust/blob/13290e83a6e20f3b408d177a9d64d8cf98fe4615/library/std/src/sys/windows/mod.rs#L315). `__fastfail` is the preferred way to abort a process on Windows as it will hook into debugger toolchains.

Other platforms expose a `_rust_abort` symbol which wraps `std::sys::abort_internal`. This would also work on Windows, but is a slightly largely change as we'd need to make sure that the symbol is properly exposed to the linker. I'm inlining the call to the `__fastfail`, but the indirection through `rust_abort` might be a cleaner approach.

 A different instruction must be used on ARM architectures. I'd like to verify this works first before tackling ARM.

Auto merge of #75132 - scottmcm:stabilize-range-is-empty, r=dtolnay

Stabilize Range[Inclusive]::is_empty

I would like to propose these two simple methods for stabilization:
- Knowing that a range is exhausted isn't otherwise trivial
- Clippy would like to suggest them, but had to do extra work to disable that path <https://github.com/rust-lang/rust-clippy/issues/3807> because they're unstable
- These work on `PartialOrd`, consistently with the stable `contains` method, and are thus more general than iterator-based approaches that need `Step`
- They've been unchanged for some time, and have picked up uses in the compiler
- Stabilizing them doesn't block any future iterator-based `is_empty` plans, as these inherent ones are preferred in name resolution

https://doc.rust-lang.org/nightly/std/ops/struct.Range.html#method.is_empty
https://doc.rust-lang.org/nightly/std/ops/struct.RangeInclusive.html#method.is_empty

Closes #48111

Auto merge of #75764 - workingjubilee:tidy-up-cargo-metadata, r=Mark-Simulacrum

bump tidy to cargo_metadata 0.11

Updates cargo_metadata in tidy's Cargo.toml from 0.9.1 to 0.11
Real version change 0.9.11 -> 0.11.1
https://github.com/oli-obk/cargo_metadata/compare/v0.9.1...v0.11.1

tidy

Auto merge of #75666 - davidtwco:tidy-lang-items, r=varkor

hir: consistent use and naming of lang items

This PR adjusts the naming of various lang items so that they are consistent and don't include prefixes containing the target or "LangItem". In addition, lang item variants are no longer exported from the `lang_items` module.

This is certainly subjective and while I think this is an improvement, if many in the team don't then we can just close this.

cleanup

Unbreak the clippy test

Auto merge of #75625 - mati865:mingw-cross-compile, r=Mark-Simulacrum

Fix windows-gnu host cross-compilation

Fixes https://github.com/rust-lang/rust/issues/64218

Also turns out it's faster to run Linux virtual machine on Windows and cross-compile `./x.py dist` than doing it on Windows directly...

removed not-needed conversion

Stabilize Range[Inclusive]::is_empty

I would like to propose these two simple methods for stabilization:
- Knowing that a range is exhaused isn't otherwise trivial
- Clippy would like to suggest them, but had to do extra work to disable that path <https://github.com/rust-lang/rust-clippy/issues/3807> because they're unstable
- These work on `PartialOrd`, consistently with now-stable `contains`, and are thus more general than iterator-based approaches that need `Step`
- They've been unchanged for some time, and have picked up uses in the compiler
- Stabilizing them doesn't block any future iterator-based is_empty plans, as the inherent ones are preferred in name resolution

Auto merge of #75110 - lzutao:ip-endianness, r=Mark-Simulacrum

Minor changes to Ipv4Addr

Minor changes to Ipv4Addr

* Impl IntoInner rather than AsInner for Ipv4Addr
* Add some comments
* Add test to show endiannes of Ipv4Addr display

Auto merge of #75876 - matklad:rust-analyzer-2020-08-24, r=matklad

:arrow_up: rust-analyzer

r? @ghost

Introduce expect snapshot testing library into rustc

Snapshot testing is a technique for writing maintainable unit tests.
Unlike usual `assert_eq!` tests, snapshot tests allow
to *automatically* upgrade expected values on test failure.
In a sense, snapshot tests are inline-version of our beloved
UI-tests.

Example:


A particular library we use, `expect_test` provides an `expect!`
macro, which creates a sort of self-updating string literal (by using
`file!` macro). Self-update is triggered by setting `UPDATE_EXPECT`
environmental variable (this info is printed during the test failure).
This library was extracted from rust-analyzer, where we use it for
most of our tests.

There are some other, more popular snapshot testing libraries:

* https://github.com/mitsuhiko/insta
* https://github.com/aaronabramov/k9

The main differences of `expect` are:

* first-class snapshot objects (so, tests can be written as functions,
  rather than as macros)
* focus on inline-snapshots (but file snapshots are also supported)
* restricted feature set (only `assert_eq` and `assert_debug_eq`)
* no extra runtime (ie, no `cargo insta`)

See https://github.com/rust-analyzer/rust-analyzer/pull/5101 for a
an extended comparison.

It is unclear if this testing style will stick with rustc in the long
run. At the moment, rustc is mainly tested via integrated UI tests.
But in the library-ified world, unit-tests will become somewhat more
important (that's why use use `rustc_lexer` library-ified library as
an example in this PR). Given that the cost of removal shouldn't be
too high, it probably makes sense to just see if this flies!

:arrow_up: rust-analyzer

Auto merge of #74590 - jyn514:timing, r=Mark-Simulacrum

Add some timing info to rustdoc

There are various improvements, but the main one is to time each pass
that rustdoc performs (`rustdoc::passes`).

Before, these were the top five timings for `cargo doc` on the cargo
repository:

```
+---------------------------------+-----------+-----------------+----------+------------+
| Item                            | Self time | % of total time | Time     | Item count |
+---------------------------------+-----------+-----------------+----------+------------+
| <unknown>                       | 854.70ms  | 20.888          | 2.47s    | 744823     |
+---------------------------------+-----------+-----------------+----------+------------+
| expand_crate                    | 795.29ms  | 19.436          | 848.00ms | 1          |
+---------------------------------+-----------+-----------------+----------+------------+
| metadata_decode_entry           | 256.73ms  | 6.274           | 279.49ms | 518344     |
+---------------------------------+-----------+-----------------+----------+------------+
| resolve_crate                   | 240.56ms  | 5.879           | 242.86ms | 1          |
+---------------------------------+-----------+-----------------+----------+------------+
| hir_lowering                    | 146.79ms  | 3.587           | 146.79ms | 1          |
+---------------------------------+-----------+-----------------+----------+------------+
```

Now the timings are:

```
+---------------------------------+-----------+-----------------+----------+------------+
| Item                            | Self time | % of total time | Time     | Item count |
+---------------------------------+-----------+-----------------+----------+------------+
| <unknown>                       | 1.40s     | 22.662          | 3.73s    | 771430     |
+---------------------------------+-----------+-----------------+----------+------------+
| collect-trait-impls             | 1.34s     | 21.672          | 2.87s    | 1          |
+---------------------------------+-----------+-----------------+----------+------------+
| expand_crate                    | 1.21s     | 19.577          | 1.28s    | 1          |
+---------------------------------+-----------+-----------------+----------+------------+
| build extern trait impl         | 704.66ms  | 11.427          | 1.07s    | 21893      |
+---------------------------------+-----------+-----------------+----------+------------+
| metadata_decode_entry           | 354.84ms  | 5.754           | 391.81ms | 544919     |
+---------------------------------+-----------+-----------------+----------+------------+
```

The goal is to help me debug regressions like https://github.com/rust-lang/rust/pull/74518#issuecomment-661498214 (currently I have _no_ idea what could have gone wrong).

r? @eddyb or @Mark-Simulacrum

hir: consistent use and naming of lang items

This commit adjusts the naming of various lang items so that they are
consistent and don't include prefixes containing the target or
"LangItem". In addition, lang item variants are no longer exported from
the `lang_items` module.

Signed-off-by: David Wood <david@davidtw.co>

Auto merge of #75815 - jyn514:ambiguous-primitives, r=guillaumegomez

Report an ambiguity if both modules and primitives are in scope for intra-doc links

Closes https://github.com/rust-lang/rust/issues/75381

- Add a new `prim@` disambiguator, since both modules and primitives are in the same namespace
- Refactor `report_ambiguity` into a closure

Additionally, I noticed that rustdoc would previously allow `[struct@char]` if `char` resolved to a primitive (not if it had a DefId). I fixed that and added a test case.

I also need to update libstd to use `prim@char` instead of `type@char`. If possible I would also like to refactor `ambiguity_error` to use `Disambiguator` instead of its own hand-rolled match - that ran into issues with `prim@` (I updated one and not the other) and it would be better for them to be in sync.

Auto merge of #75505 - Dylan-DPC:feature/arc_new, r=KodrAus

Add Arc::new_cyclic

Rework of #72443

References #75861

cc @Diggsey @RalfJung

r? @KodrAus

Auto merge of #75855 - jyn514:no-cfg-doc, r=ollie27

Use allow(unused_imports) instead of cfg(doc) for imports used only for intra-doc links

This prevents links from breaking when items are re-exported in a
different crate and the original isn't being documented.

Spotted in https://github.com/rust-lang/rust/pull/75832#discussion_r475275837 (thanks ollie!)

r? @ollie27

Auto merge of #75865 - JohnTitor:rollup-yxia6d2, r=JohnTitor

Rollup of 10 pull requests

Successful merges:

 - #75819 (Use intra-doc-links in `core::{char, macros, fmt}`)
 - #75821 (Switch to intra-doc links in `std::macros`)
 - #75825 (Fix typo in documentation of i32 wrapping_abs())
 - #75826 (Corrected Misleading documentation for derived Ord/PartialOrd implementation )
 - #75831 (doc: Prefer https link for wikipedia URLs)
 - #75844 (publish-toolstate: show more context on HTTP error)
 - #75847 (Switch to intra-doc links in `std::collections`)
 - #75851 (Switch to intra-doc links in `core::array`)
 - #75856 (more tool clippy fixes)
 - #75859 (doc: Fix typo in std::process::Child documentation)

Failed merges:

r? @ghost

Don't import atomics unless supported by the platform

Fix bad rebase

Had to use -Xignore-whitespace-conflicts to avoid awful conflicts, but
that threw off the indentation

Use underscores instead of spaces

Time how long it takes to render HTML

xpy fmt

Time running the global context

Separate `run_global_ctxt` into a separate function

Remove redundant timing for query

Time loading all crates, not each individual crate

Add some timing info to rustdoc

There are various improvements, but the main one is to time each pass
that rustdoc performs (`rustdoc::passes`).

Before, these were the top five timings for `cargo doc` on the cargo
repository:

```
+---------------------------------+-----------+-----------------+----------+------------+
| Item                            | Self time | % of total time | Time     | Item count |
+---------------------------------+-----------+-----------------+----------+------------+
| <unknown>                       | 854.70ms  | 20.888          | 2.47s    | 744823     |
+---------------------------------+-----------+-----------------+----------+------------+
| expand_crate                    | 795.29ms  | 19.436          | 848.00ms | 1          |
+---------------------------------+-----------+-----------------+----------+------------+
| metadata_decode_entry           | 256.73ms  | 6.274           | 279.49ms | 518344     |
+---------------------------------+-----------+-----------------+----------+------------+
| resolve_crate                   | 240.56ms  | 5.879           | 242.86ms | 1          |
+---------------------------------+-----------+-----------------+----------+------------+
| hir_lowering                    | 146.79ms  | 3.587           | 146.79ms | 1          |
+---------------------------------+-----------+-----------------+----------+------------+
```

Now the timings are:

```
+---------------------------------+-----------+-----------------+----------+------------+
| Item                            | Self time | % of total time | Time     | Item count |
+---------------------------------+-----------+-----------------+----------+------------+
| <unknown>                       | 1.40s     | 22.662          | 3.73s    | 771430     |
+---------------------------------+-----------+-----------------+----------+------------+
| collect-trait-impls             | 1.34s     | 21.672          | 2.87s    | 1          |
+---------------------------------+-----------+-----------------+----------+------------+
| expand_crate                    | 1.21s     | 19.577          | 1.28s    | 1          |
+---------------------------------+-----------+-----------------+----------+------------+
| build extern trait impl         | 704.66ms  | 11.427          | 1.07s    | 21893      |
+---------------------------------+-----------+-----------------+----------+------------+
| metadata_decode_entry           | 354.84ms  | 5.754           | 391.81ms | 544919     |
+---------------------------------+-----------+-----------------+----------+------------+
```

Rollup merge of #75859 - jrheard:patch-2, r=jonas-schievink

doc: Fix typo in std::process::Child documentation

Nearly done reading stdlib docs, found another small typo, here's a PR!

r? @steveklabnik

Rollup merge of #75856 - matthiaskrgr:more_clippy, r=Dylan-DPC

more tool clippy fixes

r? @Dylan-DPC

Rollup merge of #75851 - camelid:patch-2, r=jyn514

Switch to intra-doc links in `core::array`

Part of #75080.

@rustbot modify labels: A-intra-doc-links T-doc T-rustdoc

Rollup merge of #75847 - camelid:patch-1, r=dtolnay

Switch to intra-doc links in `std::collections`

Part of #75080.

@rustbot modify labels: A-intra-doc-links T-doc T-rustdoc

Rollup merge of #75844 - ehuss:publish-toolstate-httperror, r=Mark-Simulacrum

publish-toolstate: show more context on HTTP error

The default display for HTTPError in Python does not include the request body. For GitHub API, the body includes more details about the error (like rate limiting). This could help diagnosing errors like this: https://github.com/rust-lang/rust/pull/75815#issuecomment-678798158

Rollup merge of #75831 - lzutao:https, r=Dylan-DPC

doc: Prefer https link for wikipedia URLs

A tiny changes.

Rollup merge of #75826 - ayushmishra2005:misleading_documentation_for_derived_Ord_PartialOrd, r=KodrAus

Corrected Misleading documentation for derived Ord/PartialOrd implementation

Corrected Misleading documentation for derived Ord/PartialOrd implementation

Fixes #75620

Rollup merge of #75825 - jrheard:patch-1, r=steveklabnik

Fix typo in documentation of i32 wrapping_abs()

Hi!

I was reading through the std library docs and noticed that this section flowed a bit oddly; comparing it against https://doc.rust-lang.org/std/primitive.i32.html#method.wrapping_div and https://doc.rust-lang.org/std/primitive.i32.html#method.wrapping_neg , I noticed that those two pieces of documentation used a semicolon here.

This is my first time submitting a PR to this repo. Am I doing this right? Are tiny typo-fix PRs like this worth submitting, or are they not a good use of time?

Thank you!

Rollup merge of #75821 - camelid:intra-doc-links-for-std-macros, r=jyn514

Switch to intra-doc links in `std::macros`

Part of #75080.

---

* Switch to intra-doc links in `std::macros`
* Fix typo in module docs
* Link to `std::io::stderr` instead of `std::io::Stderr` to match the
  link text
* Link to `std::io::stdout`

---

@rustbot modify labels: A-intra-doc-links T-doc T-rustdoc

Rollup merge of #75819 - LeSeulArtichaut:core-intra-docs-2, r=jyn514

Use intra-doc-links in `core::{char, macros, fmt}`

Helps with #75080.
r? @jyn514

xpy fmt

Document prim@ and primitive@

Update primitive test to match the new behavior

Convert str -> prim@str in `std`

Convert from str -> prim@str for `alloc`

Disambiguate char -> prim@char for `core`

This also changes human intuition -> intuition. 'human intuition' sounds
vaguely menacing.

Report an ambiguity if both modules and primitives are in scope

- Add a new `prim@` disambiguator, since both modules and primitives are
in the same namespace
- Refactor `report_ambiguity` into a closure

Additionally, I noticed that rustdoc would previously allow
`[struct@char]` if `char` resolved to a primitive (not if it had a
DefId). I fixed that and added a test case.

Auto merge of #75817 - LeSeulArtichaut:proc_macro-docs, r=jyn514

Use intra-doc link in `proc_macro`

Yep. One link.

Helps with #75080.
r? @jyn514

add issue number

doc: Fix typo in std::process::Child documentation

Auto merge of #74489 - jyn514:assoc-items, r=manishearth,petrochenkov

Fix intra-doc links for associated items

@Manishearth and I found that links of the following sort are broken:
```rust
$ cat str_from.rs
/// [`String::from`]
pub fn foo() {}
$ rustdoc str_from.rs
warning: `[String::from]` cannot be resolved, ignoring it.
 --> str_from.rs:4:6
  |
4 | /// [`String::from`]
  |      ^^^^^^^^^^^^^^ cannot be resolved, ignoring
```
It turns out this is because the current implementation only looks at inherent impls (`impl Bar {}`) and traits _for the item being documented_. Note that this is not the same as the item being _linked_ to. So this code would work:

```rust
pub trait T1 {
    fn method();
}

pub struct S;
impl T1 for S {
    /// [S::method] on method
    fn method() {}
}
```

but putting the documentation on `trait T1` would not.

~~I realized that writing it up that my fix is only partially correct: It removes the inherent impls code when it should instead remove the `trait_item` code.~~ Fixed.

Additionally, I discovered while writing this there is some ambiguity: you could have multiple methods with the same name, but for different traits:

```rust
pub trait T1 {
    fn method();
}

pub trait T2 {
    fn method();
}

/// See [S::method]
pub struct S;
```

Rustdoc should give an ambiguity error here, but since there is currently no way to disambiguate the traits (https://github.com/rust-lang/rust/issues/74563) it does not (https://github.com/rust-lang/rust/pull/74489#issuecomment-673878404).

There is a _third_ ambiguity that pops up: What if the trait is generic and is implemented multiple times with different generic parameters? In this case, my fix does not do very well: it thinks there is only one trait instantiated and links to that trait:

```
/// [`String::from`] -- this resolves to https://doc.rust-lang.org/nightly/alloc/string/struct.String.html#method.from
pub fn foo() {}
```

However, every `From` implementation has a method called `from`! So the browser picks a random one. This is not the desired behavior, but it's not clear how to avoid it.

To be consistent with the rest of intra-doc links, this only resolves associated items from traits that are in scope. This required changes to rustc_resolve to work cross-crate; the relevant commits are prefixed with `resolve: `. As a bonus, considering only traits in scope is slightly faster. To avoid re-calculating the traits over and over, rustdoc uses a cache to store the traits in scope for a given module.

unstable-book-gen: fix clippy::single_char_pattern and clippy::iter_skip_next

Use allow(unused_imports) instead of cfg(doc)

This prevents links from breaking when items are re-exported in a
different crate and the original isn't being documented.

unicode_table_generator: fix clippy::writeln_empty_string, clippy::useless_format, clippy:::for_kv_map

tidy: remove redundant variable from check_if_error_code_is_test_in_explanation

Use intra-doc-links in `core::{char, macros, fmt}`

linkcheckr: fix clippy::redundant_static_lifetimes and clippy::single_char_pattern

expand-yaml-anchors: fix clippy::match_ref_pats and clippy::redundant_closure

resolve: Add comments to `traits_in_scope`

Switch to intra-doc links in `core::array`

Auto merge of #75656 - tirr-c:match-suggest-semi, r=estebank

Provide better spans for the match arm without tail expression

Resolves #75418.

Applied the same logic in the `if`-`else` type mismatch case.

r? @estebank

Switch to intra-doc links in `std::collections`

Auto merge of #72449 - ecstatic-morse:const-float-bitcast, r=RalfJung

Const floating point bitcasts and classification

Makes the `f32` and `f64` methods described in #72447 and #72505 unstably const.

r? @RalfJung

publish-toolstate: show more context on HTTP error

Fix `compile-flags` directive

Co-authored-by: Ralf Jung <post@ralfj.de>

HermitCore switchs to relocatable binaries

- switch to relocatbale binaries to realize ASLR
- remove all dependencies to gcc

Auto merge of #75028 - MrModder:master, r=steveklabnik

Document that slice refers to any pointer type to a sequence

I was recently confused about the way slices are represented in memory. The necessary information was not available in the std-docs directly, but was a mix of different material from the reference and book.

This PR should clear up the definition of slices a bit more in the documentation. Especially the fact that the term slice refers to the pointer/reference type, e.g. `&[T]`, and not `[T]`.
It also documents that slice pointers are twice the size of pointers to `Sized` types, as this concept may be unfamiliar to users coming from other languages that do not have the concept of "fat pointers" (especially C/C++).

I've documented why this was important to me and my findings in [this blog post](https://codecrash.me/understanding-rust-slices).

r? @lcnr

Auto merge of #74238 - RalfJung:offset_from, r=oli-obk

stabilize ptr_offset_from

This stabilizes ptr::offset_from, and closes https://github.com/rust-lang/rust/issues/41079. It also removes the deprecated `wrapping_offset_from`. This function was deprecated 19 days ago and was never stable; given an FCP of 10 days and some waiting time until FCP starts, that leaves at least a month between deprecation and removal which I think is fine for a nightly-only API.

Regarding the open questions in https://github.com/rust-lang/rust/issues/41079:
* Should offset_from abort instead of panic on ZSTs? -- As far as I know, there is no precedent for such aborts. We could, however, declare this UB. Given that the size is always known statically and the check thus rather cheap, UB seems excessive.
* Should there be more methods like this with different restrictions (to allow nuw/nsw, perhaps) or that return usize (like how isize-taking offset is more conveniently done with usize-taking add these days)? -- No reason to block stabilization on that, we can always add such methods later.

Also nominating the lang team because this exposes an intrinsic.

The stabilized method is best described [by its doc-comment](https://github.com/RalfJung/rust/blob/56d4b2d69abb93e4f0ca79471deca7aaaaeca214/src/libcore/ptr/const_ptr.rs#L227). The documentation forgot to mention the requirement that both pointers must "have the same provenance", aka "be derived from pointers to the same allocation", which I am adding in this PR. This is a precondition that [Miri already implements](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=a3b9d0a07a01321f5202cd99e9613480) and that, should LLVM ever obtain a `psub` operation to subtract pointers, will likely be required for that operation (following the semantics in [this paper](https://people.mpi-sws.org/~jung/twinsem/twinsem.pdf)).

bump stable version

Co-authored-by: Josh Stone <cuviper@gmail.com>

remove an unused feature flag

Revert changed paragraph about slice definition.

This reverts part of commit e6c83dd57b920d2069797736ae0a1c9fe14a97cb.
As requested by @steveklabnik .

Profiler: reenable atomics after #65214

    change offset from u32 to u64

Auto merge of #75816 - LeSeulArtichaut:core-intra-docs, r=jyn514

Use intra-doc-links in `core::{raw, ffi, pin}`

Helps with #75080.
r? @jyn514

Misleading documentation for derived Ord/PartialOrd implementation for enums #75620