Add rust-lldb pretty printing for Path and PathBuf

[n8henrie]

Fixes #120553
Fixes #48462

[rustbot]

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

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[n8henrie]

These both work in my local testing, providing human-readable output for Path and PathBuf for both utf-8 and non-utf-8 content.

For the non-UTF8, I tested with:

use std::ffi::OsStr;
use std::os::unix::ffi::OsStrExt;
use std::path::{Path, PathBuf};

fn main() {
    let my_pathbuf: PathBuf = OsStr::from_bytes(&[0x66, 0x6f, 0x80, 0x6f]).into();
    let my_path: &Path = my_pathbuf.as_path();
    println!("{}", my_path.display());
    println!("{}", my_pathbuf.display());
}

$ ./rust-lldb -o 'break set --file main.rs --line 8' -o run -o 'po my_pathbuf' target/debug/foo
...
(lldb) po my_pathbuf
"fo�o"

Or for the path:

(lldb) po my_path
b'fo\x80o'

I need some feedback on the regex used to identify the Path and PathBuf -- specifically, the other regexes seem to be using capture groups of unclear significance, e.g.:

"^(std::ffi::([a-z_]+::)+)OsString$"
vs
"^std::ffi::OsString$"

When wouldn't the latter work? Are the capture groups getting used elsewhere that I failed to notice?

• what is an example case making ([a-z_]+::)+ necessary?
• what is an example case making the outer capture group ((std to +)) necessary?

Happy to add these in to the regexes I used, just hoping to understand.

[Mark-Simulacrum]

I'm not sure why/whether we need those capture groups, but would prefer to have this continue using them for consistency if nothing else.

I think it would also be good to add some tests verifying this functionality works. I think you should be able to look at e.g. tests/debuginfo/rc_arc.rs and mirror that for PathBuf/OsString.

@rustbot author

[n8henrie]

Sounds great, thanks for feedback. Will work on it.

would prefer to have this continue using them for consistency if nothing else

If they're unnecessary (and confusing), would it make sense to ensure consistency by removing the others? Happy to format mine to match in the meantime, just curious / hoping to learn.

It looks like much of this was added by @artemmukhin in 47c26e6 -- do you have any insight regarding the above, specifically:

• what is an example case making ([a-z_]+::)+ necessary?
• what is an example case making the outer capture group ((std to +)) necessary?

Tests sound great. Thanks for the tip to check out rc_arc.rs.

[artemmukhin]

@n8henrie Thanks for reaching out.

I recall that when I started working on Rust pretty-printers in 2018, the Rust stdlib was undergoing changes, and entities were shifting between different packages. For instance, in Rust 1.20, we saw movements like collections::string::String to alloc::string::String and collections::vec::Vec to alloc::vec::Vec. The idea behind the somewhat complex regex was to make the pretty-printers more resilient to such changes. Keep in mind, the pretty-printers were initially designed specifically for IDEs, so they had to work with all conceivable versions of Rust. However, with the Rust stdlib structure becoming more stable over time, this seems unnecessary. I don't think capture groups are necessary either, and I can't remember why I used them in the first place.

For a reference on comprehensive and well-maintained collection of Rust LLDB pretty-printers, I suggest looking into the CodeLLDB. Particularly, the regex patterns used by CodeLLDB are simpler, for instance std::path::PathBuf instead of ^(std::([a-z_]+::)+)PathBuf$. Remarkably, these simple regex patterns seem robust over the years, requiring only minimal adjustments.

[n8henrie]

Thank you @artemmukhin! So it sounds like the more complicated regexes were in large part planning ahead for a problem that never manifested and no longer seems to be a concern. They would certainly be a lot more readable if simplified. @Mark-Simulacrum does this change your opinion at all about how I proceed? For example, I'd be happy to match the existing pattern for now and open a separate PR to consider simplifying all of the patterns. Or perhaps just adding a code comment linking to the above explanation for future searchers.

[Mark-Simulacrum]

I think matching for now and filing a separate PR updating all of them is best, perhaps confirming that we have tests for each of them.

[n8henrie]

I need to learn more about the test infra.

For some reason running the debug tests like so: ./x.py test tests/debuginfo/path.rs

Is not using my modifications to lldb_commands -- I can see in the output that it gets to type summary add [snip] NonZero but does not include the additions for Path.

