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

[via lldb-commits]

================
@@ -233,3 +259,17 @@ def test_type_cast(self):
         self.expect_var_path("((int*)arr_2d)[1]", type="int", value="2")
         self.expect_var_path("((int*)arr_2d)[2]", type="int", value="3")
         self.expect_var_path("((int*)arr_2d[1])[1]", type="int", value="5")
+
+        # Test casting to user-defined type with same name as variable.
+
+        self.expect_var_path("myStruct", type="myName")
+        self.expect_var_path("myName", type="int", value="37")
+
+        # Here 'myName' is treated as a variable, not a type, so '(myName)'
+        # is parsed as a variable expression and 'InnerFoo' is unexpected,
+        # and a type cast is not attempted.
+        self.expect(
+            "frame variable '(myName)InnerFoo'",
+            error=True,
+            substrs=["expected 'eof', got: <'InnerFoo' (identifier)>"],
----------------
cmtice wrote:

It's not that simple.  When the parser sees the token sequence left-parentheses, identifier, right-parenthesis, the identifier could validly either be a variable name or a type name. If it's a variable name, then the entire 3-token sequence is evaluated to be the variable. If any tokens follow, then they should be tokens that can reasonably follow a variable name, such as  '.', '->' '[...]', or an eof token. What the next immediate token cannot be is another identifier. However if the identifier in the first 3-token sequence is determined to be a type name, then an identifier is absolutely a valid next token.

In this particular case, the first identifier happens to be a valid name for both a type and a variable. In such cases we always choose the variable name over the type name. SO the parser decides that the first three tokens refer to a variable. At this point it moves on, remembering that it's holding a variable  but losing most of the previous context, and parses the next token and finds that it is not a valid token to come right after a variable, so we get an error message that basically says "I was expecting one type of token and I found the wrong token type -- invalid sequence".   At the point where this is generated the parser does not really have the context of the previously made decision, nor the knowledge that  the variable name (in the first three tokens) is also a valid type name. 

Having ParseTypeId always return an error message of it doesn't find a compiler type is not correct, because. e.g. '&(a)' is perfectly valid if 'a' is a variable, and we would expect ParseTypeId to return no compiler type. (Note "&((int)(b))" is also valid for DIL, so DIL always checks, when it sees a left parenthesis, to see if it's doing a type cast or not.)

All of this is a very long-winded way of saying I don't think we can really give you the error message you would like here.

https://github.com/llvm/llvm-project/pull/175061