labath added a comment. In D65386#1605119 <https://reviews.llvm.org/D65386#1605119>, @JDevlieghere wrote:
> The current patch is fine I think and I think Pavel's suggestion sounds good, > as long as it's well documented. We could make that less magical by including the name of the "setter" method in the tablegen file instead of relying on some convention for deriving it from the setting name. Ideally, in the longer term, I think we shouldn't even need to generate the "SetOptionValue" method, as I think there should be a way to write a generic, non-generated piece of code which loops over available settings and calls the appropriate setter method. But that may be easier to achieve once there is a single source of truth for all "SetOptionValue" methods (i.e., tablegen). The thing I don't like about the enum approach is that it adds another layer to the option-setting code, whereas I think that the main problem is that the option-setting code has one too many layers already. Also, -1 to checking in generated code. Repository: rLLDB LLDB CHANGES SINCE LAST ACTION https://reviews.llvm.org/D65386/new/ https://reviews.llvm.org/D65386 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