type synthetic add -l lldb_lookup.synthetic_lookup -x '.*' --category Rust
type summary add -F lldb_lookup.summary_lookup  -e -x -h '^(alloc::([a-z_]+::)+)String$' --category Rust
type summary add -F lldb_lookup.summary_lookup  -e -x -h '^&(mut )?str$' --category Rust
type summary add -F lldb_lookup.summary_lookup  -e -x -h '^&(mut )?\[.+\]$' --category Rust
type summary add -F lldb_lookup.summary_lookup  -e -x -h '^(std::ffi::([a-z_]+::)+)OsString$' --category Rust
type summary add -F lldb_lookup.summary_lookup  -e -x -h '^(alloc::([a-z_]+::)+)Vec<.+>$' --category Rust
type summary add -F lldb_lookup.summary_lookup  -e -x -h '^(alloc::([a-z_]+::)+)VecDeque<.+>$' --category Rust
type summary add -F lldb_lookup.summary_lookup  -e -x -h '^(alloc::([a-z_]+::)+)BTreeSet<.+>$' --category Rust
type summary add -F lldb_lookup.summary_lookup  -e -x -h '^(alloc::([a-z_]+::)+)BTreeMap<.+>$' --category Rust
type summary add -F lldb_lookup.summary_lookup  -e -x -h '^(std::collections::([a-z_]+::)+)HashMap<.+>$' --category Rust
type summary add -F lldb_lookup.summary_lookup  -e -x -h '^(std::collections::([a-z_]+::)+)HashSet<.+>$' --category Rust
type summary add -F lldb_lookup.summary_lookup  -e -x -h '^(alloc::([a-z_]+::)+)Rc<.+>$' --category Rust
type summary add -F lldb_lookup.summary_lookup  -e -x -h '^(alloc::([a-z_]+::)+)Arc<.+>$' --category Rust
type summary add -F lldb_lookup.summary_lookup  -e -x -h '^(core::([a-z_]+::)+)Cell<.+>$' --category Rust
type summary add -F lldb_lookup.summary_lookup  -e -x -h '^(core::([a-z_]+::)+)Ref<.+>$' --category Rust
type summary add -F lldb_lookup.summary_lookup  -e -x -h '^(core::([a-z_]+::)+)RefMut<.+>$' --category Rust
type summary add -F lldb_lookup.summary_lookup  -e -x -h '^(core::([a-z_]+::)+)RefCell<.+>$' --category Rust
type summary add -F lldb_lookup.summary_lookup  -e -x -h '^core::num::([a-z_]+::)*NonZero.+$' --category Rust
type category enable Rust

I have cleaned (x.py clean) and completely removed the build folder.

There seems to be a variety of copies of the file, some which include my previous commit and some which don't:

$ fd -u lldb_commands -X rg --files-with-matches Path
./build/aarch64-apple-darwin/stage2/lib/rustlib/etc/lldb_commands
./src/etc/lldb_commands
$ fd -u lldb_commands -X rg --files-without-match Path
./build/aarch64-apple-darwin/stage0/lib/rustlib/etc/lldb_commands
./build/aarch64-apple-darwin/ci-rustc/lib/rustlib/etc/lldb_commands
./build/aarch64-apple-darwin/rustfmt/lib/rustlib/etc/lldb_commands

Ah, it looks like the lldb_commands script is hardcoded here:

rust/src/tools/compiletest/src/runtest.rs

Line 1479 in 8f359be

let rust_type_regexes = vec![

That seems like an unusual choice. Wouldn't it be better to include_str! (or something like that) this file, to ensure the script that users run is the same one used in testing?

[n8henrie]

@Mark-Simulacrum I think I have a little better understanding of the infra and all tests passing now. Based on the helpful context form @artemmukhin, once / if this is merged, I'll open a new PR with simplified regexes that I think will be far less confusing to new contributors such as myself, as it seems some of the capture groups have never been necessary, and others seem no longer necessary.

[bors]

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

[rustbot]

Some changes occurred in src/tools/compiletest

cc @jieyouxu

[n8henrie]

Ugh, some mistakes in my rebase. Will fix.

[bors]

⌛ Testing commit 9bba3aa with merge 45f0775...

[bors]

💔 Test failed - checks-actions

[n8henrie]

Looks like other PRs may be failing with that same error (ninja: error: build.ninja:3780: multiple outputs aren't (yet?) supported by depslog; bring this up on the mailing list if it affects you: https://github.com/rust-lang-ci/rust/actions/runs/8473462168/job/23217838956) -- is that indicative of a problem with my PR? Or perhaps unrelated?

[Noratrieb]

you're fine
@bors retry #122671 (comment)

[bors]

⌛ Testing commit 9bba3aa with merge ea75669...

[bors]

💔 Test failed - checks-actions

[Mark-Simulacrum]

@bors r+

[bors]

📌 Commit 41e97a0 has been approved by Mark-Simulacrum

It is now in the queue for this repository.

[bors]

⌛ Testing commit 41e97a0 with merge 69fa40c...

[bors]

☀️ Test successful - checks-actions
Approved by: Mark-Simulacrum
Pushing 69fa40c to master...

[rust-timer]

Finished benchmarking commit (69fa40c): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.9%	[2.3%, 3.8%]	4
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 671.487s -> 670.4s (-0.16%)
Artifact size: 315.77 MiB -> 315.77 MiB (0.00%)