libsyntax: Stop parsing `+` with no bounds after it.

This will break code that looks like `Box<Trait+>`. Change that code to
`Box<Trait>` instead.

Closes #14925.

[breaking-change]
replace reference to ~"string" with box "string"
auto merge of #15062 : pcwalton/rust/trailing-plus, r=brson

This will break code that looks like `Box<Trait+>`. Change that code to
`Box<Trait>` instead.

Closes #14925.

[breaking-change]

r? @brson
auto merge of #15074 : conradkleinespel/rust/master, r=pcwalton

Using something like:

```rust
box "string"
```

yields
```shell
"`~\"string\"` has been removed; use `\"string\".to_string()` instead"
```

Should the error message maybe say `box "string"` instead?
Correctly set return type attributes on foreign function declarations

The ArgType type gives us a generic way to specify an attribute for a
type to ensure ABI conformance for foreign functions. But the code that
actually sets the argument attributes in the function declaration
only sets the attribute for the return type when the type is indirect.

Since LLVMAddAttribute() doesn't allow to set attributes on the return
type, we have to use LLVMAddFunctionAttribute() instead.

This didn't cause problems yet, because currently only some indirect
types require attributes to be set.
Add missing attributes to indirect calls for foreign functions

When calling a foreign function, some arguments and/or return value
attributes are required to conform to the foreign ABI. Currently those
attributes are only added to the declaration of foreign functions. With
direct calls, this is no problem, because LLVM can see that those
attributes apply to the call. But with an indirect call, LLVM cannot do
that and the attribute is missing.

To fix that, we have to add those attribute to the calls to foreign
functions as well.

This also allows to remove the special handling of the SRet attribute,
which is ABI-dependent and will be set via the `attr` field of the
return type's `ArgType`.
Update LLVM

To fix #8106, we need an LLVM version that contains r211082 aka 0dee6756
which fixes a bug that blocks that issue.

There have been some tiny API changes in LLVM, and cmpxchg changed its
return type. The i1 part of the new return type is only interesting when
using the new weak cmpxchg, which we don't do.
Compile bools to i1

We currently compiled bools to i8 values, because there was a bug in
LLVM that sometimes caused miscompilations when using i1 in, for
example, structs.

Using i8 means a lot of unnecessary zero-extend and truncate operations
though, since we have to convert the value from and to i1 when using for
example icmp or br instructions. Besides the unnecessary overhead caused
by this, it also sometimes made LLVM miss some optimizations.

Fixes #8106.
Fix a #14731 regression in missing_constructor() for vector patterns

Fixes #15080.
std: micro-optimize Vec constructors and add benchmarks

Generally speaking, inlining doesn't really help out with
constructing vectors, except for when we construct a zero-sized
vector. This patch allows llvm to optimize this case away in
a lot of cases, which shaves off 4-8ns. It's not much, but it
might help in some inner loop somewhere.

before:

running 12 tests
test bench_extend_0          ... bench:       123 ns/iter (+/- 6)
test bench_extend_5          ... bench:       323 ns/iter (+/- 11)
test bench_from_fn_0         ... bench:         7 ns/iter (+/- 0)
test bench_from_fn_5         ... bench:        49 ns/iter (+/- 6)
test bench_from_iter_0       ... bench:        11 ns/iter (+/- 0)
test bench_from_iter_5       ... bench:       176 ns/iter (+/- 11)
test bench_from_slice_0      ... bench:         8 ns/iter (+/- 1)
test bench_from_slice_5      ... bench:        73 ns/iter (+/- 5)
test bench_new               ... bench:         0 ns/iter (+/- 0)
test bench_with_capacity_0   ... bench:         6 ns/iter (+/- 1)
test bench_with_capacity_100 ... bench:        41 ns/iter (+/- 3)
test bench_with_capacity_5   ... bench:        40 ns/iter (+/- 2)

after:

test bench_extend_0          ... bench:       123 ns/iter (+/- 7)
test bench_extend_5          ... bench:       339 ns/iter (+/- 27)
test bench_from_fn_0         ... bench:         7 ns/iter (+/- 0)
test bench_from_fn_5         ... bench:        54 ns/iter (+/- 4)
test bench_from_iter_0       ... bench:        11 ns/iter (+/- 1)
test bench_from_iter_5       ... bench:       182 ns/iter (+/- 16)
test bench_from_slice_0      ... bench:         4 ns/iter (+/- 0)
test bench_from_slice_5      ... bench:        62 ns/iter (+/- 3)
test bench_new               ... bench:         0 ns/iter (+/- 0)
test bench_with_capacity_0   ... bench:         0 ns/iter (+/- 0)
test bench_with_capacity_100 ... bench:        41 ns/iter (+/- 1)
test bench_with_capacity_5   ... bench:        41 ns/iter (+/- 3)
serialize: Simplify the json docs
std: inline many of the Writer/Reader methods

This allows llvm to optimize away much of the overhead from using
the MemReader/MemWriters. My benchmarks showed it to shave 15% off
of my in progress serialization/json encoding.
collections: fix running `make check-stage1-collections`
auto merge of #15005 : dotdash/rust/i1_bool, r=alexcrichton

We currently compiled bools to i8 values, because there was a bug in
LLVM that sometimes caused miscompilations when using i1 in, for
example, structs.

Using i8 means a lot of unnecessary zero-extend and truncate operations
though, since we have to convert the value from and to i1 when using for
example icmp or br instructions. Besides the unnecessary overhead caused
by this, it also sometimes made LLVM miss some optimizations.

First, we have to fix some bugs concerning the handling of
attributes in foreign function declarations and calls. These
are required because the i1 type needs the ZExt attribute when
used as a function parameter or return type.

Then we have to update LLVM to get a bugfix without which LLVM
sometimes generates broken code when using i1.

And then, finally, we can switch bools over to i1.
Update few files after comparison traits renaming

There were still Total{Ord,Eq} in docs and src/etc
Rename and move ty_param_substs_and_ty
Rename ty_param_bounds_and_ty to Polytype
auto merge of #15088 : Sawyer47/rust/detotal, r=alexcrichton

There were still Total{Ord,Eq} in docs and src/etc
auto merge of #15091 : nikomatsakis/rust/issue-5527-rename-types, r=pcwalton

Some cleanups I'm sick of rebasing.

r? @pcwalton (do you agree with new names?)
auto merge of #15081 : jakub-/rust/issue-15080, r=alexcrichton

Fixes #15080.