Rollup merge of #38029 - dns2utf8:fix_verify.rs, r=petrochenkov

Fix verify.rs

Finishing d2f8fb0 from @jseyfried

Rollup merge of #38028 - Mark-Simulacrum:polish, r=nikomatsakis

Refactor one_bound_for_assoc_type to take an Iterator instead of Vec

I doubt the performance implications will be serious, but it will avoid allocating one-element Vecs for the successful case (and avoid allocating vecs at all for any case, too).

`--stage 2` tests passed locally.

Rollup merge of #38020 - GuillaumeGomez:udp-socket-doc, r=frewsxcv

Add part of missing UdpSocket's urls and examples

r? @frewsxcv

Rollup merge of #37919 - nikomatsakis:incremental-36168, r=mw

add regression test for #36168

Fixes #36168

r? @michaelwoerister

Rollup merge of #37859 - GuillaumeGomez:net_examples, r=nagisa

Add missing examples for Ipv6Addr

r? @steveklabnik

cc @frewsxcv

Auto merge of #38061 - cardoe:target-spec, r=alexcrichton

print option to dump target spec as JSON

This lets the user dump out the target spec that the compiler is using. This is useful to people defining their own target.json to compare it against existing targets or understand how different targets change internal settings. It is also potentially useful for Cargo to determine if something has changed with a target and it needs to rebuild things.

Auto merge of #38059 - arielb1:no-mere-overflow, r=nikomatsakis

evaluate obligations in LIFO order during closure projection

This is an annoying gotcha with the projection cache's handling of
nested obligations.

Nested projection obligations enter the issue in this case:
```
DEBUG:rustc::traits::project: AssociatedTypeNormalizer: depth=3
normalized
<std::iter::Map<std::ops::Range<i32>,
[closure@not-a-recursion-error.rs:5:30: 5:53]> as
std::iter::IntoIterator>::Item to _#7t with 12 add'l obligations
```

Here the normalization result is the result of the nested impl
`<[closure@not-a-recursion-error.rs:5:30: 5:53] as FnMut(i32)>::Output`,
which is an additional obligation that is a part of "add'l obligations".

By itself, this is proper behaviour - the additional obligation is
returned, and the RFC 447 rules ensure that it is processed before the
output `#_7t` is used in any way.

