kuilpd wrote: > Apart from the pointer indexing question, this PR also opens the question of > "how should the numbers be represented". Here you represent them as > ValueObjects, which means you have to give them types, which means you have > to find a type system for them, ...
Why is that a bad thing? Can we do math operations later without types? Plus it's a unified interface, node evaluation returns a `ValueObject`. > I'm not sure I agree with how are those steps implemented (in fact, I'm > pretty sure I don't agree with at least some of those steps). In order to > keep this PR focused, and because a first-class number representation is not > necessary for replacing the current "frame var", my suggestion would be to > dumb down the implementation of `postfix_expression`: Instead of > `postfix_expression "[" expression "]"`, you could implement something like > `postfix_expression "[" integer "]"`. Then we can store the RHS of the `[]` > expression directly as a (u)int64 (or AP(S)Int, or whatever), and we can > completely sidestep the question its type. I mean... this works and is a basis for future patches, why remove something that we will have to bring back shortly afterwards? After replacing frame var, DIL will just have a little bit of extra capabilities, like using another variable as an index. > My reason for that is that I believe that after this is implemented (and > @cmtice finishes member access), we will be in a position to flip the flag on > this and make it the default -- which I think is the real proof of the > pudding, and I sort of expect we will need to tweak the implementation until > everything settles into place. I think it's better to not introduce > additional complexity while we're doing that. We still need to implement bit extraction that current `frame var` allows, which looks like this: `integer[4-8]`, another node we will have to re-implement later if we redo how numbers are stored now. https://github.com/llvm/llvm-project/pull/138551 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
