[Lldb-commits] [PATCH] D81561: [lldb] Add basic -flimit-debug-info support to expression evaluator

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

In D81561#2086435 <https://reviews.llvm.org/D81561#2086435>, @clayborg wrote:

> If we run into a class in the AST importer that was forcefully completed and we can't find a better definition, what do we do? Error out? Do what we did. I would like there to be a nice log line in the "log enable lldb expr" to tell us when this happens so we can know why an expression is failing if we don't emit an error and stop the expression.


We do what we did previously -- import the empty class. The included test case exercises this scenario as well.

I'll print a log message when that happens.

> Also, for "frame variable" and the any ValueObject objects, we can easily see what a BaseClass is marked as forcefully completed and just do a simple type search for the type given a full decl context as context and substitute the type. That won't use any of this code, it will just need to know to grab the the full type from the target by doing a search. We could make a function similar to CompilerType::GetCompleteType() that takes a target so that it can search all of the modules in a target for a type.

Yes, that's the rough idea, but I haven't tried implementing it yet.

In D81561#2086580 <https://reviews.llvm.org/D81561#2086580>, @aprantl wrote:

> It's great to see this being addressed! I have a high-level question: When completing types across lldb::Modules — in which ASTContext is the complete type created? Since a per-module TypeSystem can be shared by many debuggers, I want to make sure that types from another module don't pollute another module's ASTContext, and that they are created in the/a scratch context instead.


Apart from the adding the "forcefully completed" flag, this solution does not change the contents of module ASTs in any way. If we take the example in the test case, the individual modules ASTs would look something like:
libone:

  struct One {
    int one;
  };

libtwo:

  struct [[forcefully_completed]] One { };
  struct Two : One {
    int two;
  };

a.out:

  struct [[forcefully_completed]] One { };
  struct [[forcefully_completed]] Two { };
  struct InheritsFromOne: One {
    int member;
  };
  ...

When importing into the expression AST, we pick the best representation for each of the types and create a merged class. I'm not entirely sure what happens when importing this into the AST for persistent expression results (what's the name for that?). Ideally the merged type would be imported there too, but I am not sure if that actually happens right now -- `expr inherits_from_one.one` works, but a plain `expr inherits_from_one` just displays the `member` member. I'm not yet sure if this is simply due to lack of support in the "frame variable" machinery which is supposed to display the result, or if there is some more importing that needs to happen.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81561