https://github.com/labath commented:
> The node will also have boolean literals and nullptr later, they are all > stored in a Scalar, so I don't think we should do 4 nodes for this. Why not? If all you needed was a single Scalar field that is handled uniformly, then sure. However, here you have a lot of additional data that only makes sense for a particular kind of literals. And if every use of these nodes is going to be followed by a switch on the literal type, then I don't think it saves much over declaring a separate class for each one. And it avoids questions like "what does is_floating_point() mean for a nullptr?" ... > I can add them in this PR as well. Let's not do that as that brings up the discussion about what to do with keywords. > We didn't really discuss how literals are parsed and stored, That's fine, that can be handled on the PR itself (i.e., here). > only the math and type promotion part, which I will get to in the next PR. That's the part I'm not sure about the consensus for, so I am going to ask someone else to review this as well. https://github.com/llvm/llvm-project/pull/152308 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
