This would partially resolve
fortanix/rust-sgx#31

Currently dependency crates of the standard library can sometimes leak
into error messages such as when traits to import are suggested.
Additionally they can leak into documentation such as in the list of
"all traits implemented by `u32`". The dependencies of the standard
library, however, are intended to be private.

The dependencies of the standard library can't actually be stabl-y
imported nor is the documentation that relevant since you can't import
them on stable either. This commit updates both the compiler and rustdoc
to ignore unstable traits in these two scenarios.

Specifically the suggestion for traits to import ignore unstable traits,
and similarly the list of traits implemented by a type excludes unstable
traits.

This commit is extracted from rust-lang#73441 where the addition of some new
dependencies to the standard library was showed to leak into various
error messages and documentation. The intention here is to go ahead and
land these changes ahead of that since it will likely take some time to
land.

…rch64

Copyright (c) 2020, Arm Limited.

Fixes rust-lang#61216.

This commit also categorizing access as Field, Index, or Subslice.

Ideas are taken from `mir::ProjectionElem`.

Proposed changes: https://github.com/rust-lang/project-rfc-2229/blob/master/hir-place-target.md

Closes: rust-lang/project-rfc-2229#1,
rust-lang/project-rfc-2229#2

Co-authored-by: Aman Arora <me@aman-arora.com>
Co-authored-by: Chris Pardy <chrispardy36@gmail.com>
Co-authored-by: Dhruv Jauhar <dhruvjhr@gmail.com>

Fixes rust-lang#72684.

This commit also modifies the signature of `Classifier::new` to avoid
copying the source being highlighted.

As rustc is permanently unstable. So marking every items
with unstable is essential useless.

to avoid surprising listed in API guidelines.

Instead, ignore resolution errors that occur in item bodies.

The reason this can't ignore item bodies altogether is because
`const fn` could be used in generic types, for example `[T; f()]`

- Explicitly check for missing docs
- Don't run any lints except those we explicitly specified

- Remove unnecessary `should_loop` variable
- Report errors for trait implementations

These should give resolution errors because they are visible outside the
current scope. Without these errors, rustdoc will give ICEs:

```
thread 'rustc' panicked at 'attempted .def_id() on invalid res: Err', /home/joshua/src/rust/src/libstd/macros.rs:16:9
  15: rustc_hir::def::Res<Id>::def_id
             at /home/joshua/src/rust/src/librustc_hir/def.rs:382
  16: rustdoc::clean::utils::register_res
             at src/librustdoc/clean/utils.rs:627
  17: rustdoc::clean::utils::resolve_type
             at src/librustdoc/clean/utils.rs:587
```

- Add much more extensive tests
  + fn -> impl -> fn
  + fn -> impl -> fn -> macro
  + errors in function parameters
  + errors in trait bounds
  + errors in the type implementing the trait
  + unknown bounds for the type
  + unknown types in function bodies
  + errors generated by macros

- Use explicit state instead of trying to reconstruct it from random info
- Use an enum instead of a boolean
- Add example of ignored error

Instead, report the error.

This emits the errors on-demand, without special-casing `impl Trait`, so
it should catch all ICEs of this kind, including ones that haven't been
found yet.

Since the error is emitted during type-checking there is less info about
the error; see comments in the code for details.

- Add test case for -> impl Trait
- Add test for impl trait with alias
- Move EmitIgnoredResolutionErrors to rustdoc

This makes `fn typeck_item_bodies` public, which is not desired behavior.
That change should be removed once
rust-lang#74070 is merged.

- Don't visit nested closures twice

Previously, rustdoc would issue a delay_span_bug ICE on the following code:

```rust
pub fn a() -> impl Fn() -> u32 {
    || content::doesnt::matter()
}
```

This wasn't picked up earlier because having `type Alias = impl Trait;`
in the same module caused _all closures_ to be typechecked, even if they
wouldn't normally. Additionally, if _any_ error was emitted, no
delay_span_bug would be emitted. So as part of this commit all of the
tests were separated out into different files.

Just use a boolean instead.

Previously two different parts of the context had to be passed
separately; there were two sources of truth.

TyCtxt is a reference type and so can be passed by value.

`evaluate_obligation` can only be run on types that are already valid.
So rustdoc still has to run typeck even though it doesn't care about the
result.

- Move static variables into the innermost scope in which they are used
- Clean up comments
- Remove external_providers; rename local_providers -> providers

This matches the previous behavior of everybody_loops and is also more
consistent than special-casing impls.

