[Lldb-commits] [PATCH] D11482: Add target setting to have the language follow the frame's CU.

[Greg Clayton]

clayborg added a comment.

So we accurately set the

In http://reviews.llvm.org/D11482#211941, @dawn wrote:

> Thank you for your review.  I was afraid you might not go for it since you objected to my original frame-based patch for breakpoints, but I had hoped that by having it in an option you would be OK with it. Our users (with mixed Pascal and C++ code) really want this so they don't have to remember to specify the language each time they go up or down the stack and want to view their local variables.  Consider this scenario:
>
> Suppose a user hits a breakpoint in a Pascal function called from C++ and sets the target language to Pascal so that they can evaluate their locals using the Pascal FE.  Now they go up a frame into C++ and try to see their locals but can't without resetting the target language (or by always specifying the expr --language option).  Then they run to a BP in a C++ module, same problem.
>
> Does this help explain why having such a default would be so desirable?  It is how all our debuggers and gdb work.  I'm curious - how do you get around this problem in Swift?


We know the language of each frame because of DWARF and we "do the right thing" automatically. Having the user have to do anything (set target.language, or any other setting) is the wrong approach.

For Swift, we have modified ClangASTType to contain a pointer union where there is a "clang::ASTContext *" and a "swift::ASTContext *" and still a "void *" that represents the type. All function calls inside the ClangASTType class then have code like:

  if (IsClangType())
  {
      // clang::ASTContext specific code
  }
  else if (IsSwiftType())
  {
      // clang::ASTContext specific code
  }
  
  Then no changes need to be done to any code that displays the types because the API of ClangASTContext takes care of things. 
  
  For expressions we detect the language from the frame (if a language wasn't specified with an option) and we use either the clang based expression parser or the Swift one based on the language.
  
  So any solution must:
  - not require intervention from the user in any way (no settings, or any other options on command) when switching frames
  - Evaluating expressions can use the current frame's language
  - breakpoints, if the language isn't specified, should just do the right thing and set the breakpoint in all languages
  
  Questions:
  - So does pascal have a native llvm/clang type system that isn't in the clang namespace?
  - Does pascal use types created in a clang::ASTContext or doesn't it have its own type system?
  - Does pascal use the clang expression parser or a native one?


Repository:
  rL LLVM

http://reviews.llvm.org/D11482