[all-commits] [llvm/llvm-project] f6e056: [lldb] Add a test for how we lazily create Clang A...

[Raphael Isemann via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: f6e05672f6566a8d7efc4aed6473319e7115f979
      https://github.com/llvm/llvm-project/commit/f6e05672f6566a8d7efc4aed6473319e7115f979
  Author: Raphael Isemann <teemperor at gmail.com>
  Date:   2019-12-09 (Mon, 09 Dec 2019)

  Changed paths:
    A lldb/packages/Python/lldbsuite/test/functionalities/lazy-loading/Makefile
    A lldb/packages/Python/lldbsuite/test/functionalities/lazy-loading/TestLazyLoading.py
    A lldb/packages/Python/lldbsuite/test/functionalities/lazy-loading/main.cpp

  Log Message:
  -----------
  [lldb] Add a test for how we lazily create Clang AST nodes

Summary:
One of the ways we try to make LLDB faster is by only creating the Clang declarations (and loading the associated types)
when we actually need them for something. For example an evaluated expression might need to load types to
type check and codegen the expression.

Currently this mechanism isn't really tested, so we currently have no way to know how many Clang nodes we load and
when we load them. In general there seems to be some confusion when and why certain Clang nodes are created.
As we are about to make some changes to the code which is creating Clang AST nodes we probably should have
a test that at least checks that the current behaviour doesn't change. It also serves as some kind of documentation
on the current behaviour.

The test in this patch is just evaluating some expressions and checks which Clang nodes are created due to this in the
module AST. The check happens by looking at the AST dump of the current module and then scanning it for the
declarations we are looking for.

I'm aware that there are things missing in this test (inheritance, template parameters, non-expression evaluation commands)
but I'll expand it in follow up patches.

Also this test found two potential bugs in LLDB which are documented near the respective asserts in the test:

1. LLDB seems to always load all types of local variables even when we don't reference them in the expression. We had patches
that tried to prevent this but it seems that didn't work as well as it should have (even though we don't complete these
types).
2. We always seem to complete the first field of any record we run into. This has the funny side effect that LLDB is faster when
all classes in a project have an arbitrary `char unused;` as their first member. We probably want to fix this.

Reviewers: shafik

Subscribers: abidh, JDevlieghere, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D71056