This avoids duplicating the same struct twice.

…unds

…hrogb

Enable some timeouts in SGX platform

This would partially resolve fortanix/rust-sgx#31

cc @jethrogb and @Goirad

Don't run `everybody_loops` for rustdoc; instead ignore resolution errors

r? @eddyb
cc @petrochenkov, @GuillaumeGomez, @Manishearth, @ecstatic-morse, @marmeladema

~~Blocked on rust-lang#73743 Merged.
~~Blocked on crater run.~~ Crater popped up some ICEs ([now fixed](rust-lang#73566 (comment))). See [crater run](https://crater-reports.s3.amazonaws.com/pr-73566/index.html), [ICEs](rust-lang#73566 (comment)).
~~Blocked on rust-lang#74070 so that we don't make typeck_tables_of public when it shouldn't be.~~ Merged.

Closes rust-lang#71820, closes rust-lang#71104, closes rust-lang#65863.

## What is the motivation for this change?

As seen from a lengthy trail of PRs and issues (rust-lang#73532, rust-lang#73103, rust-lang#71820, rust-lang#71104), `everybody_loops` is causing bugs in rustdoc. The main issue is that it does not preserve the validity of the `DefId` tree, meaning that operations on DefIds may unexpectedly fail when called later. This is blocking intra-doc links (see rust-lang#73101).

This PR starts by removing `everybody_loops`, fixing rust-lang#71104 and rust-lang#71820. However, that brings back the bugs seen originally in rust-lang#43348: Since libstd documents items for all platforms, the function bodies sometimes do not type check. Here are the errors from documenting `libstd` with `everybody_loops` disabled and no other changes:

```rust
error[E0433]: failed to resolve: could not find `handle` in `sys`
  --> src/libstd/sys/windows/ext/process.rs:13:27
   |
13 |         let handle = sys::handle::Handle::new(handle as *mut _);
   |                           ^^^^^^ could not find `handle` in `sys`

error[E0425]: cannot find function `symlink_inner` in module `sys::fs`
   --> src/libstd/sys/windows/ext/fs.rs:544:14
    |
544 |     sys::fs::symlink_inner(src.as_ref(), dst.as_ref(), false)
    |              ^^^^^^^^^^^^^ not found in `sys::fs`

error[E0425]: cannot find function `symlink_inner` in module `sys::fs`
   --> src/libstd/sys/windows/ext/fs.rs:564:14
    |
564 |     sys::fs::symlink_inner(src.as_ref(), dst.as_ref(), true)
    |              ^^^^^^^^^^^^^ not found in `sys::fs`
```

## Why does this need changes to `rustc_resolve`?

Normally, this could be avoided by simply not calling the `typeck_item_bodies` pass. However, the errors above happen before type checking, in name resolution itself. Since name resolution is intermingled with macro expansion, and rustdoc needs expansion to happen before it knows all items to be documented, there needs to be someway to ignore _resolution_ errors in function bodies.

An alternative solution suggested by @petrochenkov was to not run `everybody_loops` on anything containing a nested `DefId`. This would solve some of the immediate issues, but isn't bullet-proof: the following functions still could not be documented if the items in the body failed to resolve:

- Functions containing a nested `DefId` (rust-lang#71104)
- ~~Functions returning `impl Trait` (rust-lang#43878 These ended up not resolving anyway with this PR.
- ~~`const fn`, because `loop {}` in `const fn` is unstable (rust-lang#43636 `const_loop` was just stabilized.

This also isn't exactly what rustdoc wants, which is to avoid looking at function bodies in the first place.

## What changes were made?

The hack implemented in this PR is to add an option to ignore all resolution errors in function bodies. This is enabled only for rustdoc. Since resolution errors are ignored, the MIR generated will be invalid, as can be seen in the following ICE:

```rust
error: internal compiler error: broken MIR in DefId(0:11 ~ doc_cfg[8787]::uses_target_feature[0]) ("return type"): bad type [type error]
  --> /home/joshua/src/rust/src/test/rustdoc/doc-cfg.rs:51:1
   |
51 | / pub unsafe fn uses_target_feature() {
52 | |     content::should::be::irrelevant();
53 | | }
   | |_^
```

Fortunately, rustdoc does not need to access MIR in order to generate documentation. Therefore this also removes the call to `analyze()` in `rustdoc::run_core`. This has the side effect of not generating all lints by default. Most lints are safe to ignore (does rustdoc really need to run liveness analysis?) but `missing_docs` in particular is disabled when it should not be. Re-running `missing_docs` specifically does not help, because it causes the typechecking pass to be run, bringing back the errors from rust-lang#24658:

```
error[E0599]: no method named `into_handle` found for struct `sys::unix::pipe::AnonPipe` in the current scope
  --> src/libstd/sys/windows/ext/process.rs:71:27
   |
71 |         self.into_inner().into_handle().into_raw() as *mut _
   |                           ^^^^^^^^^^^ method not found in `sys::unix::pipe::AnonPipe`
   |
```

Because of rust-lang#73743, we only run typeck on demand. So this only causes an issue for functions returning `impl Trait`, which were already special cased by `ReplaceFunctionWithBody`. However, it now considers `async fn f() -> T` to be considered `impl Future<Output = T>`, where before it was considered to have a concrete `T` type.

## How will this affect future changes to rustdoc?

- Any new changes to rustdoc will not be able to perform type checking without bringing back resolution errors in function bodies.
    + As a corollary, any new lints cannot require or perform type checking. In some cases this may require refactoring other parts of the compiler to perform type-checking only on-demand, see for example rust-lang#73743.
    + As a corollary, rustdoc can never again call `tcx.analysis()` unless this PR is reverted altogether.

## Current status

- ~~I am not yet sure how to bring back `missing_docs` without running typeck. @eddyb suggested allowing lints to opt-out of type-checking, which would probably be another rabbit hole.~~ The opt-out was implemented in rust-lang#73743. However, of the rustc lints, now _only_ missing_docs is run and no other lints: rust-lang#73566 (comment). We need a team decision on whether that's an acceptable tradeoff. Note that all rustdoc lints are still run (`intra_doc_link_resolution_failure`, etc). **UPDATE**: This was deemed acceptable in rust-lang#73566 (comment)
- ~~The implementation of optional errors in `rustc_resolve` is very brute force, it should probably be moved from `LateResolver` to `Resolver` to avoid duplicating the logic in many places.~~ I'm mostly happy with it now.

- This no longer allows errors in `async fn f() -> T`. This caused breakage in 50 crates out of a full crater run, all of which (that I looked at) didn't compile when run with rustc directly. In other words, it used to be that they could not be compiled but could still be documented; now they can't be documented either. This needs a decision from the rustdoc team on whether this is acceptable breakage. **UPDATE**: This was deemed acceptable in rust-lang#73566 (comment)
- ~~This makes `fn typeck_tables_of` in `rustc_typeck` public. This is not desired behavior, but needs the changes from rust-lang#74070 in order to be fixed.~~ Reverted.

…ebank,GuillaumeGomez

Don't pollute docs/suggestions with libstd deps

Currently dependency crates of the standard library can sometimes leak
into error messages such as when traits to import are suggested.
Additionally they can leak into documentation such as in the list of
"all traits implemented by `u32`". The dependencies of the standard
library, however, are intended to be private.

The dependencies of the standard library can't actually be stabl-y
imported nor is the documentation that relevant since you can't import
them on stable either. This commit updates both the compiler and rustdoc
to ignore unstable traits in these two scenarios.

Specifically the suggestion for traits to import ignore unstable traits,
and similarly the list of traits implemented by a type excludes unstable
traits.

This commit is extracted from rust-lang#73441 where the addition of some new
dependencies to the standard library was showed to leak into various
error messages and documentation. The intention here is to go ahead and
land these changes ahead of that since it will likely take some time to
land.

…an-DPC

Small cleanup for E0705 explanation

r? @Dylan-DPC

…e27,GuillaumeGomez

rustdoc: glue tokens before highlighting

Fixes rust-lang#72684.

This commit also modifies the signature of `Classifier::new` to avoid
copying the source being highlighted.

…an-DPC

Clean up E0710 explanation

r? @Dylan-DPC

…nikomatsakis

Ignoring test case: [codegen] repr-transparent-aggregates-1.rs for aarch64

Ignoring test case: [codegen] repr-transparent-aggregates-1.rs for aarch64.

Copyright (c) 2020, Arm Limited.

…atsakis

Remove some `ignore-stage1` annotations.

These tests appear to no longer need the `ignore-stage1` marker.

- `run-make-fulldeps/issue-37839` and `run-make-fulldeps/issue-37893`: I believe these were due to the use of proc-macros, and probably were just missed in rust-lang#49219 which fixed the proc-macro compatibility.

- `compile-fail/asm-src-loc-codegen-units.rs`: This was due to an old issue with landing pads (as mentioned in the linked issue rust-lang#20184). `-Zno-landing-pads` was an option when building the first stage (it was much faster), but somewhere along the way (I think the switch from makefiles to rustbuild), the option was removed.
  - NOTE: This test doesn't actually test what it was originally written for, and is probably mostly pointless now. This test was asserting the message "build without -C codegen-units for more exact errors", but that was removed in rust-lang#42682. It is now in essence identical to `asm-src-loc.rs`.

…nikomatsakis

add regression test for rust-lang#61216

Fixes rust-lang#61216.

…, r=nikomatsakis

Make hir ProjectionKind more precise

This commit also categorizing access as Field, Index, or Subslice.

Ideas are taken from `mir::ProjectionElem`.

Proposed changes: https://github.com/rust-lang/project-rfc-2229/blob/master/hir-place-target.md

Closes: rust-lang/project-rfc-2229#1,
Closes: rust-lang/project-rfc-2229#2

r? @nikomatsakis @matthewjasper

forbid generic params in the type of const params

implements and closes rust-lang#74152

fixes rust-lang#74101, closes rust-lang#71169, fixes rust-lang#73491, closes rust-lang#62878

@eddyb and I talked [on zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/type.20of.20const.20parameters/near/203405696) about this and we probably want to also forbid generic consts in the default
type of a parameter, e.g. `struct Foo<T, U = [u8; std::mem::size_of::<T>()]>`, this is currently still allowed
and I will probably fix that in a followup PR.

r? @varkor @eddyb

…akis

Fix 44056 test with debug on macos.

The test `codegen/issue-44056-macos-tls-align.rs` fails on macos if `debug-assertions` is enabled in `config.toml`.  It has the following error:

```
/Users/eric/Proj/rust/rust/src/test/codegen/issue-44056-macos-tls-align.rs:9:11: error: CHECK: expected string not found in input
// CHECK: @STATIC_VAR_1 = thread_local local_unnamed_addr global <{ [32 x i8] }> zeroinitializer, section "__DATA,__thread_bss", align 4
          ^
/Users/eric/Proj/rust/rust/build/x86_64-apple-darwin/test/codegen/issue-44056-macos-tls-align/issue-44056-macos-tls-align.ll:1:1: note: scanning from here
; ModuleID = 'issue_44056_macos_tls_align.3a1fbbbh-cgu.0'
^
/Users/eric/Proj/rust/rust/build/x86_64-apple-darwin/test/codegen/issue-44056-macos-tls-align/issue-44056-macos-tls-align.ll:9:1: note: possible intended match here
@STATIC_VAR_1 = thread_local global <{ [32 x i8] }> zeroinitializer, section "__DATA,__thread_bss", align 4
^
```

Comparing the output, the actual output is missing the text "`local_unnamed_addr`".

The fix here is to ignore `local_unnamed_addr`, as it doesn't seem relevant to the test.

Don't panic if the lhs of a div by zero is not statically known

Fixes rust-lang#73993 for real this time

r? @wesleywiser

…er-warns, r=Mark-Simulacrum

Do not render unstable items for rustc doc

See the zulip conversion: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/rustc.20doc.3A.20.22internal.20compiler.20API.22.20warns.20are.20everywhere!/near/203850782

Before:
![image](https://user-images.githubusercontent.com/15225902/87501971-9cff8780-c68a-11ea-93b4-ea53ce18a77b.png)
After:
![image](https://user-images.githubusercontent.com/15225902/87501985-a7218600-c68a-11ea-81c0-a6b5b120832c.png)

Nothing changes in unstable items of std:
Before:
![image](https://user-images.githubusercontent.com/15225902/87502004-b7d1fc00-c68a-11ea-9224-a27a1d2a81d6.png)
After:
![image](https://user-images.githubusercontent.com/15225902/87502018-c0c2cd80-c68a-11ea-9773-4c63158025cb.png)

Closes  rust-lang#54682

…eGomez

rustdoc: Rename internal API fns to `into_string`

to avoid surprising listed in API guidelines.

… r=pietroalbini

Add RISC-V GNU/Linux to src/tools/build-manifest as a host platform

Missed during rust-lang#72973

…lacrum

BtreeMap: superficially refactor root access

Remove or comment every unwrap in BTreeMap's main code and more.

r? @Mark-Simulacrum

…roalbini

Bump version to 1.47

This also bumps to a more recent rustfmt version, just to keep us relatively up to date (though almost nothing has changed in rustfmt we use beyond bumps to the parser infra). No formatting changes as a result of this.

r? @pietroalbini