[Lldb-commits] [lldb] [LLDB] Add type casting to DIL, part 1 of 3. (PR #165199)

[Ilia Kuklin via lldb-commits]

================
@@ -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