rust-gdb/rust-lldb: Trim output of vec/slice/array

[untitaker]

Fix #29467

I have tested this with rust-gdb, but rust-lldb is completely untested.

It prints "cannot access memory" for the example in #29467 instead of hanging
up.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nikomatsakis (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.

[alexcrichton]

r? @michaelwoerister

[michaelwoerister]

Looks good to me. Let's see if it passes the LLDB tests.

[michaelwoerister]

@bors r+

[bors]

📌 Commit 0899f9d has been approved by michaelwoerister

[bors]

⌛ Testing commit 0899f9d with merge a6e0bd7...

[bors]

💔 Test failed - auto-mac-32-opt

[untitaker]

The scoping bugs in the lldb scripts should now be fixed.

[untitaker]

I'm not sure if there's something wrong with my dev environment, because I can't get the tests to fail locally when reverting the actual fix.

[michaelwoerister]

The test case should not contain the #![omit_gdb_pretty_printer_section] since we actually want to test the GDB pretty printers.

[untitaker]

@michaelwoerister I've removed that attr, please take a look again. It seems that the testcase passes both with and without the fix, but I'm not sure why.

[untitaker]

My current suspicion is that ... is interpreted as a wildcard by the testrunner?

[michaelwoerister]

Only [...] should be interpreted as a wildcard. Let me see if I can reproduce your results.

[untitaker]

I see, I've updated the ... to .. though

[michaelwoerister]

@untitaker OK, so I've looked into LLDB and since we are producing actual strings there, it would be a greater undertaking to do the same as in GDB (and it's not clear that we actually want to do that there).

My proposal would be:

• Move MAX_CHILDREN into lldb_rust_formatters.py and only use it there.
• Make the GDB versions return an iterator as @tromey suggested (by just removing the list() call, presumably).
• Adapt the test cases accordingly.

[untitaker]

I'm unsure on how to adapt the tests, and can't get them to fail. I'm thinking about removing them.

[michaelwoerister]

You can take the adapted tests from here:
https://github.com/michaelwoerister/rust/blob/pp-huge-vec/src/test/debuginfo/huge-vec.rs
This version worked for me on Linux and Mac OS.

[untitaker]

Updated with your test. The first testcase build should fail, the second one pass. Otherwise something is seriously broken.

[untitaker]

The relevant tests unexpectedly pass on Travis, but I get stylecheck errors.

[michaelwoerister]

You need to add the line // ignore-tidy-linelength below // min-lldb-version: 310 to tell the build script that it shouldn't care about line length in this file.

[untitaker]

But why do the tests pass without the fix?

[michaelwoerister]

Where do you see them passing? In the Travis log I only see 'make tidy' running (and failing).

[untitaker]

Sorry, yes. Updated PR.

[michaelwoerister]

@bors r+

[bors]

📌 Commit be44f1e has been approved by michaelwoerister

[bors]

⌛ Testing commit be44f1e with merge c50d71a...

[bors]

💔 Test failed - auto-win-gnu-64-opt

[michaelwoerister]

Almost passing. Pretty printers are not enabled on Windows.
Please add the following directives (somewhere near min-lldb-version):

// ignore-windows
// ignore-freebsd
// ignore-android
// min-gdb-version 7.7

Those are the same as in the pretty-std.rs test file, so they should be up-to-date.

[untitaker]

I'd like to wait for #30249 such that I can run the gdb/lldb tests in Travis.

[alexcrichton]

Looks like #30249 is stalling, so I'm gonna close this one as well (not a lot of activity), but feel free to resubmit!

[cptroot]

I'm running into this issue right now where LLDB is trying to print a 591KiB byte slice everytime I step through my nom parser. Is there any way that I can revive this really old PR? Looking for guidance on what caused this to go unmerged in the past.

[tromey]

I think the gdb parts are probably not needed any more, at least not with a new-enough gdb (so that the struct printer is not used). You can control the number of printed elements in gdb with set print elements, and AFAICT all the other gdb pretty-printers read values lazily.

For lldb, I think the formatters need some updates to provide synthetic children. (This came up in a different bug as well; I'll file a bug for this specifically.) Then maybe the target.max-children-count setting will apply correctly.