[Lldb-commits] [PATCH] D115277: [lldb] Workaround for type-like entities defined in a lexical block

[Kristina Bessonova via Phabricator via lldb-commits]

krisb added a comment.

In D115277#3178248 <https://reviews.llvm.org/D115277#3178248>, @jingham wrote:

> I worry this makes the case where a function has two definitions of the same type in one function a more confusing error than the "can't find type" error you would get without this patch.  Is this of sufficient urgency that we can't take the time to fix it correctly?

No urgency at all, I just believe it makes things a bit better than we have now.
And I want D113741 <https://reviews.llvm.org/D113741> gets relanded :)

Before D113741 <https://reviews.llvm.org/D113741> (which gets reverted because of the aforementioned issue in lldb), there was an almost the same behavior as we would have if both D113741 <https://reviews.llvm.org/D113741> and this patch applied.
I mean, before D113741 <https://reviews.llvm.org/D113741>, clang always put types to their parent subprogram scope, no matter where they were actually defined. So we got all the types defined within a particular function emitted in the same scope which is the subprogram.
As expected, if we had two types in the same name defined in the same function, lldb could't properly display information about this type. But there were/are no issues with displaying variables types for such a case.
Here is an example:

  int main() {
    int a = -1; 
    if (a > 0) {
      typedef int Int;
      Int local = a;
      return a * local;
    } else {
      typedef long Int;
      Int local = a;
      return a * local;
    }
  }

Even if in the beginning of main we can access 'Int' and lldb will always display as it 'int', never 'long':

  * thread #1, name = 'a.out', stop reason = breakpoint 1.1
      frame #0: 0x000000000040111b a.out`main at test_lldb.cpp:2:7
     1   	int main() {
  -> 2   	  int a = -1;
     3   	  if (a > 0) {
     4   	    typedef int Int;
     5   	    Int local = a;
     6   	    return a * local;
     7   	  } else {
  (lldb) image lookup -t Int
  Best match found in /home/kbessonova/workspace/llvm/llvm-project/build/a.out:
  id = {0x0000006c}, name = "Int", byte-size = 4, decl = test_lldb.cpp:4, compiler_type = "typedef Int"
       typedef 'Int': id = {0x000000a0}, name = "int", byte-size = 4, compiler_type = "int"

There are no issues with 'local':

  * thread #1, name = 'a.out', stop reason = step over
      frame #0: 0x0000000000401141 a.out`main at test_lldb.cpp:9:17
     6   	    return a * local;
     7   	  } else {
     8   	    typedef long Int;
  -> 9   	    Int local = a;
     10  	    return a * local;
     11  	  }
     12  	}
  (lldb) p local
  (Int) $0 = 4198432 + 0i

And in scripting mode we can see its proper type:

  (lldb) script
  Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
  >>> var = lldb.frame.FindVariable("local")
  >>> type = var.GetType()
  >>> print(type)
  typedef Int
  >>> print(type.GetCanonicalType())
  long

So 'before D113741 <https://reviews.llvm.org/D113741>' == ' D113741 <https://reviews.llvm.org/D113741> + D115277 <https://reviews.llvm.org/D115277>' with one difference: lldb would no longer report errors for variables which types are defined within a lexical block, which looks to me more valuable than having a proper type information from 'image lookup -t'.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D115277/new/

https://reviews.llvm.org/D115277