Give SliceIndex impls a test suite of girth befitting the implementation

[ExpHP]

So one day I was writing something in my codebase that basically amounted to impl SliceIndex for (Bound<usize>, Bound<usize>), and I said to myself:

Boy, gee, golly! I never realized bounds checking was so tricky!

At some point when I had around 60 lines of tests for it, I decided to go see how the standard library does it to see if I missed any edge cases. ...That's when I discovered that libcore only had about 40 lines of tests for slicing altogether, and none of them even used ..=.

---

This PR includes:

• Literally the first appearance of the word get_unchecked_mut in any directory named test or tests.
• Likewise the first appearance of get_mut used with any type of range argument in these directories.
• Tests for the panics on overflow with ..=.
  • I wanted to test on [(); usize::MAX] as well but that takes linear time in debug mode </3
• A horrible and ugly test-generating macro for the should_panic tests that increases the DRYness by a single order of magnitude (which IMO wasn't enough, but I didn't want to go any further and risk making the tests inaccessible to next guy).
• Same stuff for str!
  • Actually, the existing str tests were pretty good. I just helped filled in the holes.
• A fix for the bug it caught. (only one sadly)

[rust-highfive]

r? @bluss

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

[rust-highfive]

Your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

Resolving deltas: 100% (605067/605067), completed with 4761 local objects.
---
[00:00:44] configure: rust.quiet-tests     := True
---
[00:04:45] tidy error: /checkout/src/liballoc/tests/str.rs:642: line longer than 100 chars
[00:04:45] tidy error: /checkout/src/liballoc/tests/str.rs:651: line longer than 100 chars
[00:04:45] tidy error: /checkout/src/liballoc/tests/str.rs:660: line longer than 100 chars
[00:04:45] tidy error: /checkout/src/liballoc/tests/str.rs:669: line longer than 100 chars
[00:04:45] tidy error: /checkout/src/liballoc/tests/str.rs:678: line longer than 100 chars
[00:04:45] tidy error: /checkout/src/liballoc/tests/str.rs:687: line longer than 100 chars
[00:04:45] tidy error: /checkout/src/liballoc/tests/str.rs:696: line longer than 100 chars
[00:04:45] tidy error: /checkout/src/liballoc/tests/str.rs:705: line longer than 100 chars
[00:04:45] tidy error: /checkout/src/liballoc/tests/str.rs:706: line longer than 100 chars
[00:04:45] tidy error: /checkout/src/liballoc/tests/str.rs:707: line longer than 100 chars
[00:04:46] some tidy checks failed
[00:04:46]
[00:04:46]
[00:04:46] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/tidy" "/checkout/src" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "--no-vendor" "--quiet"
[00:04:46] expected success, got: exit code: 1
[00:04:46]
[00:04:46]
[00:04:46] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
[00:04:46] Build completed unsuccessfully in 0:01:53
[00:04:46] Makefile:79: recipe for target 'tidy' failed
[00:04:46] make: *** [tidy] Error 1
---
$ ls -lat $HOME/Library/Logs/DiagnosticReports/
ls: cannot access /home/travis/Library/Logs/DiagnosticReports/: No such file or directory
travis_time:end:0258ba80:start=1523916453831324825,finish=1523916453837939675,duration=6614850
travis_fold:end:after_failure.2
travis_fold:start:after_failure.3
travis_time:start:03250e15
$ find $HOME/Library/Logs/DiagnosticReports -type f -name '*.crash' -not -name '*.stage2-*.crash' -not -name 'com.apple.CoreSimulator.CoreSimulatorService-*.crash' -exec printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" {} \; -exec head -750 {} \; -exec echo travis_fold":"end:crashlog \; || true
find: `/home/travis/Library/Logs/DiagnosticReports': No such file or directory
travis_time:end:03250e15:start=1523916453843528410,finish=1523916453849607489,duration=6079079
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:1f619d66
$ dmesg | grep -i kill
[   10.250665] init: failsafe main process (1092) killed by TERM signal

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

[ExpHP]

On second thought I think I'm going to pull the bug fix into a separate PR to make it easier to backport to beta

[ExpHP]

Note: After #50039 merges, this will need to be rebased/force-pushed (I couldn't cherry-pick the commit from this PR).

When I do so I will likely:

• revisit the syntax for the test-generating macro in this PR (because I really hate it)
• look for any other RangeXyzInclusive methods that can be delegated to RangeXyz (smaller PR just to fix #50002 #50039 (comment))

so any review might want to hold off until then.

[bors]

☔ The latest upstream changes (presumably #50039) made this pull request unmergeable. Please resolve the merge conflicts.

[pietroalbini]

Ping from triage @ExpHP! #50039 was merged, this needs the rebase.

[ExpHP]

Oops, sorry! I did something locally, but then started having second thoughts due to how uneven the PR makes this part of the test suite appear, and chickened out. I guess I should follow through and just get it back up here, to let others be the judge of that.

(also, my local branch currently has the cardinal sin of a later commit that broadly changes decisions made in an earlier commit, but it seemed too difficult to clean up due to intervening commits, so I'm afraid I might have to leave it like that. Blechh)

[ExpHP]

rebased, force-pushed, and put into correct chronological order using black magic.

Notes:

• Be aware that the macro syntax introduced in ce66f5d is revised in later commits.
  • (Crap, I just noticed now that I actually could have squashed these easily, thanks to having removed some of the intervening commits at the last minute. Sorry)
• I tried not to include any substantial changes to existing test cases in ce66f5d, 030aa9b, or f1d7b45 beyond the format (i.e. I tried to preserve their inputs and expected outputs/modes of failure).
• The concern addressed by 02b3da1 is purely anticipatory/not backed by evidence

[shepmaster]

Ping from triage, @bluss! Will you have time to review this in the near future?

[pietroalbini]

Ping from triage! This PR needs a review, can @bluss or someone else from @rust-lang/libs review this?

[alexcrichton]

Egad sorry for the delay @ExpHP! Tihs all looks great to me, thanks!

@bors: r+

[bors]

📌 Commit f1d7b45 has been approved by alexcrichton

[bors]

⌛ Testing commit f1d7b45 with merge 5f566f2ae20052cc0fdb384120ee56ab4ff32b0d...

[alexcrichton]

@bors: retry r-

prioritizing rollup which includes this in it

I think the simple_big test may also have been the cause of https://travis-ci.org/rust-lang/rust/jobs/377407894, so I've ignored the test for Emscripten specifically in the rollup and we can see how that goes

[ExpHP]

Makes sense. The test was present before this PR, but my PR adds a to_owned() (hidden in the assert_range_eq! macro) that might be pushing it just over the limit.