Add regression test

Always consider static methods object-safe

This also fixes #18490 as a side-effect by avoiding a later
out-of-bounds slice.

auto merge of #17595 : danburkert/rust/tuple-index-deserialization, r=alexcrichton

Currently `Decoder` implementations are not provided the tuple arity as
a parameter to `read_tuple`. This forces all encoder/decoder combos to
serialize the arity along with the elements. Tuple-arity is always known
statically at the decode site, because it is part of the type of the
tuple, so it could instead be provided as an argument to `read_tuple`,
as it is to `read_struct`.

The upside to this is that serialized tuples could become smaller in
encoder/decoder implementations which choose not to serialize type
(arity) information. For example, @TyOverby's
[binary-encode](https://github.com/TyOverby/binary-encode) format is
currently forced to serialize the tuple-arity along with every tuple,
despite the information being statically known at the decode site.

A downside to this change is that the tuple-arity of serialized tuples
can no longer be automatically checked during deserialization. However,
for formats which do serialize the tuple-arity, either explicitly (rbml)
or implicitly (json), this check can be added to the `read_tuple` method.

The signature of `Deserialize::read_tuple` and
`Deserialize::read_tuple_struct` are changed, and thus binary
backwards-compatibility is broken. This change does *not* force
serialization formats to change, and thus does not break decoding values
serialized prior to this change.

[breaking-change]

auto merge of #18474 : alexcrichton/rust/no-more-traits, r=aturon

As part of the collections reform RFC, this commit removes all collections
traits in favor of inherent methods on collections themselves. All methods
should continue to be available on all collections.

This is a breaking change with all of the collections traits being removed and
no longer being in the prelude. In order to update old code you should move the
trait implementations to inherent implementations directly on the type itself.

Note that some traits had default methods which will also need to be implemented
to maintain backwards compatibility.

[breaking-change]
cc #18424

collections: Remove all collections traits

As part of the collections reform RFC, this commit removes all collections
traits in favor of inherent methods on collections themselves. All methods
should continue to be available on all collections.

This is a breaking change with all of the collections traits being removed and
no longer being in the prelude. In order to update old code you should move the
trait implementations to inherent implementations directly on the type itself.

Note that some traits had default methods which will also need to be implemented
to maintain backwards compatibility.

[breaking-change]
cc #18424

Tuple deserialization should not fail

libserialize: tuple-arity should be provided to `Decoder::read_tuple`

Currently `Decoder` implementations are not provided the tuple arity as
a parameter to `read_tuple`. This forces all encoder/decoder combos to
serialize the arity along with the elements. Tuple-arity is always known
statically at the decode site, because it is part of the type of the
tuple, so it could instead be provided as an argument to `read_tuple`,
as it is to `read_struct`.

The upside to this is that serialized tuples could become smaller in
encoder/decoder implementations which choose not to serialize type
(arity) information. For example, @TyOverby's
[binary-encode](https://github.com/TyOverby/binary-encode) format is
currently forced to serialize the tuple-arity along with every tuple,
despite the information being statically known at the decode site.

A downside to this change is that the tuple-arity of serialized tuples
can no longer be automatically checked during deserialization. However,
for formats which do serialize the tuple-arity, either explicitly (rbml)
or implicitly (json), this check can be added to the `read_tuple` method.

The signature of `Deserialize::read_tuple` and
`Deserialize::read_tuple_struct` are changed, and thus binary
backwards-compatibility is broken. This change does *not* force
serialization formats to change, and thus does not break decoding values
serialized prior to this change.

[breaking-change]

auto merge of #18457 : japaric/rust/tocstr, r=alexcrichton

Methods that used to take `ToCStr` implementors by value, now take them by reference. In particular, this breaks some uses of `Command`:

``` rust
Command::new("foo");  // Still works
Command::new(path) -> Command::new(&path)
cmd.arg(string) -> cmd.arg(&string) or cmd.arg(string.as_slice())
```

[breaking-change]

---

It may be sensible to remove `impl ToCstr for String` since:
- We're getting `impl Deref<str> for String`, so `string.to_cstr()` would still work
- `Command` methods would still be able to use `cmd.arg(string[..])` instead of `cmd.arg(&string)`.

But, I'm leaving that up to the library stabilization process.

r? @aturon
cc #16918

auto merge of #18422 : michaelwoerister/rust/windows-freeze-fix, r=alexcrichton

On some Windows versions of GDB this is more stable than setting breakpoints via function names. This is also something I wanted to do for some time now because it makes the tests more consistent.

@brson:
These changes are in response to issue #17540. It works on my machine with the toolchain mentioned in the issue. In order to find out if the problem is really worked around, we also need to make the build bots use the newer GDB version again.

auto merge of #18371 : nikomatsakis/rust/issue-18262, r=pcwalton

Teach variance checker about the lifetime bounds that appear in trait object types.

[breaking-change] This patch fixes a hole in the type system which resulted in lifetime parameters that were only used in trait objects not being checked. It's hard to characterize precisely the changes that might be needed to fix target code.

cc #18262 (this fixes the test case by @jakub- but I am not sure if this is the same issue that @alexcrichton was reporting)

r? @pnkfelix

Fixes #18205

auto merge of #18177 : nick29581/rust/ufcs2, r=nikomatsakis

r?

closes #18061

Fix RustDoc bug

Rebasing and review changes

test

Cross crait inherant impls

Remove FnStyle from DefFn and DefStaticMethod

Resolve methods called as functions and...

...defined in another crate.

Fixes #18061

Teach variance checker about the lifetime bounds that appear in trait object types.

debuginfo: Enable some GDB tests on Windows.

debuginfo: Make GDB tests use line breakpoints like done in LLDB tests.

On some Windows versions of GDB this is more stable than setting breakpoints via function names.

auto merge of #18440 : japaric/rust/hash, r=alexcrichton

- The signature of the `*_equiv` methods of `HashMap` and similar structures have changed, and now require one less level of indirection. Change your code from:

``` rust
hashmap.find_equiv(&"Hello");
hashmap.find_equiv(&&[0u8, 1, 2]);
```

to:

``` rust
hashmap.find_equiv("Hello");
hashmap.find_equiv(&[0u8, 1, 2]);
```

- The generic parameter `T` of the `Hasher::hash<T>` method have become `Sized?`. Downstream code must add `Sized?` to that method in their implementations. For example:

``` rust
impl Hasher<FnvState> for FnvHasher {
    fn hash<T: Hash<FnvState>>(&self, t: &T) -> u64 { /* .. */ }
}
```

must be changed to:

``` rust
impl Hasher<FnvState> for FnvHasher {
    fn hash<Sized? T: Hash<FnvState>>(&self, t: &T) -> u64 { /* .. */ }
    //      ^^^^^^
}
```

[breaking-change]

---

After review I'll squash the commits and update the commit message with the above paragraph.

r? @aturon
cc #16918

DSTify ToCStr

auto merge of #18458 : eddyb/rust/free-region-args, r=nikomatsakis

This fixes ICEs caused by late-bound lifetimes ending up in argument
datum types and being used in cleanup - user Drop impl's would then
fail to monomorphize if the type was used to look up the impl of a
method call - which happens in trans now, I presume for multidispatch.

trans: use types from argument patterns instead of the function signature.

This fixes ICEs caused by late-bound lifetimes ending up in argument
datum types and being used in cleanup - user Drop impl's would then
fail to monomorphize if the type was used to look up the impl of a
method call - which happens in trans now, I presume for multidispatch.

DSTify Hash

- The signature of the `*_equiv` methods of `HashMap` and similar structures
have changed, and now require one less level of indirection. Change your code
from:

```
hashmap.find_equiv(&"Hello");
hashmap.find_equiv(&&[0u8, 1, 2]);
```

to:

```
hashmap.find_equiv("Hello");
hashmap.find_equiv(&[0u8, 1, 2]);
```

- The generic parameter `T` of the `Hasher::hash<T>` method have become
`Sized?`. Downstream code must add `Sized?` to that method in their
implementations. For example:

```
impl Hasher<FnvState> for FnvHasher {
    fn hash<T: Hash<FnvState>>(&self, t: &T) -> u64 { /* .. */ }
}
```

must be changed to:

```
impl Hasher<FnvState> for FnvHasher {
    fn hash<Sized? T: Hash<FnvState>>(&self, t: &T) -> u64 { /* .. */ }
    //      ^^^^^^
}
```

[breaking-change]

auto merge of #18264 : jakub-/rust/var-ids-in-error-messages, r=nikomatsakis

This PR aims to improve the readability of diagnostic messages that involve unresolved type variables. Currently, messages like the following:

```rust
mismatched types: expected `core::result::Result<uint,()>`, found `core::option::Option<<generic #1>>`
<anon>:6     let a: Result<uint, ()> = None;
                                       ^~~~
mismatched types: expected `&mut <generic #2>`, found `uint`
<anon>:7     f(42u);
               ^~~
```

tend to appear unapproachable to new users. [0] While specific type var IDs are valuable in
diagnostics that deal with more than one such variable, in practice many messages
only mention one. In those cases, leaving out the specific number makes the messages
slightly less terrifying.

```rust
mismatched types: expected `core::result::Result<uint, ()>`, found `core::option::Option<_>`
<anon>:6     let a: Result<uint, ()> = None;
                                       ^~~~
mismatched types: expected `&mut _`, found `uint`
<anon>:7     f(42u);
               ^~~
```

As you can see, I also tweaked the aesthetics slightly by changing type variables to use the type hole syntax _. For integer variables, the syntax used is:

```rust
mismatched types: expected `core::result::Result<uint, ()>`, found `core::option::Option<_#1i>`
<anon>:6     let a: Result<uint, ()> = Some(1);
```

and float variables:

```rust
mismatched types: expected `core::result::Result<uint, ()>`, found `core::option::Option<_#1f>`
<anon>:6     let a: Result<uint, ()> = Some(0.5);
```

[0] https://twitter.com/coda/status/517713085465772032

Closes https://github.com/rust-lang/rust/issues/2632.
Closes https://github.com/rust-lang/rust/issues/3404.
Closes https://github.com/rust-lang/rust/issues/18426.

auto merge of #18431 : japaric/rust/show, r=alexcrichton

r? @aturon
cc #16918

DSTify Show and all the other formatting traits

auto merge of #18459 : alexcrichton/rust/rollup, r=alexcrichton

Test fixes and rebase conflicts

rollup merge of #18445 : alexcrichton/index-mut

Conflicts:
src/libcollections/vec.rs

rollup merge of #18430 : bjz/token

Conflicts:
src/libsyntax/parse/parser.rs

rollup merge of #18398 : aturon/lint-conventions-2

Conflicts:
src/libcollections/slice.rs
src/libcore/failure.rs
src/libsyntax/parse/token.rs
src/test/debuginfo/basic-types-mut-globals.rs
src/test/debuginfo/simple-struct.rs
src/test/debuginfo/trait-pointers.rs

rollup merge of #18452 : bkoropoff/issue-18425

rollup merge of #18443 : alexcrichton/deref-vec-and-string

rollup merge of #18442 : Manishearth/rust_panic

rollup merge of #18438 : jakub-/empty-file

auto merge of #18381 : pelmers/rust/patch-1, r=alexcrichton

Happened to be reading through the doc.

Use the `_` representation for integral variables as well

Add a test for errors unifying an integer variable with a float variable

Add a test for failure to unify type parameters

auto merge of #18339 : chastell/rust/guide_pattern_fixes, r=nikomatsakis

I think it helps to show that the variables introduced in match blocks are indeed independent from the matched variable `x` (especially when `x` is still reachable inside those blocks and might be useful), so this renames them accordingly. Maybe some linter (or language-level warning?) will eventually warn about shadowing `x` in such cases. ;)

I’m not super happy about the matching-on-range example, as it’s too contrived (`e` and `x` are exactly the same here), but I couldn’t come up with something both simple and non-redundant.

auto merge of #18377 : steveklabnik/rust/fix_wording_about_errors, r=nikomatsakis

see https://github.com/rust-lang/rust/pull/18176#discussion_r19374679

/cc @eddyb @huonw @nikomatsakis

rollup merge of #18421 : tbu-/pr_checkeddiv1

rollup merge of #18417 : P1start/lint-fixes

rollup merge of #18413 : bkoropoff/issue-18412

rollup merge of #18411 : richo/tm-null-check

rollup merge of #18409 : gamazeps/issue15273

rollup merge of #18408 : thestinger/unsafe

rollup merge of #18407 : thestinger/arena

rollup merge of #18397 : aochagavia/ascii

rollup merge of #18395 : cakebaker/fix_use_of_sqrt

rollup merge of #18393 : aochagavia/prelude

rollup merge of #18392 : cakebaker/remove_double_negation

auto merge of #18376 : steveklabnik/rust/gh7963, r=alexcrichton

FIxes #7963.

rollup merge of #18383 : bkoropoff/issue-17361

rollup merge of #18381 : pelmers/patch-1

collections: Enable IndexMut for some collections

This commit enables implementations of IndexMut for a number of collections,
including Vec, RingBuf, SmallIntMap, TrieMap, TreeMap, and HashMap. At the same
time this deprecates the `get_mut` methods on vectors in favor of using the
indexing notation.

cc #18424

auto merge of #18374 : steveklabnik/rust/gh18197, r=sfackler

Fixes #18197

auto merge of #18367 : pcwalton/rust/inline-atomic-constructors, r=thestinger

Servo really wants this.

r? @brson

auto merge of #18279 : bgamari/rust/check-static-recursion, r=alexcrichton

I just found this patch which at some point solved a problem I encountered. Unfortunately I apparently dropped it before I managed to write a test case. I'll try to dig up the code that triggered the issue.

Special-case some error messages about `Sized`

The error messages still aren’t as good as they were before DST, but they better
describe the actual problem, not mentioning `Sized` at all (because that bound
is normally implied, not explicitly stated).

Closes #17567.
Closes #18040.
Closes #18159.

Add a message for when a `.` follows a macro invocation

auto merge of #17704 : nick29581/rust/object-safety, r=nikomatsakis

r? @nikomatsakis

Add regression test for #18425

Fix ICE translating array repeat expr of non-Copy type

The type checker permits an array repeat expression of non-Copy
type if the count is 1, but trans asserts on it prior to this
change.

Closes #18425

auto merge of #18448 : brson/rust/clean-llvm, r=alexcrichton

When building for multiple targets, the initial 'make' invocation
always fails. The missing build stamp causes clean-llvm to be
invoked, but clean-llvm cleans *all* llvm builds. So what happens
is that 1) all llvm's are cleaned (a no-op), 2) llvm-${target1}
builds, 3) all llvm's are cleaned (deleting llvm-${target1}),
4) llvm-${target2} is built, 5) the remaining build for ${target1}
fails because llvm does not exist.

This makes the clean operation only clean the correct llvm build.
Should greatly reduce bot failures.

Improve the error message for parenthesised box expressions

Closes #15386.

Fix a minor issue with how lint groups are printed by rustc

Remove `unused_extern_crate` and `unused_result` from the `unused` lint group

These lints are allow by default because they are sometimes too sensitive.

check_static_recursion: Handle foreign items

Try and fix Windows terminal

Rebasing fixes

mk: Clean just one llvm build at a time. Closes #17852

When building for multiple targets, the initial 'make' invocation
always fails. The missing build stamp causes clean-llvm to be
invoked, but clean-llvm cleans *all* llvm builds. So what happens
is that 1) all llvm's are cleaned (a no-op), 2) llvm-${target1}
builds, 3) all llvm's are cleaned (deleting llvm-${target1}),
4) llvm-${target2} is built, 5) the remaining build for ${target1}
fails because llvm does not exist.

This makes the clean operation only clean the correct llvm build.
Should greatly reduce bot failures.

Changes for Windows terminal

Change extensions traits to blanket impls

changes to tests

changes to libs

Enforce object safety

closes #17670

[breaking-change]

Traits must be object-safe if they are to be used in trait objects. This might require splitting a trait into object-safe and non-object-safe parts.

Some standard library traits in std::io have been split - Reader has new traits BytesReader (for the bytes method) and AsRefReader (for by_ref), Writer has new trait AsRefWriter (for by_ref). All these new traits have blanket impls, so any type which implements Reader or Writer (respectively) will have an implmentation of the new traits. To fix your code, you just need to `use` the new trait.

collections: impl Deref for Vec/String

This commit adds the following impls:

    impl<T> Deref<[T]> for Vec<T>
    impl<T> DerefMut<[T]> for Vec<T>
    impl Deref<str> for String

This commit also removes all duplicated inherent methods from vectors and
strings as implementations will now silently call through to the slice
implementation. Some breakage occurred at std and beneath due to inherent
methods removed in favor of those in the slice traits and std doesn't use its
own prelude,

cc #18424

auto merge of #18359 : 1-more/rust/feature, r=alexcrichton

Rename rust_fail to rust_panic

Always drop var IDs from type variables modulo -Z verbose, per PR discussion

Address review comments

Update tests with the new diagnostic tweaks

Improve the readability of diagnostics that involve unresolved type variables

Diagnostics such as the following

```
mismatched types: expected `core::result::Result<uint,()>`, found `core::option::Option<<generic #1>>`
<anon>:6     let a: Result<uint, ()> = None;
                                       ^~~~
mismatched types: expected `&mut <generic #2>`, found `uint`
<anon>:7     f(42u);
               ^~~
```

tend to be fairly unappealing to new users. While specific type var IDs are valuable in
diagnostics that deal with more than one such variable, in practice many messages
only mention one. In those cases, leaving out the specific number makes the messages
slightly less terrifying.

In addition, type variables have been changed to use the type hole syntax `_` in diagnostics.
With a variable ID, they're printed as `_#id` (e.g. `_#1`). In cases where the ID is left out,
it's simply `_`. Integer and float variables have an additional suffix after the number, e.g.
`_#1i` or `_#3f`.

Formatting fixes

Remove Token::get_close_delimiter

We can simplify these usages due to the new delimiter representation. `Parser::expect_open_delim` has been added for convenience.

Use common variants for open and close delimiters

This common representation for delimeters should make pattern matching easier. Having a separate `token::DelimToken` enum also allows us to enforce the invariant that the opening and closing delimiters must be the same in `ast::TtDelimited`, removing the need to ensure matched delimiters when working with token trees.

auto merge of #18357 : TeXitoi/rust/simplify-reverse-complement, r=alexcrichton

Simpler, safer and shorter, in the same spirit of the current version, and the
same performances.

@mahkoh please review, I think I didn't change any performances related thing.

Remove an empty file from librustc

rustc: fail if LLVM is passed an invalid triple

This changes create_target_machine to correctly return a Result (Since
the underlying LLVM function can fail and return NULL)

auto merge of #17894 : steveklabnik/rust/fail_to_panic, r=aturon

This in-progress PR implements https://github.com/rust-lang/rust/issues/17489.

I made the code changes in this commit, next is to go through alllllllll the documentation and fix various things.

- Rename column headings as appropriate, `# Panics` for panic conditions and `# Errors` for `Result`s.
- clean up usage of words like 'fail' in error messages

Anything else to add to the list, @aturon ? I think I should leave the actual functions with names like `slice_or_fail` alone, since you'll get to those in your conventions work?

I'm submitting just the code bits now so that we can see it separately, and I also don't want to have to keep re-building rust over and over again if I don't have to :wink:

Listing all the bits so I can remember as I go:

- [x] compiler-rt
- [x] compiletest
- [x] doc
- [x] driver
- [x] etc
- [x] grammar
- [x] jemalloc
- [x] liballoc
- [x] libarena
- [x] libbacktrace
- [x] libcollections
- [x] libcore
- [x] libcoretest
- [x] libdebug
- [x] libflate
- [x] libfmt_macros
- [x] libfourcc
- [x] libgetopts
- [x] libglob
- [x] libgraphviz
- [x] libgreen
- [x] libhexfloat
- [x] liblibc
- [x] liblog
- [x] libnative
- [x] libnum
- [x] librand
- [x] librbml
- [x] libregex
- [x] libregex_macros
- [x] librlibc
- [x] librustc
- [x] librustc_back
- [x] librustc_llvm
- [x] librustdoc
- [x] librustrt
- [x] libsemver
- [x] libserialize
- [x] libstd
- [x] libsync
- [x] libsyntax
- [x] libterm
- [x] libtest
- [x] libtime
- [x] libunicode
- [x] liburl
- [x] libuuid
- [x] llvm
- [x] rt
- [x] test

Update infrastructure for fail -> panic

This includes updating the language items and marking what needs to
change after a snapshot.

If you do not use the standard library, the language items you need to
implement have changed. For example:

```rust
 #[lang = "fail_fmt"] fn fail_fmt() -> ! { loop {} }
```

is now

```rust
 #[lang = "panic_fmt"] fn panic_fmt() -> ! { loop {} }
```

Related, lesser-implemented language items `fail` and
`fail_bounds_check` have become `panic` and `panic_bounds_check`, as
well. These are implemented by `libcore`, so it is unlikely (though
possible!) that these two renamings will affect you.

[breaking-change]

Fix test suite

auto merge of #18282 : pczarn/rust/regex-parse, r=burntsushi

Fixes #18034

3 bugs fixed.

Rename fail! to panic!

https://github.com/rust-lang/rfcs/pull/221

The current terminology of "task failure" often causes problems when
writing or speaking about code. You often want to talk about the
possibility of an operation that returns a Result "failing", but cannot
because of the ambiguity with task failure. Instead, you have to speak
of "the failing case" or "when the operation does not succeed" or other
circumlocutions.

Likewise, we use a "Failure" header in rustdoc to describe when
operations may fail the task, but it would often be helpful to separate
out a section describing the "Err-producing" case.

We have been steadily moving away from task failure and toward Result as
an error-handling mechanism, so we should optimize our terminology
accordingly: Result-producing functions should be easy to describe.

To update your code, rename any call to `fail!` to `panic!` instead.
Assuming you have not created your own macro named `panic!`, this
will work on UNIX based systems:

    grep -lZR 'fail!' . | xargs -0 -l sed -i -e 's/fail!/panic!/g'

You can of course also do this by hand.

[breaking-change]

auto merge of #18375 : steveklabnik/rust/gh17969, r=alexcrichton

Fixes #17969

auto merge of #18365 : bjz/rust/token, r=alexcrichton

[breaking-change]

(for syntax-extensions)

- Token variant identifiers have been converted to PascalCase for consistency with Rust coding standards
- Some free-functions in `syntax::token` have been converted to methods on `syntax::token::Token`:
    - `can_begin_expr`         -> `Token::can_begin_expr`
    - `close_delimiter_for`    -> `Token::get_close_delimiter`
    - `is_lit`                 -> `Token::is_lit`
    - `is_ident`               -> `Token::is_ident`
    - `is_path`                -> `Token::is_path`
    - `is_plain_ident`         -> `Token::is_plain_ident`
    - `is_lifetime`            -> `Token::is_lifetime`
    - `is_mutability`          -> `Token::is_mutability`
    - `to_binop`               -> `Token::to_binop`
    - `is_keyword`             -> `Token::is_keyword`
    - `is_any_keyword`         -> `Token:is_any_keyword`
    - `is_strict_keyword`      -> `Token::is_strict_keyword`
    - `is_reserved_keyword`    -> `Token::is_reserved_keyword`
    - `mtwt_token_eq`          -> `Token::mtwt_eq`
- `token::Ident` now takes an enum instead of a boolean for clarity
- `token::{to_string, binop_to_string}` were moved to `pprust::{token_to_string, binop_to_string}`

Fix `core::num::CheckedDiv::checked_div` documentation

The "/" was probably generated by a `gq` in vim.

auto merge of #18340 : chastell/rust/guide_closures_fixes, r=steveklabnik

Some minor wording fixes to the Closures chapter; my brain tripped a few times when reading it, so I tried to come up with something a bit smoother. I’m not a native speaker, so please do review this critically.