Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add rust-lldb pretty printing for Path and PathBuf #120557

Merged
merged 1 commit into from
Mar 30, 2024

Conversation

n8henrie
Copy link
Contributor

@n8henrie n8henrie commented Feb 1, 2024

Fixes #120553
Fixes #48462

@rustbot
Copy link
Collaborator

rustbot commented Feb 1, 2024

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

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Feb 1, 2024
@n8henrie
Copy link
Contributor Author

n8henrie commented Feb 1, 2024

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
Copy link
Member

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

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 4, 2024
@n8henrie
Copy link
Contributor Author

n8henrie commented Feb 4, 2024

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
Copy link
Contributor

@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
Copy link
Contributor Author

n8henrie commented Feb 5, 2024

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
Copy link
Member

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.

@rust-log-analyzer

This comment has been minimized.

@n8henrie
Copy link
Contributor Author

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:

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?

@rustbot rustbot added A-testsuite Area: The testsuite used to check the correctness of rustc T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) labels Feb 24, 2024
@rust-log-analyzer

This comment has been minimized.

n8henrie added a commit to n8henrie/rust that referenced this pull request Feb 26, 2024
According to logic in rust-lang#120557 (comment)
the capture groups may be unnecessary and could possibly go with something
as simple as `std::path::PathBuf` as done in CodeLLDB:
https://github.com/vadimcn/codelldb/blob/05502bf75e4e7878a99b0bf0a7a81bba2922cbe3/formatters/rust.py#L59C56-L59C74

However for consistency will follow the pattern for now and consider updating all of regexes in a future PR.
@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@n8henrie
Copy link
Contributor Author

n8henrie commented Feb 28, 2024

@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
Copy link
Contributor

bors commented Mar 17, 2024

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

@rustbot
Copy link
Collaborator

rustbot commented Mar 17, 2024

Some changes occurred in src/tools/compiletest

cc @jieyouxu

@n8henrie
Copy link
Contributor Author

Ugh, some mistakes in my rebase. Will fix.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Mar 28, 2024
@bors
Copy link
Contributor

bors commented Mar 28, 2024

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

bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 28, 2024
…crum

Add rust-lldb pretty printing for Path and PathBuf

Fixes rust-lang#120553
Fixes rust-lang#48462
@bors
Copy link
Contributor

bors commented Mar 28, 2024

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Mar 28, 2024
@rust-log-analyzer

This comment has been minimized.

@n8henrie
Copy link
Contributor Author

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
Copy link
Member

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

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 28, 2024
bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 29, 2024
…crum

Add rust-lldb pretty printing for Path and PathBuf

Fixes rust-lang#120553
Fixes rust-lang#48462
@bors
Copy link
Contributor

bors commented Mar 29, 2024

⌛ Testing commit 9bba3aa with merge ea75669...

@rust-log-analyzer

This comment has been minimized.

@bors
Copy link
Contributor

bors commented Mar 29, 2024

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Mar 29, 2024
@Mark-Simulacrum
Copy link
Member

@bors r+

@bors
Copy link
Contributor

bors commented Mar 30, 2024

📌 Commit 41e97a0 has been approved by Mark-Simulacrum

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 30, 2024
@bors
Copy link
Contributor

bors commented Mar 30, 2024

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

@bors
Copy link
Contributor

bors commented Mar 30, 2024

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

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Mar 30, 2024
@bors bors merged commit 69fa40c into rust-lang:master Mar 30, 2024
12 checks passed
@rustbot rustbot added this to the 1.79.0 milestone Mar 30, 2024
@rust-timer
Copy link
Collaborator

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%)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-testsuite Area: The testsuite used to check the correctness of rustc merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
Projects
None yet
8 participants