Account for GetSyntheticValue failures#155737
Conversation
rustbot
added
the
S-waiting-on-review
|
rustbot has assigned @Mark-Simulacrum. Use Why was this reviewer chosen?The reviewer was selected based on:
|
|
|
||
| def get_child_index(self, name: str) -> int: | ||
| if self.is_ptr and name == "$$dereference$$": | ||
| if name == "$$dereference$$": |
There was a problem hiding this comment.
Question (non-blocking): Trying to better understand the synthethic provider relationships. Do we know why dereferences are handled I guess "directly" by DefaultSyntheticProvider, and not another *SyntheticProvider? Is it just because dereferences are very common?
There was a problem hiding this comment.
DefaultSyntheticProvider shouldnt ever encounter pointer types at all anymore, and its pointer logic was vestigial. Due to this check, all indirection should go through IndirectionSyntheticProvider.
Having an indirection provider fixes a number of issues that boil down to "none of our providers expect pointers to be passed in". Usually it's fine because LLDB propogates pointee children upwards as pointer children, but when we're doing things like inspecting the type's layout directly (e.g. enum variants) or a type's generic params, looking at the pointer type causes the logic to fail.
There's an alternative, iirc it's a flag on synthetics/summaries called lldb.eTypeOptionFrontendWantsDereference. I think it does what we want (forces only dereferenced/non-pointer entities passed to providers), but i need to test it and dig through the logic in LLDB to be sure.
$$dereference$$ is a special child name and LLDB uses it to allow operator * dereferencing and operator -> field access in the repl.
rust-bors
Bot
added
S-waiting-on-bors
Rollup of 7 pull requests Successful merges: - #155643 (Improve suggestion for $-prefixed fragment specifiers) - #154197 (Avoid redundant clone suggestions in borrowck diagnostics) - #154372 (Exposing Float Masks) - #155680 (Handle index projections in call destinations in DSE) - #155732 (bootstrap: Don't clone submodules unconditionally in dry-run) - #155737 (Account for `GetSyntheticValue` failures) - #155738 (Pass fields to `is_tuple_fields` instead of `SBValue` object)
4 participants
GetSyntheticValuereturns an invalidSBValueif 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//pull/155336 or similar lands. Additionally, codelldb subvertslldb_commandsto 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 beIndirectionSyntheticProvider, notDefaultSyntheticProvider.