[Debug Info] replace lldb_commands with __lldb_init_module#155336
[Debug Info] replace lldb_commands with __lldb_init_module#155336Walnut356 wants to merge 1 commit intorust-lang:mainfrom
lldb_commands with __lldb_init_module#155336Conversation
|
Some changes occurred in src/tools/compiletest cc @jieyouxu |
|
rustbot has assigned @Mark-Simulacrum. Use Why was this reviewer chosen?The reviewer was selected based on:
|
|
now that i think on it, apple's LLDB is a custom fork. I don't think the version extraction logic will work for it. Lemme fix that real quick. |
This comment has been minimized.
This comment has been minimized.
|
You should be able to run try jobs on this PR urself after this: |
|
✌️ @Walnut356, you can now perform try builds on this pull request! You can now post |
e4db5e7 to
e8cc4eb
Compare
|
rad, thank you |
This comment has been minimized.
This comment has been minimized.
e8cc4eb to
40198c7
Compare
|
@bors try jobs=aarch64-apple |
[Debug Info] replace `lldb_commands` with `__lldb_init_module` try-job: aarch64-apple
This comment has been minimized.
This comment has been minimized.
|
💔 Test for d52c8f9 failed: CI. Failed job:
|
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
Okay, bad news is this test didn't go exactly as planned because
i'm still iffy on whether I want to just update the tests, or if i want to force a |
|
I guess I should also note that, in additional bad news, apples versioning scheme seems to have 0 relation to llvm's, so using raw version numbers probably won't work. I should be able to just check for features via |
|
☔ The latest upstream changes (presumably #155710) made this pull request unmergeable. Please resolve the merge conflicts. |
…youxu Account for `GetSyntheticValue` failures `GetSyntheticValue` returns an invalid `SBValue` if no synthetic is present. That wasn't a problem before when we were attaching synthetics to every type, but it won't be the case once github.com/rust-lang/pull/155336 or similar lands. Additionally, codelldb subverts `lldb_commands` to apply similar behavior that doesn't attach synthetics to every type, so this fixes a regression there too. Additionally, I removed 1 useless instance of `GetSyntheticValue`, since pointers should always be `IndirectionSyntheticProvider`, not `DefaultSyntheticProvider`.
DO NOT MERGE. Please run through
aarch64-apple. Ideally the tests fail. If they don't, the test runner is using too old of a version of LLDB and I need to fiddle with this some more.TL;DR I hate
lldb_commands, it's annoying to update and maintain since it's just a raw text file of CLI commands. All of the functionality can be replicated via the debugger's own API.__lldb_init_moduleis called immediately uponcommand script import lldb_lookup.py, so it should function identically (with one exception, see below). We can do things like let python tell us the names of the functions and classes, making them easier to keep in sync. Most importantly, we can conditionally use one set of visualizers or another depending on the version of the debugger. This is a precursor to using callback-based type matching, which was added in LLDB 19.The one exception i mentioned above replaces our
".*"regex that dumps everything throughlldb_lookup.synthetic_lookup. That wildcard also includes primitives which is less than ideal, especially for performance. It's bad enough that codelldb intercepts this command and replaces it with a type recognizer. If i removelldb_commands, codelldb can no longer do this. To prevent a regression on their end, I added a conditional that replicates that behavior.Here's the problem: for some godforsaken reason, if a struct contains a field with a
SyntheticProvider(even one that is "empty", like forDefaultSyntheticProviderfor primitives) it is formatted differently than a struct whose fields don't have providers. That breaks a bunch of the tests because instead of{ x = 10 y = 30 }we get(x = 10, y = 30). Very cool.So, we have divergent behavior depending on the version of LLDB. That's nothing new, since MSVC enums are broken prior to LLDB 18, so it's whatever (and the difference hardly matters to the end user). If the CI test runners have a new enough version of LLDB that it uses the type recognizer instead of the wildcard, the tests will fail. I'll update them and we'll be good to go. If they don't fail, I need to probably force a struct summary provider so that all versions look the same (which isn't ideal performance), or I can just wait until xcode happens to update to a newer version of LLDB.
try-job: aarch64-apple