Don't use a SyntheticProvider for literally every type

[Walnut356]

Replaces a glob regex with individualized imports for each standard library type. This improves debugger performance by quite a bit when populating lots of values with lots of fields

With the glob, afaik every single value of every single type that the debugger renders is run through a python function that does quite a few string comparisons (i plan to fix those next) to determine the SyntheticProvider to use. It looks like DefaultSyntheticProvider's functions internally call the liblldb c++ functions, which ends up with identical behavior to not using a SyntheticProvider at all, except you have extra python round trips slowing things down.

These sample vidoes were run on x86-64-pc-windows-gnu. vect is a 1000 element Vec<Big>, Big contains a dozen or so Small, and Small contains a dozen or so [i32; 5]

Before:

asdf2.mov

After:

asdf.mov

---

try-job: aarch64-apple

[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) some time within the next two weeks.

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

[Mark-Simulacrum]

@bors r+

[bors]

📌 Commit 673b3d3 has been approved by Mark-Simulacrum

It is now in the queue for this repository.

[jhpratt]

@bors r-

failing in CI: #133442 (comment)

[Walnut356]

Ah, well that's an unfortunate issue to say the least. I don't have a great way to run the test suite on my end - I've tried via both x86_64-pc-windows-gnu and x86_64-unknown-linux-gnu (via WSL) and both result in python failing to import the _lldb module for whatever reason.

Based on the output and some manual experimentation, it looks like, by default, lldb uses different formatting defaults for Synthetic vs Non Synthetic types? Essentially the -e option isn't enabled. VSCode + codelldb visualizes it the same either way (including the summary for whatever reason), but the raw string output from LLDB is different.

The result is that the type output with my patch looks like this:

(temp::SomeStruct) *stack_val_ref = (x = 10, y = 23.5)

without the patch, the output (and expectation from the test) is:

(temp::SomeStruct) *stack_val_ref = {
  x = 10
  y = 23.5
}

There is a solution, but it's a little jank.

type summary add -F _ -e -x -h "^.*$" --category Rust

This works (i think) because the summary is invalid, thus it defaults to LLDB's default, but with the extra flags. I'd love to do this in a less stupid way, but as far as I can tell there is no way, given an SBValue, to give that value an SBTypeSummary (and thus set its formatting options such that it prints expanded).

It looks like the order of the commands does matter as well, so it needs to be put before all the rest of the type summary add commands.

With the additional testing, it seems clear that this change mostly impacts codelldb, since codelldb's extra processing steps for synthetic types are relatively slow. That said, it's still probably better overall not to use synthetic types for everything when we don't have to.

I tested this with LLDB-DAP as well and the output seems to be the same before and after

[Walnut356]

@rustbot review

[Mark-Simulacrum]

@bors r+

[bors]

📌 Commit 8ecac88 has been approved by Mark-Simulacrum

It is now in the queue for this repository.

[matthiaskrgr]

@bors r- rollup=never
#133612 (comment)

[Walnut356]

Whoops, looks like there was never any explicit type synthetic lookup for tuples, they just happened to be caught by the wildcard. Every case that failed was one that involved tuples. Should be all good now

@rustbot review

[Zalathar]

@bors try

[bors]

⌛ Trying commit 9b4a247 with merge de6acf0...

[bors]

☀️ Try build successful - checks-actions
Build commit: de6acf0 (de6acf077184c7e69e73ea3c456ecf48cbd667a1)