[lldb] Decouple importing the std C++ module from the way the program is compiled

Summary:
At the moment, when trying to import the `std` module in LLDB, we look at the imported modules used in the compiled program
and try to infer the Clang configuration we need from the DWARF module-import. That was the initial idea but turned out to
cause a few problems or inconveniences:

* It requires that users compile their programs with C++ modules. Given how experimental C++ modules are makes this feature inaccessible
for many users. Also it means that people can't just get the benefits of this feature for free when we activate it by default
(and we can't just close all the associated bug reports).
* Relying on DWARF's imported module tags (that are only emitted by default on macOS) means this can only be used when using DWARF (and with -glldb on Linux).
* We essentially hardcoded the C standard library paths on some platforms (Linux) or just couldn't support this feature on other platforms (macOS).

This patch drops the whole idea of looking at the imported module DWARF tags and instead just uses the support files of the compilation unit.
If we look at the support files and see file paths that indicate where the C standard library and libc++ are, we can just create the module
configuration this information. This fixes all the problems above which means we can enable all the tests now on Linux, macOS and with other debug information
than what we currently had. The only debug information specific code is now the iteration over external type module when -gmodules is used (as `std` and also the
`Darwin` module are their own external type module with their own files).

The meat of this patch is the CppModuleConfiguration which looks at the file paths from the compilation unit and then figures out the include paths
based on those paths. It's quite conservative in that it only enables modules if we find a single C library and single libc++ library. It's still missing some
test mode where we try to compile an expression before we actually activate the config for the user (which probably also needs some caching mechanism),
but for now it works and makes the feature usable.

Reviewers: aprantl, shafik, jdoerfert

Reviewed By: aprantl

Subscribers: mgorny, abidh, JDevlieghere, lldb-commits

Tags: #c_modules_in_lldb, #lldb

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

llvm-svn: 372716

1 files changed, 82 insertions, 0 deletions

diff --git a/lldb/source/Plugins/ExpressionParser/Clang/CppModuleConfiguration.cpp b/lldb/source/Plugins/ExpressionParser/Clang/CppModuleConfiguration.cpp
new file mode 100644
index 00000000000..47c0345d6a0
--- /dev/null
+++ b/lldb/source/Plugins/ExpressionParser/Clang/CppModuleConfiguration.cpp
@@ -0,0 +1,82 @@
+//===-- CppModuleConfiguration.cpp ----------------------------------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+#include "CppModuleConfiguration.h"
+
+#include "ClangHost.h"
+#include "lldb/Host/FileSystem.h"
+
+using namespace lldb_private;
+
+bool CppModuleConfiguration::SetOncePath::TrySet(llvm::StringRef path) {
+  // Setting for the first time always works.
+  if (m_first) {
+    m_path = path.str();
+    m_valid = true;
+    m_first = false;
+    return true;
+  }
+  // Changing the path to the same value is fine.
+  if (m_path == path)
+    return true;
+
+  // Changing the path after it was already set is not allowed.
+  m_valid = false;
+  return false;
+}
+
+bool CppModuleConfiguration::analyzeFile(const FileSpec &f) {
+  llvm::SmallString<256> dir_buffer = f.GetDirectory().GetStringRef();
+  // Convert to posix style so that we can use '/'.
+  llvm::sys::path::native(dir_buffer, llvm::sys::path::Style::posix);
+  llvm::StringRef posix_dir(dir_buffer);
+
+  // Check for /c++/vX/ that is used by libc++.
+  static llvm::Regex libcpp_regex(R"regex(/c[+][+]/v[0-9]/)regex");
+  if (libcpp_regex.match(f.GetPath())) {
+    // Strip away libc++'s /experimental directory if there is one.
+    posix_dir.consume_back("/experimental");
+    return m_std_inc.TrySet(posix_dir);
+  }
+
+  // Check for /usr/include. On Linux this might be /usr/include/bits, so
+  // we should remove that '/bits' suffix to get the actual include directory.
+  if (posix_dir.endswith("/usr/include/bits"))
+    posix_dir.consume_back("/bits");
+  if (posix_dir.endswith("/usr/include"))
+    return m_c_inc.TrySet(posix_dir);
+
+  // File wasn't interesting, continue analyzing.
+  return true;
+}
+
+bool CppModuleConfiguration::hasValidConfig() {
+  // We all these include directories to have a valid usable configuration.
+  return m_c_inc.Valid() && m_std_inc.Valid();
+}
+
+CppModuleConfiguration::CppModuleConfiguration(
+    const FileSpecList &support_files) {
+  // Analyze all files we were given to build the configuration.
+  bool error = !std::all_of(support_files.begin(), support_files.end(),
+                            std::bind(&CppModuleConfiguration::analyzeFile,
+                                      this, std::placeholders::_1));
+  // If we have a valid configuration at this point, set the
+  // include directories and module list that should be used.
+  if (!error && hasValidConfig()) {
+    // Calculate the resource directory for LLDB.
+    llvm::SmallString<256> resource_dir;
+    llvm::sys::path::append(resource_dir, GetClangResourceDir().GetPath(),
+                            "include");
+    m_resource_inc = resource_dir.str();
+
+    // This order matches the way Clang orders these directories.
+    m_include_dirs = {m_std_inc.Get(), m_resource_inc, m_c_inc.Get()};
+    m_imported_modules = {"std"};
+  }
+}