Use primitive indexing in slice's Index/IndexMut

[bluss]

[T]'s Index implementation is normally not used for indexing, instead
the compiler supplied indexing is used.

Use the compiler supplied version in Index/IndexMut.

This removes an inconsistency:

Compiler supplied bound check failures look like this:

thread 'main' panicked at 'index out of bounds: the len is 3 but the index is 4'

If you convince Rust to use the Index impl for slices, bounds check
failure looks like this instead:

thread 'main' panicked at 'assertion failed: index < self.len()'

The latter is used if you for example use Index generically:

use std::ops::Index;fnfoo<T: ?Sized>(x:&T)whereT:Index<usize>{&x[4];}foo(&[1,2,3][..])

[rust-highfive]

r? @aturon

(rust_highfive has picked a reviewer for you, use r? to override)

[alexcrichton]

@bors: r+

Thanks!

[bors]

📌 Commit 20b9f1c has been approved by alexcrichton

[sfackler]

Test failure: https://travis-ci.org/rust-lang/rust/builds/159685433#L4672

[bors]

⌛ Testing commit 20b9f1c with merge 5675d4f...

[bors]

💔 Test failed - auto-win-msvc-64-opt-rustbuild

[alexcrichton]

@bors: retry

On Tue, Sep 13, 2016 at 7:48 PM, bors notifications@github.com wrote:

💔 Test failed - auto-win-msvc-64-opt-rustbuild
https://buildbot.rust-lang.org/builders/auto-win-msvc-64-opt-rustbuild/builds/2492

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#36454 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAD95DJGzlNKtv5nzesvkMdZscfglUIAks5qp2BugaJpZM4J8B2j
.

[bluss]

Thanks @sfackler

[bluss]

So huh, it has using the Index trait for arrays, that's not how I understood it.

[bluss]

Fixed the test by amending the commit.

[bluss]

To explain the mystery, it looks like array indexing uses the Index trait for slice in constexprs, and compiler-supplied indexing otherwise (do you know about this @oli-obk ?)

[alexcrichton]

@bors: r+

[bors]

📌 Commit 7e425d9 has been approved by alexcrichton

[oli-obk]

The error pattern is still wrong. It should not include "assertion failed".

The constexpr behaviour sounds very odd. Might be related to @eddyb's new const trans?

[alexcrichton]

@bors: r-

Indeed looks like travis is still failing

[eddyb]

Not sure if relevant, but if integer type inference is being relied on, #33903 could be involved.

[bluss]

Oh! Sorry, that was dumb. I'm fixing this up.

[bluss]

@bors r=alexcrichton

[bors]

📌 Commit a4ee9c6 has been approved by alexcrichton