Could we fix that, so the SmallVector formatter is only used for SmallVector objects, not pointers?

Merged in https://github.com/llvm/llvm-project/pull/66949

Thanks for doing this!

Redo ValueObjectDynamicValue::UpdateValue changes based on upstream testing

@Michael137 I'll wait a week before merging, in case any issues arise in your usage. These days I haven't been crossing paths with many DenseMap instances, so my beta testing has been zero.

Thanks, I will disable these for now, and see what can be done to address the issues we've seen.

@broadwaylamb hi, have you been using the PointerUnion formatter? We have seen a variety of issues, which don't seem to have easy fixes. If you're not using it, I will disable it. Alternatively, I propose creating a separate file that you and others could choose to import separately from lldbDataFormatters.py.

Add -e to expand DenseMap children

Change bool IsSwift() to LanguageType GetImplementationLanguage()

@bulbazord @augusto2112 hopefully this is a quick review.

Refactor for better API layering

Remove the DenseSet logic, which I had wrong

Fix range(N) to list(range(N))

• Add logic to recognize DenseSet, in which case all buckets are printed
• Change the summary to call out when a single tombstone is present in the children

Remove FUNCTION from FormatManager logs

Restore static_cast<void *>() because of -Wformat-pedantic

Include formatter kind ("format", "summary", "synthetic") to FormatManager logs

I just gave __PRETTY_FUNCTION__ a test drive, and it's a bit verbose/noisy: For example:

I wonder if we should hint in all 3 command objects (expr, frame var and DWIM) or if we should limit this to DWIM instead (since DWIM is the one aliased to p and po and I don't think vo or expr -O are often used unintentionally).

This was superseded by D145276.

Thanks to @jingham's help in identifying this issue, I have opened https://reviews.llvm.org/D153922 as a potential fix for the issue on macOS.

I will try to reproduce.

In D153648#4444898, @jingham wrote:

and that the one that won will indeed be in that list but will not be marked as a duplicate.

thanks!

+1 to a test

To expand the conversation, I have also opened D152031 which makes the same change to GetChildAtIndex.

correction: there's still an overload of GetChildAtNamePath, which takes a can_create value and passes it through to GetChildMemberWithName. However that function isn't used, and could be deleted. To delete the parameter, that overload of GetChildMemberWithName would need to be deleted too. In general, I'm still in favor of the conservative choice of giving it a default. Deleting it altogether is an easy follow up, if so desired.

That's an option too, which I considered. I went with this as a more
conservative change. If there's agreement to remove it then I can change it.

Change auto to StringRef