================
@@ -339,6 +463,40 @@ std::string DILParser::ParseUnqualifiedId() {
return identifier;
}
+CompilerType
+DILParser::ResolveTypeDeclarators(CompilerType type,
+ const std::vector<Token> &ptr_operators) {
+ CompilerType bad_type;
+ // Resolve pointers/references.
+ for (Token tk : ptr_operators) {
+ uint32_t loc = tk.GetLocation();
+ if (tk.GetKind() == Token::star) {
+ // Pointers to reference types are forbidden.
+ if (type.IsReferenceType()) {
+ BailOut(llvm::formatv("'type name' declared as a pointer to a "
+ "reference of type {0}",
+ type.TypeDescription()),
+ loc, CurToken().GetSpelling().length());
+ return bad_type;
+ }
----------------
kuilpd wrote:
> > But in general, this is a C-style cast with C-style syntax, I think it
> > should be expected to be used only with C/C++ code, since DIL will be
> > mostly used automatically without the programmer knowing that DIL will try
> > to evaluate the expression before the compiler.
> But isn't DIL supposed to be the de-facto inspection language? Regardless of
> what language you're debugging. Yes it follows mostly C/C++ syntax but here
> you are checking explicitly C++ language semantics, not just syntax.
> It is the intention of the DIL to be the general introspection language. We
> should try to make it useable to people who aren't just debugging C but the
> overall idea is that most people are familiar with C so making the syntax
> look C-ish is a good way to achieve that goal. Remember that this is not the
> expression parser, whose job it is to capture all the subtleties of any given
> language. This is primarily a way to examine data values.
@Michael137 @jimingham
What I meant to say is that considering how we're integrating DIL into LLDB,
most people won't even know that DIL exists. We just replaced the
implementation of `frame var` with DIL and made people use it without realizing
it. And this implementation is used as a first attempt in evaluating
expressions when using an IDE via lldb-dap (for example), so people will be
just writing expressions in the language that they're debugging.
So, on the one hand, what's the point going out of the way supporting C-style
cast on languages with different reference symbol, or no explicit references at
all (like Swift, if I understand correctly)? For someone to do this, they would
need to know about DIL and to know that it is allowed to replace a reference
symbol `&` with something else specifically in a C-style cast. On the other
hand, the debugged code could be a mixture of C++ and Swift objects, so maybe
this could be useful to have anyway. I'm really not sure, I thought we could
eventually just support different syntax constructions from different languages
which underneath could do the same thing, or at least very similar ones. For
example, having both a C-style cast and a keyword `as` for Swift and Rust,
which is why I also suggested to keep the name "CStyleCastNode" in the code.
This hasn't really come up in any meetings about DIL afaik, so maybe we need to
discuss this at some point.
But for now it's probably a good idea anyway to check pointer/reference
operators during evaluation, although disallowing reference to pointer and
reference to reference is exclusive to this cast. Normally, we can do that, so
existing type system functions like `GetPointerType` won't work here.
https://github.com/llvm/llvm-project/pull/165199
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
