[Lldb-commits] [PATCH] D35036: switch on enum should be exhaustive and warning-free

penryu requested review of this revision. penryu added a comment. This revision is now accepted and ready to land. I need to learn more about the number formatters before I make more significant changes than those below. As written currently, it leaves the logic intact and resolves the warning.

[Lldb-commits] [PATCH] D35036: switch on enum should be exhaustive and warning-free

sas added a comment. Putting that check in an inline function instead of doing ad-hoc validation in the call-site seems better indeed. https://reviews.llvm.org/D35036 ___ lldb-commits mailing list lldb-commits@lists.llvm.org

[Lldb-commits] [PATCH] D35036: switch on enum should be exhaustive and warning-free

penryu added a comment. Thanks, sas. I'll be honest, my prefer solution involves an inlined function (uint64_t -> TypeCodes) that eliminates the cast from the NSNumberSummaryProvider() method altogether. This way we can handle any dirty mappings from raw memory directory to the enum within

[Lldb-commits] [PATCH] D35036: switch on enum should be exhaustive and warning-free

sas accepted this revision. sas added a comment. This revision is now accepted and ready to land. Looks like the numeric values of `TypeCode` are contiguous. It would probably be cleaner to a check after the cast to validate the value instead of having to add a line for each label in the

[Lldb-commits] [PATCH] D35036: switch on enum should be exhaustive and warning-free

penryu created this revision. Testing the value of type_code against the closed enum TypeCodes provides statically verifiable completeness of testing. However, one branch assigns to type_code by casting directly from a masked integer value. This is currently handled by adding a default: case