maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lldb/unittests/Expression/CppModuleConfigurationTest.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

303 lines
12 KiB
C++
Raw Normal View History

[lldb][NFC] Fix all formatting errors in .cpp file headers Summary: A *.cpp file header in LLDB (and in LLDB) should like this: ``` //===-- TestUtilities.cpp -------------------------------------------------===// ``` However in LLDB most of our source files have arbitrary changes to this format and these changes are spreading through LLDB as folks usually just use the existing source files as templates for their new files (most notably the unnecessary editor language indicator `-*- C++ -*-` is spreading and in every review someone is pointing out that this is wrong, resulting in people pointing out that this is done in the same way in other files). This patch removes most of these inconsistencies including the editor language indicators, all the different missing/additional '-' characters, files that center the file name, missing trailing `===//` (mostly caused by clang-format breaking the line). Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere Reviewed By: JDevlieghere Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D73258
2020-01-24 15:23:27 +08:00
//===-- CppModuleConfigurationTest.cpp ------------------------------------===//
[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
2019-09-24 18:08:18 +08:00
//
// 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 "Plugins/ExpressionParser/Clang/CppModuleConfiguration.h"
#include "Plugins/ExpressionParser/Clang/ClangHost.h"
[lldb] Add a SubsystemRAII that takes care of calling Initialize and Terminate in the unit tests Summary: Many of our tests need to initialize certain subsystems/plugins of LLDB such as `FileSystem` or `HostInfo` by calling their static `Initialize` functions before the test starts and then calling `::Terminate` after the test is done (in reverse order). This adds a lot of error-prone boilerplate code to our testing code. This patch adds a RAII called SubsystemRAII that ensures that we always call ::Initialize and then call ::Terminate after the test is done (and that the Terminate calls are always in the reverse order of the ::Initialize calls). It also gets rid of all of the boilerplate that we had for these calls. Per-fixture initialization is still not very nice with this approach as it would require some kind of static unique_ptr that gets manually assigned/reseted from the gtest SetUpTestCase/TearDownTestCase functions. Because of that I changed all per-fixture setup to now do per-test setup which can be done by just having the SubsystemRAII as a member of the test fixture. This change doesn't influence our normal test runtime as LIT anyway runs each test case separately (and the Initialize/Terminate calls are anyway not very expensive). It will however make running all tests in a single executable slightly slower. Reviewers: labath, JDevlieghere, martong, espindola, shafik Reviewed By: labath Subscribers: mgorny, rnkovacs, emaste, MaskRay, abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71630
2019-12-23 17:38:12 +08:00
#include "TestingSupport/SubsystemRAII.h"
[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
2019-09-24 18:08:18 +08:00
#include "lldb/Host/FileSystem.h"
#include "lldb/Host/HostInfo.h"
#include "gmock/gmock.h"
#include "gtest/gtest.h"
using namespace lldb_private;
namespace {
struct CppModuleConfigurationTest : public testing::Test {
[lldb][import-std-module] Do some basic file checks before trying to import a module Currently when LLDB has enough data in the debug information to import the `std` module, it will just try to import it. However when debugging libraries where the sources aren't available anymore, importing the module will generate a confusing diagnostic that the module couldn't be built. For the fallback mode (where we retry failed expressions with the loaded module), this will cause the second expression to fail with a module built error instead of the actual parsing issue in the user expression. This patch adds checks that ensures that we at least have any source files in the found include paths before we try to import the module. This prevents the module from being loaded in the situation described above which means we don't emit the bogus 'can't import module' diagnostic and also don't waste any time retrying the expression in the fallback mode. For the unit tests I did some refactoring as they now require a VFS with the files in it and not just the paths. The Python test just builds a binary with a fake C++ module, then deletes the module before debugging. Fixes rdar://73264458 Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D95096
2021-01-21 19:05:59 +08:00
llvm::MemoryBufferRef m_empty_buffer;
llvm::IntrusiveRefCntPtr<llvm::vfs::InMemoryFileSystem> m_fs;
CppModuleConfigurationTest()
: m_empty_buffer("", "<empty buffer>"),
m_fs(new llvm::vfs::InMemoryFileSystem()) {}
void SetUp() override {
FileSystem::Initialize(m_fs);
HostInfo::Initialize();
}
void TearDown() override {
HostInfo::Terminate();
FileSystem::Terminate();
}
/// Utility function turning a list of paths into a FileSpecList.
FileSpecList makeFiles(llvm::ArrayRef<std::string> paths) {
FileSpecList result;
for (const std::string &path : paths) {
result.Append(FileSpec(path, FileSpec::Style::posix));
if (!m_fs->addFileNoOwn(path, static_cast<time_t>(0), m_empty_buffer))
llvm_unreachable("Invalid test configuration?");
}
return result;
}
[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
2019-09-24 18:08:18 +08:00
};
} // namespace
/// Returns the Clang resource include directory.
static std::string ResourceInc() {
llvm::SmallString<256> resource_dir;
llvm::sys::path::append(resource_dir, GetClangResourceDir().GetPath(),
"include");
[lldb] Replace SmallStr.str().str() with std::string conversion operator. Use the std::string conversion operator introduced in d7049213d0fcda691c9e79f9b41e357198d99738. The SmallString in the log statement doesn't require conversion at all when using the variadic log macro.
2020-01-30 13:33:37 +08:00
return std::string(resource_dir);
[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
2019-09-24 18:08:18 +08:00
}
TEST_F(CppModuleConfigurationTest, Linux) {
// Test the average Linux configuration.
[lldb][import-std-module] Do some basic file checks before trying to import a module Currently when LLDB has enough data in the debug information to import the `std` module, it will just try to import it. However when debugging libraries where the sources aren't available anymore, importing the module will generate a confusing diagnostic that the module couldn't be built. For the fallback mode (where we retry failed expressions with the loaded module), this will cause the second expression to fail with a module built error instead of the actual parsing issue in the user expression. This patch adds checks that ensures that we at least have any source files in the found include paths before we try to import the module. This prevents the module from being loaded in the situation described above which means we don't emit the bogus 'can't import module' diagnostic and also don't waste any time retrying the expression in the fallback mode. For the unit tests I did some refactoring as they now require a VFS with the files in it and not just the paths. The Python test just builds a binary with a fake C++ module, then deletes the module before debugging. Fixes rdar://73264458 Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D95096
2021-01-21 19:05:59 +08:00
[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
2019-09-24 18:08:18 +08:00
std::string usr = "/usr/include";
[lldb][import-std-module] Do some basic file checks before trying to import a module Currently when LLDB has enough data in the debug information to import the `std` module, it will just try to import it. However when debugging libraries where the sources aren't available anymore, importing the module will generate a confusing diagnostic that the module couldn't be built. For the fallback mode (where we retry failed expressions with the loaded module), this will cause the second expression to fail with a module built error instead of the actual parsing issue in the user expression. This patch adds checks that ensures that we at least have any source files in the found include paths before we try to import the module. This prevents the module from being loaded in the situation described above which means we don't emit the bogus 'can't import module' diagnostic and also don't waste any time retrying the expression in the fallback mode. For the unit tests I did some refactoring as they now require a VFS with the files in it and not just the paths. The Python test just builds a binary with a fake C++ module, then deletes the module before debugging. Fixes rdar://73264458 Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D95096
2021-01-21 19:05:59 +08:00
std::string libcpp = "/usr/include/c++/v1";
std::vector<std::string> files = {// C library
usr + "/stdio.h",
// C++ library
libcpp + "/vector",
libcpp + "/module.modulemap"};
[LLDB] Provide target specific directories to libclang On Linux some C++ and C include files reside in target specific directories, like /usr/include/x86_64-linux-gnu. Patch adds them to libclang, so LLDB jitter has more chances to compile expression. OS Laboratory. Huawei Russian Research Institute. Saint-Petersburg Reviewed By: teemperor Differential Revision: https://reviews.llvm.org/D110827
2021-11-26 02:27:02 +08:00
CppModuleConfiguration config(makeFiles(files), llvm::Triple());
[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
2019-09-24 18:08:18 +08:00
EXPECT_THAT(config.GetImportedModules(), testing::ElementsAre("std"));
EXPECT_THAT(config.GetIncludeDirs(),
testing::ElementsAre(libcpp, ResourceInc(), usr));
}
[LLDB] Provide target specific directories to libclang On Linux some C++ and C include files reside in target specific directories, like /usr/include/x86_64-linux-gnu. Patch adds them to libclang, so LLDB jitter has more chances to compile expression. OS Laboratory. Huawei Russian Research Institute. Saint-Petersburg Reviewed By: teemperor Differential Revision: https://reviews.llvm.org/D110827
2021-11-26 02:27:02 +08:00
TEST_F(CppModuleConfigurationTest, LinuxTargetSpecificInclude) {
// Test the average Linux configuration.
std::string usr = "/usr/include";
std::string usr_target = "/usr/include/x86_64-linux-gnu";
std::string libcpp = "/usr/include/c++/v1";
std::string libcpp_target = "/usr/include/x86_64-unknown-linux-gnu/c++/v1";
std::vector<std::string> files = {
// C library
usr + "/stdio.h", usr_target + "/sys/cdefs.h",
// C++ library
libcpp + "/vector", libcpp + "/module.modulemap"};
CppModuleConfiguration config(makeFiles(files),
llvm::Triple("x86_64-unknown-linux-gnu"));
EXPECT_THAT(config.GetImportedModules(), testing::ElementsAre("std"));
EXPECT_THAT(config.GetIncludeDirs(),
testing::ElementsAre(libcpp, ResourceInc(), usr, usr_target,
libcpp_target));
}
[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
2019-09-24 18:08:18 +08:00
TEST_F(CppModuleConfigurationTest, Sysroot) {
// Test that having a sysroot for the whole system works fine.
[lldb][import-std-module] Do some basic file checks before trying to import a module Currently when LLDB has enough data in the debug information to import the `std` module, it will just try to import it. However when debugging libraries where the sources aren't available anymore, importing the module will generate a confusing diagnostic that the module couldn't be built. For the fallback mode (where we retry failed expressions with the loaded module), this will cause the second expression to fail with a module built error instead of the actual parsing issue in the user expression. This patch adds checks that ensures that we at least have any source files in the found include paths before we try to import the module. This prevents the module from being loaded in the situation described above which means we don't emit the bogus 'can't import module' diagnostic and also don't waste any time retrying the expression in the fallback mode. For the unit tests I did some refactoring as they now require a VFS with the files in it and not just the paths. The Python test just builds a binary with a fake C++ module, then deletes the module before debugging. Fixes rdar://73264458 Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D95096
2021-01-21 19:05:59 +08:00
[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
2019-09-24 18:08:18 +08:00
std::string libcpp = "/home/user/sysroot/usr/include/c++/v1";
std::string usr = "/home/user/sysroot/usr/include";
[lldb][import-std-module] Do some basic file checks before trying to import a module Currently when LLDB has enough data in the debug information to import the `std` module, it will just try to import it. However when debugging libraries where the sources aren't available anymore, importing the module will generate a confusing diagnostic that the module couldn't be built. For the fallback mode (where we retry failed expressions with the loaded module), this will cause the second expression to fail with a module built error instead of the actual parsing issue in the user expression. This patch adds checks that ensures that we at least have any source files in the found include paths before we try to import the module. This prevents the module from being loaded in the situation described above which means we don't emit the bogus 'can't import module' diagnostic and also don't waste any time retrying the expression in the fallback mode. For the unit tests I did some refactoring as they now require a VFS with the files in it and not just the paths. The Python test just builds a binary with a fake C++ module, then deletes the module before debugging. Fixes rdar://73264458 Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D95096
2021-01-21 19:05:59 +08:00
std::vector<std::string> files = {// C library
usr + "/stdio.h",
// C++ library
libcpp + "/vector",
libcpp + "/module.modulemap"};
[LLDB] Provide target specific directories to libclang On Linux some C++ and C include files reside in target specific directories, like /usr/include/x86_64-linux-gnu. Patch adds them to libclang, so LLDB jitter has more chances to compile expression. OS Laboratory. Huawei Russian Research Institute. Saint-Petersburg Reviewed By: teemperor Differential Revision: https://reviews.llvm.org/D110827
2021-11-26 02:27:02 +08:00
CppModuleConfiguration config(makeFiles(files), llvm::Triple());
[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
2019-09-24 18:08:18 +08:00
EXPECT_THAT(config.GetImportedModules(), testing::ElementsAre("std"));
EXPECT_THAT(config.GetIncludeDirs(),
testing::ElementsAre(libcpp, ResourceInc(), usr));
}
TEST_F(CppModuleConfigurationTest, LinuxLocalLibCpp) {
// Test that a locally build libc++ is detected.
[lldb][import-std-module] Do some basic file checks before trying to import a module Currently when LLDB has enough data in the debug information to import the `std` module, it will just try to import it. However when debugging libraries where the sources aren't available anymore, importing the module will generate a confusing diagnostic that the module couldn't be built. For the fallback mode (where we retry failed expressions with the loaded module), this will cause the second expression to fail with a module built error instead of the actual parsing issue in the user expression. This patch adds checks that ensures that we at least have any source files in the found include paths before we try to import the module. This prevents the module from being loaded in the situation described above which means we don't emit the bogus 'can't import module' diagnostic and also don't waste any time retrying the expression in the fallback mode. For the unit tests I did some refactoring as they now require a VFS with the files in it and not just the paths. The Python test just builds a binary with a fake C++ module, then deletes the module before debugging. Fixes rdar://73264458 Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D95096
2021-01-21 19:05:59 +08:00
[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
2019-09-24 18:08:18 +08:00
std::string usr = "/usr/include";
[lldb][import-std-module] Do some basic file checks before trying to import a module Currently when LLDB has enough data in the debug information to import the `std` module, it will just try to import it. However when debugging libraries where the sources aren't available anymore, importing the module will generate a confusing diagnostic that the module couldn't be built. For the fallback mode (where we retry failed expressions with the loaded module), this will cause the second expression to fail with a module built error instead of the actual parsing issue in the user expression. This patch adds checks that ensures that we at least have any source files in the found include paths before we try to import the module. This prevents the module from being loaded in the situation described above which means we don't emit the bogus 'can't import module' diagnostic and also don't waste any time retrying the expression in the fallback mode. For the unit tests I did some refactoring as they now require a VFS with the files in it and not just the paths. The Python test just builds a binary with a fake C++ module, then deletes the module before debugging. Fixes rdar://73264458 Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D95096
2021-01-21 19:05:59 +08:00
std::string libcpp = "/home/user/llvm-build/include/c++/v1";
std::vector<std::string> files = {// C library
usr + "/stdio.h",
// C++ library
libcpp + "/vector",
libcpp + "/module.modulemap"};
[LLDB] Provide target specific directories to libclang On Linux some C++ and C include files reside in target specific directories, like /usr/include/x86_64-linux-gnu. Patch adds them to libclang, so LLDB jitter has more chances to compile expression. OS Laboratory. Huawei Russian Research Institute. Saint-Petersburg Reviewed By: teemperor Differential Revision: https://reviews.llvm.org/D110827
2021-11-26 02:27:02 +08:00
CppModuleConfiguration config(makeFiles(files), llvm::Triple());
[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
2019-09-24 18:08:18 +08:00
EXPECT_THAT(config.GetImportedModules(), testing::ElementsAre("std"));
EXPECT_THAT(config.GetIncludeDirs(),
testing::ElementsAre(libcpp, ResourceInc(), usr));
}
TEST_F(CppModuleConfigurationTest, UnrelatedLibrary) {
// Test that having an unrelated library in /usr/include doesn't break.
[lldb][import-std-module] Do some basic file checks before trying to import a module Currently when LLDB has enough data in the debug information to import the `std` module, it will just try to import it. However when debugging libraries where the sources aren't available anymore, importing the module will generate a confusing diagnostic that the module couldn't be built. For the fallback mode (where we retry failed expressions with the loaded module), this will cause the second expression to fail with a module built error instead of the actual parsing issue in the user expression. This patch adds checks that ensures that we at least have any source files in the found include paths before we try to import the module. This prevents the module from being loaded in the situation described above which means we don't emit the bogus 'can't import module' diagnostic and also don't waste any time retrying the expression in the fallback mode. For the unit tests I did some refactoring as they now require a VFS with the files in it and not just the paths. The Python test just builds a binary with a fake C++ module, then deletes the module before debugging. Fixes rdar://73264458 Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D95096
2021-01-21 19:05:59 +08:00
[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
2019-09-24 18:08:18 +08:00
std::string usr = "/usr/include";
[lldb][import-std-module] Do some basic file checks before trying to import a module Currently when LLDB has enough data in the debug information to import the `std` module, it will just try to import it. However when debugging libraries where the sources aren't available anymore, importing the module will generate a confusing diagnostic that the module couldn't be built. For the fallback mode (where we retry failed expressions with the loaded module), this will cause the second expression to fail with a module built error instead of the actual parsing issue in the user expression. This patch adds checks that ensures that we at least have any source files in the found include paths before we try to import the module. This prevents the module from being loaded in the situation described above which means we don't emit the bogus 'can't import module' diagnostic and also don't waste any time retrying the expression in the fallback mode. For the unit tests I did some refactoring as they now require a VFS with the files in it and not just the paths. The Python test just builds a binary with a fake C++ module, then deletes the module before debugging. Fixes rdar://73264458 Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D95096
2021-01-21 19:05:59 +08:00
std::string libcpp = "/home/user/llvm-build/include/c++/v1";
std::vector<std::string> files = {// C library
usr + "/stdio.h",
// unrelated library
usr + "/boost/vector",
// C++ library
libcpp + "/vector",
libcpp + "/module.modulemap"};
[LLDB] Provide target specific directories to libclang On Linux some C++ and C include files reside in target specific directories, like /usr/include/x86_64-linux-gnu. Patch adds them to libclang, so LLDB jitter has more chances to compile expression. OS Laboratory. Huawei Russian Research Institute. Saint-Petersburg Reviewed By: teemperor Differential Revision: https://reviews.llvm.org/D110827
2021-11-26 02:27:02 +08:00
CppModuleConfiguration config(makeFiles(files), llvm::Triple());
[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
2019-09-24 18:08:18 +08:00
EXPECT_THAT(config.GetImportedModules(), testing::ElementsAre("std"));
EXPECT_THAT(config.GetIncludeDirs(),
testing::ElementsAre(libcpp, ResourceInc(), usr));
}
[LLDB] Provide target specific directories to libclang On Linux some C++ and C include files reside in target specific directories, like /usr/include/x86_64-linux-gnu. Patch adds them to libclang, so LLDB jitter has more chances to compile expression. OS Laboratory. Huawei Russian Research Institute. Saint-Petersburg Reviewed By: teemperor Differential Revision: https://reviews.llvm.org/D110827
2021-11-26 02:27:02 +08:00
TEST_F(CppModuleConfigurationTest, UnrelatedLibraryWithTargetSpecificInclude) {
// Test that having an unrelated library in /usr/include doesn't break.
std::string usr = "/usr/include";
std::string libcpp = "/home/user/llvm-build/include/c++/v1";
std::string libcpp_target =
"/home/user/llvm-build/include/x86_64-unknown-linux-gnu/c++/v1";
std::vector<std::string> files = {// C library
usr + "/stdio.h",
// unrelated library
usr + "/boost/vector",
// C++ library
libcpp + "/vector",
libcpp + "/module.modulemap"};
CppModuleConfiguration config(makeFiles(files),
llvm::Triple("x86_64-unknown-linux-gnu"));
EXPECT_THAT(config.GetImportedModules(), testing::ElementsAre("std"));
EXPECT_THAT(config.GetIncludeDirs(),
testing::ElementsAre(libcpp, ResourceInc(), usr, libcpp_target));
}
[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
2019-09-24 18:08:18 +08:00
TEST_F(CppModuleConfigurationTest, Xcode) {
// Test detection of libc++ coming from Xcode with generic platform names.
[lldb][import-std-module] Do some basic file checks before trying to import a module Currently when LLDB has enough data in the debug information to import the `std` module, it will just try to import it. However when debugging libraries where the sources aren't available anymore, importing the module will generate a confusing diagnostic that the module couldn't be built. For the fallback mode (where we retry failed expressions with the loaded module), this will cause the second expression to fail with a module built error instead of the actual parsing issue in the user expression. This patch adds checks that ensures that we at least have any source files in the found include paths before we try to import the module. This prevents the module from being loaded in the situation described above which means we don't emit the bogus 'can't import module' diagnostic and also don't waste any time retrying the expression in the fallback mode. For the unit tests I did some refactoring as they now require a VFS with the files in it and not just the paths. The Python test just builds a binary with a fake C++ module, then deletes the module before debugging. Fixes rdar://73264458 Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D95096
2021-01-21 19:05:59 +08:00
[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
2019-09-24 18:08:18 +08:00
std::string p = "/Applications/Xcode.app/Contents/Developer/";
std::string libcpp = p + "Toolchains/B.xctoolchain/usr/include/c++/v1";
std::string usr =
p + "Platforms/A.platform/Developer/SDKs/OSVers.sdk/usr/include";
[lldb][import-std-module] Do some basic file checks before trying to import a module Currently when LLDB has enough data in the debug information to import the `std` module, it will just try to import it. However when debugging libraries where the sources aren't available anymore, importing the module will generate a confusing diagnostic that the module couldn't be built. For the fallback mode (where we retry failed expressions with the loaded module), this will cause the second expression to fail with a module built error instead of the actual parsing issue in the user expression. This patch adds checks that ensures that we at least have any source files in the found include paths before we try to import the module. This prevents the module from being loaded in the situation described above which means we don't emit the bogus 'can't import module' diagnostic and also don't waste any time retrying the expression in the fallback mode. For the unit tests I did some refactoring as they now require a VFS with the files in it and not just the paths. The Python test just builds a binary with a fake C++ module, then deletes the module before debugging. Fixes rdar://73264458 Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D95096
2021-01-21 19:05:59 +08:00
std::vector<std::string> files = {
// C library
usr + "/stdio.h",
// C++ library
libcpp + "/vector",
libcpp + "/module.modulemap",
};
[LLDB] Provide target specific directories to libclang On Linux some C++ and C include files reside in target specific directories, like /usr/include/x86_64-linux-gnu. Patch adds them to libclang, so LLDB jitter has more chances to compile expression. OS Laboratory. Huawei Russian Research Institute. Saint-Petersburg Reviewed By: teemperor Differential Revision: https://reviews.llvm.org/D110827
2021-11-26 02:27:02 +08:00
CppModuleConfiguration config(makeFiles(files), llvm::Triple());
[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
2019-09-24 18:08:18 +08:00
EXPECT_THAT(config.GetImportedModules(), testing::ElementsAre("std"));
EXPECT_THAT(config.GetIncludeDirs(),
testing::ElementsAre(libcpp, ResourceInc(), usr));
}
TEST_F(CppModuleConfigurationTest, LibCppV2) {
// Test that a "v2" of libc++ is still correctly detected.
[lldb][import-std-module] Do some basic file checks before trying to import a module Currently when LLDB has enough data in the debug information to import the `std` module, it will just try to import it. However when debugging libraries where the sources aren't available anymore, importing the module will generate a confusing diagnostic that the module couldn't be built. For the fallback mode (where we retry failed expressions with the loaded module), this will cause the second expression to fail with a module built error instead of the actual parsing issue in the user expression. This patch adds checks that ensures that we at least have any source files in the found include paths before we try to import the module. This prevents the module from being loaded in the situation described above which means we don't emit the bogus 'can't import module' diagnostic and also don't waste any time retrying the expression in the fallback mode. For the unit tests I did some refactoring as they now require a VFS with the files in it and not just the paths. The Python test just builds a binary with a fake C++ module, then deletes the module before debugging. Fixes rdar://73264458 Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D95096
2021-01-21 19:05:59 +08:00
std::string libcpp = "/usr/include/c++/v2";
std::vector<std::string> files = {// C library
"/usr/include/stdio.h",
// C++ library
libcpp + "/vector",
libcpp + "/module.modulemap"};
[LLDB] Provide target specific directories to libclang On Linux some C++ and C include files reside in target specific directories, like /usr/include/x86_64-linux-gnu. Patch adds them to libclang, so LLDB jitter has more chances to compile expression. OS Laboratory. Huawei Russian Research Institute. Saint-Petersburg Reviewed By: teemperor Differential Revision: https://reviews.llvm.org/D110827
2021-11-26 02:27:02 +08:00
CppModuleConfiguration config(makeFiles(files), llvm::Triple());
[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
2019-09-24 18:08:18 +08:00
EXPECT_THAT(config.GetImportedModules(), testing::ElementsAre("std"));
EXPECT_THAT(config.GetIncludeDirs(),
testing::ElementsAre("/usr/include/c++/v2", ResourceInc(),
"/usr/include"));
}
TEST_F(CppModuleConfigurationTest, UnknownLibCppFile) {
// Test that having some unknown file in the libc++ path doesn't break
// anything.
[lldb][import-std-module] Do some basic file checks before trying to import a module Currently when LLDB has enough data in the debug information to import the `std` module, it will just try to import it. However when debugging libraries where the sources aren't available anymore, importing the module will generate a confusing diagnostic that the module couldn't be built. For the fallback mode (where we retry failed expressions with the loaded module), this will cause the second expression to fail with a module built error instead of the actual parsing issue in the user expression. This patch adds checks that ensures that we at least have any source files in the found include paths before we try to import the module. This prevents the module from being loaded in the situation described above which means we don't emit the bogus 'can't import module' diagnostic and also don't waste any time retrying the expression in the fallback mode. For the unit tests I did some refactoring as they now require a VFS with the files in it and not just the paths. The Python test just builds a binary with a fake C++ module, then deletes the module before debugging. Fixes rdar://73264458 Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D95096
2021-01-21 19:05:59 +08:00
std::string libcpp = "/usr/include/c++/v1";
std::vector<std::string> files = {// C library
"/usr/include/stdio.h",
// C++ library
libcpp + "/non_existing_file",
libcpp + "/module.modulemap",
libcpp + "/vector"};
[LLDB] Provide target specific directories to libclang On Linux some C++ and C include files reside in target specific directories, like /usr/include/x86_64-linux-gnu. Patch adds them to libclang, so LLDB jitter has more chances to compile expression. OS Laboratory. Huawei Russian Research Institute. Saint-Petersburg Reviewed By: teemperor Differential Revision: https://reviews.llvm.org/D110827
2021-11-26 02:27:02 +08:00
CppModuleConfiguration config(makeFiles(files), llvm::Triple());
[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
2019-09-24 18:08:18 +08:00
EXPECT_THAT(config.GetImportedModules(), testing::ElementsAre("std"));
EXPECT_THAT(config.GetIncludeDirs(),
testing::ElementsAre("/usr/include/c++/v1", ResourceInc(),
"/usr/include"));
}
TEST_F(CppModuleConfigurationTest, MissingUsrInclude) {
// Test that we don't load 'std' if we can't find the C standard library.
[lldb][import-std-module] Do some basic file checks before trying to import a module Currently when LLDB has enough data in the debug information to import the `std` module, it will just try to import it. However when debugging libraries where the sources aren't available anymore, importing the module will generate a confusing diagnostic that the module couldn't be built. For the fallback mode (where we retry failed expressions with the loaded module), this will cause the second expression to fail with a module built error instead of the actual parsing issue in the user expression. This patch adds checks that ensures that we at least have any source files in the found include paths before we try to import the module. This prevents the module from being loaded in the situation described above which means we don't emit the bogus 'can't import module' diagnostic and also don't waste any time retrying the expression in the fallback mode. For the unit tests I did some refactoring as they now require a VFS with the files in it and not just the paths. The Python test just builds a binary with a fake C++ module, then deletes the module before debugging. Fixes rdar://73264458 Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D95096
2021-01-21 19:05:59 +08:00
std::string libcpp = "/usr/include/c++/v1";
std::vector<std::string> files = {// C++ library
libcpp + "/vector",
libcpp + "/module.modulemap"};
[LLDB] Provide target specific directories to libclang On Linux some C++ and C include files reside in target specific directories, like /usr/include/x86_64-linux-gnu. Patch adds them to libclang, so LLDB jitter has more chances to compile expression. OS Laboratory. Huawei Russian Research Institute. Saint-Petersburg Reviewed By: teemperor Differential Revision: https://reviews.llvm.org/D110827
2021-11-26 02:27:02 +08:00
CppModuleConfiguration config(makeFiles(files), llvm::Triple());
[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
2019-09-24 18:08:18 +08:00
EXPECT_THAT(config.GetImportedModules(), testing::ElementsAre());
EXPECT_THAT(config.GetIncludeDirs(), testing::ElementsAre());
}
TEST_F(CppModuleConfigurationTest, MissingLibCpp) {
// Test that we don't load 'std' if we don't have a libc++.
[lldb][import-std-module] Do some basic file checks before trying to import a module Currently when LLDB has enough data in the debug information to import the `std` module, it will just try to import it. However when debugging libraries where the sources aren't available anymore, importing the module will generate a confusing diagnostic that the module couldn't be built. For the fallback mode (where we retry failed expressions with the loaded module), this will cause the second expression to fail with a module built error instead of the actual parsing issue in the user expression. This patch adds checks that ensures that we at least have any source files in the found include paths before we try to import the module. This prevents the module from being loaded in the situation described above which means we don't emit the bogus 'can't import module' diagnostic and also don't waste any time retrying the expression in the fallback mode. For the unit tests I did some refactoring as they now require a VFS with the files in it and not just the paths. The Python test just builds a binary with a fake C++ module, then deletes the module before debugging. Fixes rdar://73264458 Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D95096
2021-01-21 19:05:59 +08:00
std::string usr = "/usr/include";
std::vector<std::string> files = {
// C library
usr + "/stdio.h",
};
[LLDB] Provide target specific directories to libclang On Linux some C++ and C include files reside in target specific directories, like /usr/include/x86_64-linux-gnu. Patch adds them to libclang, so LLDB jitter has more chances to compile expression. OS Laboratory. Huawei Russian Research Institute. Saint-Petersburg Reviewed By: teemperor Differential Revision: https://reviews.llvm.org/D110827
2021-11-26 02:27:02 +08:00
CppModuleConfiguration config(makeFiles(files), llvm::Triple());
[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
2019-09-24 18:08:18 +08:00
EXPECT_THAT(config.GetImportedModules(), testing::ElementsAre());
EXPECT_THAT(config.GetIncludeDirs(), testing::ElementsAre());
}
TEST_F(CppModuleConfigurationTest, IgnoreLibStdCpp) {
// Test that we don't do anything bad when we encounter libstdc++ paths.
[lldb][import-std-module] Do some basic file checks before trying to import a module Currently when LLDB has enough data in the debug information to import the `std` module, it will just try to import it. However when debugging libraries where the sources aren't available anymore, importing the module will generate a confusing diagnostic that the module couldn't be built. For the fallback mode (where we retry failed expressions with the loaded module), this will cause the second expression to fail with a module built error instead of the actual parsing issue in the user expression. This patch adds checks that ensures that we at least have any source files in the found include paths before we try to import the module. This prevents the module from being loaded in the situation described above which means we don't emit the bogus 'can't import module' diagnostic and also don't waste any time retrying the expression in the fallback mode. For the unit tests I did some refactoring as they now require a VFS with the files in it and not just the paths. The Python test just builds a binary with a fake C++ module, then deletes the module before debugging. Fixes rdar://73264458 Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D95096
2021-01-21 19:05:59 +08:00
std::string usr = "/usr/include";
std::vector<std::string> files = {
// C library
usr + "/stdio.h",
// C++ library
usr + "/c++/8.0.1/vector",
};
[LLDB] Provide target specific directories to libclang On Linux some C++ and C include files reside in target specific directories, like /usr/include/x86_64-linux-gnu. Patch adds them to libclang, so LLDB jitter has more chances to compile expression. OS Laboratory. Huawei Russian Research Institute. Saint-Petersburg Reviewed By: teemperor Differential Revision: https://reviews.llvm.org/D110827
2021-11-26 02:27:02 +08:00
CppModuleConfiguration config(makeFiles(files), llvm::Triple());
[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
2019-09-24 18:08:18 +08:00
EXPECT_THAT(config.GetImportedModules(), testing::ElementsAre());
EXPECT_THAT(config.GetIncludeDirs(), testing::ElementsAre());
}
TEST_F(CppModuleConfigurationTest, AmbiguousCLib) {
// Test that we don't do anything when we are not sure where the
// right C standard library is.
[lldb][import-std-module] Do some basic file checks before trying to import a module Currently when LLDB has enough data in the debug information to import the `std` module, it will just try to import it. However when debugging libraries where the sources aren't available anymore, importing the module will generate a confusing diagnostic that the module couldn't be built. For the fallback mode (where we retry failed expressions with the loaded module), this will cause the second expression to fail with a module built error instead of the actual parsing issue in the user expression. This patch adds checks that ensures that we at least have any source files in the found include paths before we try to import the module. This prevents the module from being loaded in the situation described above which means we don't emit the bogus 'can't import module' diagnostic and also don't waste any time retrying the expression in the fallback mode. For the unit tests I did some refactoring as they now require a VFS with the files in it and not just the paths. The Python test just builds a binary with a fake C++ module, then deletes the module before debugging. Fixes rdar://73264458 Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D95096
2021-01-21 19:05:59 +08:00
std::string usr1 = "/usr/include";
std::string usr2 = "/usr/include/other/path";
std::string libcpp = usr1 + "c++/v1";
std::vector<std::string> files = {
// First C library
usr1 + "/stdio.h",
// Second C library
usr2 + "/stdio.h",
// C++ library
libcpp + "/vector",
libcpp + "/module.modulemap",
};
[LLDB] Provide target specific directories to libclang On Linux some C++ and C include files reside in target specific directories, like /usr/include/x86_64-linux-gnu. Patch adds them to libclang, so LLDB jitter has more chances to compile expression. OS Laboratory. Huawei Russian Research Institute. Saint-Petersburg Reviewed By: teemperor Differential Revision: https://reviews.llvm.org/D110827
2021-11-26 02:27:02 +08:00
CppModuleConfiguration config(makeFiles(files), llvm::Triple());
[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
2019-09-24 18:08:18 +08:00
EXPECT_THAT(config.GetImportedModules(), testing::ElementsAre());
EXPECT_THAT(config.GetIncludeDirs(), testing::ElementsAre());
}
TEST_F(CppModuleConfigurationTest, AmbiguousLibCpp) {
// Test that we don't do anything when we are not sure where the
// right libc++ is.
[lldb][import-std-module] Do some basic file checks before trying to import a module Currently when LLDB has enough data in the debug information to import the `std` module, it will just try to import it. However when debugging libraries where the sources aren't available anymore, importing the module will generate a confusing diagnostic that the module couldn't be built. For the fallback mode (where we retry failed expressions with the loaded module), this will cause the second expression to fail with a module built error instead of the actual parsing issue in the user expression. This patch adds checks that ensures that we at least have any source files in the found include paths before we try to import the module. This prevents the module from being loaded in the situation described above which means we don't emit the bogus 'can't import module' diagnostic and also don't waste any time retrying the expression in the fallback mode. For the unit tests I did some refactoring as they now require a VFS with the files in it and not just the paths. The Python test just builds a binary with a fake C++ module, then deletes the module before debugging. Fixes rdar://73264458 Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D95096
2021-01-21 19:05:59 +08:00
std::string usr = "/usr/include";
std::string libcpp1 = usr + "c++/v1";
std::string libcpp2 = usr + "c++/v2";
std::vector<std::string> files = {
// C library
usr + "/stdio.h",
// First C++ library
libcpp1 + "/vector",
libcpp1 + "/module.modulemap",
// Second C++ library
libcpp2 + "/vector",
libcpp2 + "/module.modulemap",
};
[LLDB] Provide target specific directories to libclang On Linux some C++ and C include files reside in target specific directories, like /usr/include/x86_64-linux-gnu. Patch adds them to libclang, so LLDB jitter has more chances to compile expression. OS Laboratory. Huawei Russian Research Institute. Saint-Petersburg Reviewed By: teemperor Differential Revision: https://reviews.llvm.org/D110827
2021-11-26 02:27:02 +08:00
CppModuleConfiguration config(makeFiles(files), llvm::Triple());
[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
2019-09-24 18:08:18 +08:00
EXPECT_THAT(config.GetImportedModules(), testing::ElementsAre());
EXPECT_THAT(config.GetIncludeDirs(), testing::ElementsAre());
}