However, the projection cache breaks this - it caches the
`<std::iter::Map<std::ops::Range<i32>,[closure@not-a-recursion-error.rs:5:30:
5:53]> as std::iter::IntoIterator>::Item = #_7t` resolution. Now
everybody else that attempts to look up the projection will just get
`#_7t` *without* any additional obligations. This obviously causes all
sorts of trouble (here a spurious `EvaluatedToAmbig` results in
specializations not being discarded
[here](https://github.com/rust-lang/rust/blob/9ca50bd4d50b55456e88a8c3ad8fcc9798f57522/src/librustc/traits/select.rs#L1705)).

The compiler works even with this projection cache gotcha because in most
cases during "one-pass evaluation". we tend to process obligations in LIFO
order - after an obligation is added to the cache, we process its nested
obligations before we do anything else (and if we have a cycle, we handle
it specifically) - which makes sure the inference variables are resolved
before they are used.

That "LIFO" order That was not done when projecting out of a closure, so
let's just fix that for the time being.

Fixes #38033.

Beta-nominating because regression.

r? @nikomatsakis

Auto merge of #38056 - clarcharr:master, r=alexcrichton

Add String::split_off.

This seems to match up with the latest version of the collection reform, and seems useful enough to add. First pull request!

Auto merge of #38055 - rkruppe:rm-unused-llvm-ffi, r=alexcrichton

Remove unused functions from rustc_llvm

rustc: add basic test for --print target-spec

This is a very basic test of the --print target-spec feature.

Signed-off-by: Doug Goldstein <cardoe@cardoe.com>

rustc: add --print target-spec option

This option provides the user the ability to dump the configuration that
is in use by rustc for the target they are building for.

Signed-off-by: Doug Goldstein <cardoe@cardoe.com>

Auto merge of #38053 - eddyb:lazy-9, r=nikomatsakis

[9/n] rustc: move type information out of AdtDef and TraitDef.

_This is part of a series ([prev](https://github.com/rust-lang/rust/pull/37688) | [next]()) of patches designed to rework rustc into an out-of-order on-demand pipeline model for both better feature support (e.g. [MIR-based](https://github.com/solson/miri) early constant evaluation) and incremental execution of compiler passes (e.g. type-checking), with beneficial consequences to IDE support as well.
If any motivation is unclear, please ask for additional PR description clarifications or code comments._

<hr>

Both `AdtDef` and `TraitDef` contained type information (field types, generics and predicates) which was required to create them, preventing their use before that type information exists, or in the case of field types, *mutation* was required, leading to a variance-magicking implementation of `ivar`s.

This PR takes that information out and the resulting cleaner setup could even eventually end up merged with HIR, because, just like `AssociatedItem` before it, there's no dependency on types anymore.
(With one exception, variant discriminants should probably be moved into their own map later.)

Auto merge of #38050 - alexcrichton:fix-llvm-deps, r=japaric

rustbuild: Cross-compiled LLVM depens on host

We use the host's tblgen so we need to be sure to always build the host first.

Closes #38037

Auto merge of #37936 - tedsta:fuchsia_std_process, r=alexcrichton

Fuchsia support for std::process via liblaunchpad.

Now we can launch processes on Fuchsia via the Rust standard library! ... Mostly.

Right now, ~5% of the time, reading the stdout/stderr off the pipes will fail. Some Magenta kernel people think it's probably a bug in Magenta's pipes. I wrote a unit test that demonstrates the issue in C, which I was told will expedite a fix. https://fuchsia-review.googlesource.com/#/c/15628/

Hopefully this can get merged once the issue is fixed :)

@raphlinus

Auto merge of #37789 - arielb1:length-limit, r=nikomatsakis

limit the length of types in monomorphization

This adds the new insta-stable `#![type_size_limit]` crate attribute to control
the limit, and is obviously a [breaking-change] fixable by that.

Fixes #37311.

r? @nikomatsakis

convert --print options to a vector

To allow manipulation of the options that appear in --print, convert it
to a vector.

Signed-off-by: Doug Goldstein <cardoe@cardoe.com>

limit the length of types in monomorphization

This adds the new insta-stable `#![type_size_limit]` crate attribute to control
the limit, and is obviously a [breaking-change] fixable by that.

std::process fuchsia support cleanup

Auto merge of #38048 - rkruppe:llvm-stringref-fixes, r=alexcrichton

[LLVM 4.0] Don't assume llvm::StringRef is null terminated

StringRefs have a length and their contents are not usually null-terminated. The solution is to either copy the string data (in `rustc_llvm::diagnostic`) or take the size into account (in LLVMRustPrintPasses).

I couldn't trigger a bug caused by this (apparently all the strings returned in practice are actually null-terminated) but this is more correct and more future-proof.

cc #37609

Auto merge of #38018 - sourcefrog:doc, r=alexcrichton

Document that Process::command will search the PATH

Auto merge of #37911 - liigo:rustdoc-playground, r=alexcrichton

rustdoc: get back missing crate-name when --playground-url is used

follow up PR #37763
r? @alexcrichton (since you r+ed to #37763 )

----

Edit: When `#![doc(html_playground_url="")]` is used, the current crate name is saved to `PLAYGROUND`, so rustdoc may generate `extern crate NAME;` into code snips automatically. But when `--playground-url` was introduced in PR #37763, I forgot saving crate name to `PLAYGROUND`. This PR fix that.

----

Update:
- add test
- unstable `--playground-url`

Add String::split_off.

Auto merge of #37573 - ruuda:faster-cursor, r=alexcrichton

Add small-copy optimization for copy_from_slice

## Summary

During benchmarking, I found that one of my programs spent between 5 and 10 percent of the time doing memmoves. Ultimately I tracked these down to single-byte slices being copied with a memcopy. Doing a manual copy if the slice contains only one element can speed things up significantly. For my program, this reduced the running time by 20%.

## Background

I am optimizing a program that relies heavily on reading a single byte at a time. To avoid IO overhead, I read all data into a vector once, and then I use a `Cursor` around that vector to read from. During profiling, I noticed that `__memmove_avx_unaligned_erms` was hot, taking up 7.3% of the running time. It turns out that these were caused by calls to `Cursor::read()`, which calls `<&[u8] as Read>::read()`, which calls `&[T]::copy_from_slice()`, which calls `ptr::copy_nonoverlapping()`. This one is implemented as a memcopy. Copying a single byte with a memcopy is very wasteful, because (at least on my platform) it involves calling `memcpy` in libc. This is an indirect call when libc is linked dynamically, and furthermore `memcpy` is optimized for copying large amounts of data at the cost of a bit of overhead for small copies.

## Benchmarks

Before I made this change, `perf` reported the following for my program. I only included the relevant functions, and how they rank. (This is on a different machine than where I ran the original benchmarks. It has an older CPU, so `__memmove_sse2_unaligned_erms` is called instead of `__memmove_avx_unaligned_erms`.)

```
#3   5.47%  bench_decode  libc-2.24.so      [.] __memmove_sse2_unaligned_erms
#5   1.67%  bench_decode  libc-2.24.so      [.] memcpy@GLIBC_2.2.5
#6   1.51%  bench_decode  bench_decode      [.] memcpy@plt
```

`memcpy` is eating up 8.65% of the total running time, and the overhead of dispatching to a specialized fast copy function (`memcpy@GLIBC` showing up) is clearly visible. The price of dynamic linking (`memcpy@plt` showing up) is visible too.

After this change, this is what `perf` reports:

```
#5   0.33%  bench_decode  libc-2.24.so      [.] __memmove_sse2_unaligned_erms
#14  0.01%  bench_decode  libc-2.24.so      [.] memcpy@GLIBC_2.2.5
```

Now only 0.34% of the running time is spent on memcopies. The dynamic linking overhead is not significant at all any more.

To add some more data, my program generates timing results for the operation in its main loop. These are the timings before and after the change:

| Time before   | Time after    | After/Before |
|---------------|---------------|--------------|
| 29.8 ± 0.8 ns | 23.6 ± 0.5 ns |  0.79 ± 0.03 |

The time is basically the total running time divided by a constant; the actual numbers are not important. This change reduced the total running time by 21% (much more than the original 9% spent on memmoves, likely because the CPU is stalling a lot less because data dependencies are more transparent). Of course YMMV and for most programs this will not matter at all. But when it does, the gains can be significant!

## Alternatives

* At first I implemented this in `io::Cursor`. I moved it to `&[T]::copy_from_slice()` instead, but this might be too intrusive, especially because it applies to all `T`, not just `u8`. To restrict this to `io::Read`, `<&[u8] as Read>::read()` is probably the best place.
* I tried copying bytes in a loop up to 64 or 8 bytes before calling `Read::read`, but both resulted in about a 20% slowdown instead of speedup.

Document that Process::command will search the PATH

Auto merge of #38047 - canndrew:fmt-void-non-empty, r=bluss

Make core::fmt::Void a non-empty type.

Adding back this change that was removed from PR #36449 because it's a fix and because I immediately hit a problem with it again when I started implementing my fix for #12609.

Removed Option<ExitStatus> member from fuchsia Process struct. Destroy launchpads and close handles in Drop impls rather than manually

Auto merge of #37800 - alexcrichton:new-bootstrap, r=eddyb

Update the bootstrap compiler

Now that we've got a beta build, let's use it!

Update the bootstrap compiler

Now that we've got a beta build, let's use it!

Auto merge of #38014 - jseyfried:refactor_path_resolution, r=nrc

resolve: refactor path resolution

This is a pure refactoring, modulo minor diagnostics improvements.
r? @nrc

Refactor one_bound_for_assoc_type to take an Iterator instead of Vec.

Auto merge of #37989 - nrc:save-mod, r=nikomatsakis

save-analysis: redirect a module decl to the start of the defining file

Move small-copy optimization into <&[u8] as Read>

Based on the discussion in https://github.com/rust-lang/rust/pull/37573,
it is likely better to keep this limited to std::io, instead of
modifying a function which users expect to be a memcpy.

Move small-copy optimization into copy_from_slice

Ultimately copy_from_slice is being a bottleneck, not io::Cursor::read.
It might be worthwhile to move the check here, so more places can
benefit from it.

Add small-copy optimization for io::Cursor

During benchmarking, I found that one of my programs spent between 5 and
10 percent of the time doing memmoves. Ultimately I tracked these down
to single-byte slices being copied with a memcopy in io::Cursor::read().
Doing a manual copy if only one byte is requested can speed things up
significantly. For my program, this reduced the running time by 20%.

Why special-case only a single byte, and not a "small" slice in general?
I tried doing this for slices of at most 64 bytes and of at most 8
bytes. In both cases my test program was significantly slower.

Auto merge of #37954 - eddyb:rustdoc-2, r=alexcrichton

rustdoc: link to cross-crate sources directly.

Fixes #37684 by implementing proper support for getting the `Span` of definitions across crates.
In rustdoc this is used to generate direct links to the original source instead of fragile redirects.

This functionality could be expanded further for making error reporting code more uniform and seamless across crates, although at the moment there is no actual source to print, only file/line/column information.

Closes #37870 which is also "fixes" #37684 by throwing away the builtin macro docs from libcore.
After this lands, #37727 could be reverted, although it doesn't matter much either way.

rustdoc: link to cross-crate sources directly.

rustc: track the Span's of definitions across crates.

Auto merge of #37965 - Mark-Simulacrum:trait-obj-to-exis-predicate, r=eddyb

Refactor TraitObject to Slice<ExistentialPredicate>

For reference, the primary types changes in this PR are shown below. They may add in the understanding of what is discussed below, though they should not be required.

We change `TraitObject` into a list of `ExistentialPredicate`s to allow for a couple of things:
 - Principal (ExistentialPredicate::Trait) is now optional.
 - Region bounds are moved out of `TraitObject` into `TyDynamic`. This permits wrapping only the `ExistentialPredicate` list in `Binder`.
 - `BuiltinBounds` and `BuiltinBound` are removed entirely from the codebase, to permit future non-constrained auto traits. These are replaced with `ExistentialPredicate::AutoTrait`, which only requires a `DefId`. For the time being, only `Send` and `Sync` are supported; this constraint can be lifted in a future pull request.
 - Binder-related logic is extracted from `ExistentialPredicate` into the parent (`Binder<Slice<EP>>`), so `PolyX`s are inside `TraitObject` are replaced with `X`.

The code requires a sorting order for `ExistentialPredicate`s in the interned `Slice`. The sort order is asserted to be correct during interning, but the slices are not sorted at that point.

1. `ExistentialPredicate::Trait` are defined as always equal; **This may be wrong; should we be comparing them and sorting them in some way?**
1. `ExistentialPredicate::Projection`: Compared by `ExistentialProjection::sort_key`.
1. `ExistentialPredicate::AutoTrait`: Compared by `TraitDef.def_path_hash`.

Construction of `ExistentialPredicate`s is conducted through `TyCtxt::mk_existential_predicates`, which interns a passed iterator as a `Slice`. There are no convenience functions to construct from a set of separate iterators; callers must pass an iterator chain. The lack of convenience functions is primarily due to few uses and the relative difficulty in defining a nice API due to optional parts and difficulty in recognizing which argument goes where. It is also true that the current situation isn't significantly better than 4 arguments to a constructor function; but the extra work is deemed unnecessary as of this time.

```rust
// before this PR
struct TraitObject<'tcx> {
    pub principal: PolyExistentialTraitRef<'tcx>,
    pub region_bound: &'tcx ty::Region,
    pub builtin_bounds: BuiltinBounds,
    pub projection_bounds: Vec<PolyExistentialProjection<'tcx>>,
}

// after
pub enum ExistentialPredicate<'tcx> {
    // e.g. Iterator
    Trait(ExistentialTraitRef<'tcx>),
    // e.g. Iterator::Item = T
    Projection(ExistentialProjection<'tcx>),
    // e.g. Send
    AutoTrait(DefId),
}
```

rustdoc: fix up --playground-url

unstable --playground-url, add test code

rustdoc: get back missing crate-name when --playground-url is used

follow up PR #37763

Auto merge of #37863 - mikhail-m1:mut_error, r=nikomatsakis

add hint to fix error for immutable ref in arg

fix  #36412 part of #35233
r? @jonathandturner

rustc: simplify AdtDef by removing the field types and ty::ivar.

rustc: remove type information from TraitDef.

Auto merge of #37369 - estebank:multiline-span, r=nikomatsakis

Show multiline spans in full if short enough

When dealing with multiline spans that span few lines, show the complete span instead of restricting to the first character of the first line.

For example, instead of:

```
% ./rustc file2.rs
error[E0277]: the trait bound `{integer}: std::ops::Add<()>` is not satisfied
  --> file2.rs:13:9
   |
13 |    foo(1 + bar(x,
   |        ^ trait `{integer}: std::ops::Add<()>` not satisfied
   |
```

show

```
% ./rustc file2.rs
error[E0277]: the trait bound `{integer}: std::ops::Add<()>` is not satisfied
  --> file2.rs:13:9
   |
13 |      foo(1 + bar(x,
   |  ________^ starting here...
14 | |            y),
   | |_____________^ ...ending here: trait `{integer}: std::ops::Add<()>` not satisfied
   |
```

The [proposal in internals](https://internals.rust-lang.org/t/proposal-for-multiline-span-comments/4242/6) outlines the reasoning behind this.

Auto merge of #37918 - flodiebold:separate-bodies, r=nikomatsakis

Separate function bodies from their signatures in HIR

Also give them their own dep map node.

I'm still unhappy with the handling of inlined items (1452edc1), but maybe you have a suggestion how to improve it.

Fixes #35078.

r? @nikomatsakis

librustdoc: Fix compilation after visitor change

update comments

revamp `Visitor` with a single method for controlling nested visits

Fix rebase breakage

Fix doc test collection

Fix SVH tests some more

Split nested_visit_mode function off from nested_visit_map

... and make the latter mandatory to implement.

Address remaining review comments

Fix remaining SVH tests

Refactor inlined items some more

They don't implement FnLikeNode anymore, instead are handled differently
further up in the call tree. Also, keep less information (just def ids
for the args).

WIP: update tests to pass -- not complete

restructure `CollectItem` dep-node to separate fn sigs from bodies

Setup two tasks, one of which only processes the signatures, in order to
isolate the typeck entries for signatures from those for bodies.

Fixes #36078
Fixes #37720

Add make tidy fixes

Remove unused import

Fix some comments

Make hello_world test work again

This used to work with the rustc_clean attribute, but doesn't anymore
since my rebase; but I don't know enough about the type checking to find
out what's wrong. The dep graph looks like this:

ItemSignature(xxxx) -> CollectItem(xxxx)
CollectItem(xxxx) -> ItemSignature(xxxx)
ItemSignature(xxxx) -> TypeckItemBody(yyyy)
HirBody(xxxx) -> CollectItem(xxxx)

The cycle between CollectItem and ItemSignature looks wrong, and my
guess is the CollectItem -> ItemSignature edge shouldn't be there, but
I'm not sure how to prevent it.

Fix new tests

rustc_typeck: Make CollectItemTypesVisitor descend into bodies as well

Fix cross-crate associated constant evaluation

Give function bodies their own dep graph node

Save bodies of functions for inlining into other crates

This is quite hacky and I hope to refactor it a bit, but at least it
seems to work.

rustc_driver: fix compilation

rustc_passes: fix compilation

rustc_plugin: fix compilation

rustc_plugin: fix compilation

rustc_metadata: fix compilation

rustc_privacy: fix compilation

rustc_trans: fix compilation

rustc_trans: fix compilation

rustc_incremental: fix compilation

rustc_incremental: fix compilation

rustc_typeck: fix compilation

rustc_borrowck: fix compilation

rustc_mir: fix compilation

rustc_const_eval: fix compilation

rustc: replace body exprs by their ids

Add exprs map to crate, collect item blocks there

Remove `resolver.record_resolution()`.

Auto merge of #38046 - rkruppe:fix-32bit-rustbuild, r=alexcrichton

Fix rustbuild on 32 bit Linux

This is cherry-picked from #37817 which seems to be stalled and currently needs to be rebased anyway.

r? @alexcrichton (who authored this change)

Remove allocation in push_type_params

Adds TyCtxt::require_lang_item(LangItem) to simplify lang item requires.

Replaces instances of tcx.lang_items.require(..) with fatal unwrap with
this method.

Remove auto_traits from PartitionedBounds

Refactor TyTrait to contain a interned ExistentialPredicate slice.

Renames TyTrait to TyDynamic.

Simplify `binding.module()`.

Clean up formatting.

Refactor away `ResolveResult`.

Refactor path resoloution.

Use `Def::Err` to signal that an error has already been reported where possible.

evaluate obligations in LIFO order during closure projection

This is an annoying gotcha with the projection cache's handling of
nested obligations.

Nested projection obligations enter the issue in this case:
```
DEBUG:rustc::traits::project: AssociatedTypeNormalizer: depth=3
normalized
<std::iter::Map<std::ops::Range<i32>,
[closure@not-a-recursion-error.rs:5:30: 5:53]> as
std::iter::IntoIterator>::Item to _#7t with 12 add'l obligations
```

Here the normalization result is the result of the nested impl
`<[closure@not-a-recursion-error.rs:5:30: 5:53] as FnMut(i32)>::Output`,
which is an additional obligation that is a part of "add'l obligations".

By itself, this is proper behaviour - the additional obligation is
returned, and the RFC 447 rules ensure that it is processed before the
output `#_7t` is used in any way.

However, the projection cache breaks this - it caches the
`<std::iter::Map<std::ops::Range<i32>,[closure@not-a-recursion-error.rs:5:30:
5:53]> as std::iter::IntoIterator>::Item = #_7t` resolution. Now
everybody else that attempts to look up the projection will just get
`#_7t` *without* any additional obligations. This obviously causes all
sorts of trouble (here a spurious `EvaluatedToAmbig` results in
specializations not being discarded
[here](https://github.com/rust-lang/rust/blob/9ca50bd4d50b55456e88a8c3ad8fcc9798f57522/src/librustc/traits/select.rs#L1705)).

The compiler works even with this projection cache gotcha because in most
cases during "one-pass evaluation". we tend to process obligations in LIFO
order - after an obligation is added to the cache, we process its nested
obligations before we do anything else (and if we have a cycle, we handle
it specifically) - which makes sure the inference variables are resolved
before they are used.

That "LIFO" order That was not done when projecting out of a closure, so
let's just fix that for the time being.

Fixes #38033.

fixup test cases

add hint to fix error for immutable ref in arg

Auto merge of #37791 - petrochenkov:where, r=nikomatsakis

Support `?Sized` in where clauses

Implemented as described in https://github.com/rust-lang/rust/issues/20503#issuecomment-258677026 - `?Trait` bounds are moved on type parameter definitions when possible, reported as errors otherwise.
(It'd be nice to unify bounds and where clauses in HIR, but this is mostly blocked by rustdoc now - it needs to render bounds in pleasant way and the best way to do it so far is to mirror what was written in source code.)

Fixes https://github.com/rust-lang/rust/issues/20503
r? @nikomatsakis

Remove unused functions from rustc_llvm

Don't assume llvm::StringRef is null terminated

StringRefs have a length and their contents are not usually null-terminated.
The solution is to either copy the string data (in rustc_llvm::diagnostic) or take the size into account (in LLVMRustPrintPasses).
I couldn't trigger a bug caused by this (apparently all the strings returned in practice are actually null-terminated) but this is more correct and more future-proof.