Add pretty printer for &mut []

[untitaker]

Fix #30232

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[untitaker]

BTW I've verified the new behavior manually using rust-gdb.

[alexcrichton]

Thanks! Can you add a test for this as well?

[untitaker]

I have added tests now, but haven't verified locally whether they pass because I have had enough of that experience while working on #30250. IIRC I even found out a way to just run the lldb/gdb tests, but the testrunner still recompiled rustc every time.

[untitaker]

I've now also triggered extra builds to tests whether the tests are effective (I wouldn't know), because in #30250 I've had the CI pass even though it shouldn't.

Any hint on how to run the tests efficiently locally would be apprechiated.

EDIT: BTW I'd like to rebase everything into one commit before merge.

[alexcrichton]

Looks good to me! If you want to squash I'll r+

[untitaker]

I don't understand why the tests pass for b031de3

[untitaker]

Ah, it seems that Travis doesn't test this part of the system, only Bors does. Is there a different way to verify that the tests are effective?

[alexcrichton]

Oh it appears that travis doesn't have gdb installed, so it's not running gdb tests. I believe that's an error! If you'd like, you could modify .travis.yml to install gdb and verify they're running?

[untitaker]

This might be intentional as IIRC according to CONTRIBUTING, Travis only runs a subset of all tests.

On 12 January 2016 01:34:48 CET, Alex Crichton [email protected] wrote:

Oh it appears that travis doesn't have gdb installed, so it's not
running gdb tests. I believe that's an error! If you'd like, you could
modify .travis.yml to install gdb and verify they're running?

---

Reply to this email directly or view it on GitHub:
#30249 (comment)

Sent from my phone. Please excuse my brevity.

[alexcrichton]

That's somewhat outdated, there's no reason we didn't install gdb on travis afaik.

I'm fine with merging though, so if you want to squash we can send to bors

[untitaker]

I've now updated the PR to install gdb and lldb explicitly in Travis. The first commit contains the test and the changes to travis.yml, and should fail if Travis runs the tests correctly. The second commit contains the actual fix.

[alexcrichton]

Looks like the gdb tests did indeed run on travis, but it also looks like one of them failed.

[sfackler]

This looks like it's good to go?

[untitaker]

It seems that lldb tests are only run on OS X, so I have no way of verifying whether the tests I wrote are any good.

[alexcrichton]

@bors: r+ 1ca7b2e

[bors]

⌛ Testing commit 1ca7b2e with merge 944bd28...

[bors]

💔 Test failed - auto-mac-64-opt

[Manishearth]

failures:

---- [debuginfo-lldb] debuginfo/vec-slices.rs stdout ----
    NOTE: compiletest thinks it is using LLDB version 310

error: line not found in debugger output: [...]$6 = &mut [64, 65]
status: exit code: 0
command: "/usr/bin/python2.7" "/Users/rustbuild/src/rust-buildbot/slave/auto-mac-64-opt/build/src/etc/lldb_batchmode.py" "x86_64-apple-darwin/test/debuginfo-lldb/vec-slices.stage2-x86_64-apple-darwin" "x86_64-apple-darwin/test/debuginfo-lldb/vec-slices.debugger.script"
stdout:
------------------------------------------
LLDB batch-mode script
----------------------
Debugger commands script is 'x86_64-apple-darwin/test/debuginfo-lldb/vec-slices.debugger.script'.
Target executable is 'x86_64-apple-darwin/test/debuginfo-lldb/vec-slices.stage2-x86_64-apple-darwin'.
Current working directory is '/Users/rustbuild/src/rust-buildbot/slave/auto-mac-64-opt/build/obj'
Creating a target for 'x86_64-apple-darwin/test/debuginfo-lldb/vec-slices.stage2-x86_64-apple-darwin'
settings set auto-confirm true

version
lldb-310.2.37 
command script import /Users/rustbuild/src/rust-buildbot/slave/auto-mac-64-opt/build/./src/etc/lldb_rust_formatters.py
type summary add --no-value --python-function lldb_rust_formatters.print_val -x ".*" --category Rust
type category enable Rust

breakpoint set --line 112
Breakpoint 1: where = vec-slices.stage2-x86_64-apple-darwin`vec_slices::main + 206 at vec-slices.rs:112, address = 0x0000000100000a4e 
run
Hit breakpoint 1.1: where = vec-slices.stage2-x86_64-apple-darwin`vec_slices::main + 206 at vec-slices.rs:112, address = 0x0000000100000a4e, resolved, hit count = 1 
Process 39175 launched: '/Users/rustbuild/src/rust-buildbot/slave/auto-mac-64-opt/build/obj/x86_64-apple-darwin/test/debuginfo-lldb/vec-slices.stage2-x86_64-apple-darwin' (x86_64) 
print empty
(&[i64]) $0 = &[] 
print singleton
(&[i64]) $1 = &[1] 
print multiple
(&[i64]) $2 = &[2, 3, 4, 5] 
print slice_of_slice
(&[i64]) $3 = &[3, 4] 
print padded_tuple
(&[(i32, i16)]) $4 = &[(6, 7), (8, 9)] 
print padded_struct
(&[vec_slices::AStruct]) $5 = &[AStruct { x: 10, y: 11, z: 12 }, AStruct { x: 13, y: 14, z: 15 }] 
print 'vec_slices::MUT_VECT_SLICE'
(int) $6 = 1279869765 
quit


------------------------------------------
stderr:
------------------------------------------

------------------------------------------

thread '[debuginfo-lldb] debuginfo/vec-slices.rs' panicked at 'explicit panic', /Users/rustbuild/src/rust-buildbot/slave/auto-mac-64-opt/build/src/compiletest/runtest.rs:1505
note: Run with `RUST_BACKTRACE=1` for a backtrace.


failures:
    [debuginfo-lldb] debuginfo/vec-slices.rs

test result: FAILED. 90 passed; 1 failed; 10 ignored; 0 measured

[untitaker]

print 'vec_slices::MUT_VECT_SLICE'
(int) $6 = 1279869765 

that seems unreal. Anybody knows what is happening there?

[alexcrichton]

Closing due to inactivity, but feel free to reopen with the test fixed!

[untitaker]

@alexcrichton I don't know how to fix the test failures and asked for help in the previous comment.

[untitaker]

Also sorry for the slow reply!