llvm-project/lldb/unittests/Interpreter/TestCompletion.cpp

296 lines
12 KiB
C++
Raw Normal View History

//===-- TestCompletion.cpp --------------------------------------*- C++ -*-===//
//
// 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 "lldb/Host/FileSystem.h"
#include "lldb/Interpreter/CommandCompletions.h"
#include "lldb/Utility/StringList.h"
#include "lldb/Utility/TildeExpressionResolver.h"
#include "gmock/gmock.h"
#include "gtest/gtest.h"
#include "TestingSupport/MockTildeExpressionResolver.h"
Include inlined functions when figuring out a contiguous address range Checking this in for Antonio Afonso: This diff changes the function LineEntry::GetSameLineContiguousAddressRange so that it also includes function calls that were inlined at the same line of code. My motivation is to decrease the step over time of lines that heavly rely on inlined functions. I have multiple examples in the code base I work that makes a step over stop 20 or mote times internally. This can easly had up to step overs that take >500ms which I was able to lower to 25ms with this new strategy. The reason the current code is not extending the address range beyond an inlined function is because when we resolve the symbol at the next address of the line entry we will get the entry line corresponding to where the original code for the inline function lives, making us barely extend the range. This then will end up on a step over having to stop multiple times everytime there's an inlined function. To check if the range is an inlined function at that line I also get the block associated with the next address and check if there is a parent block with a call site at the line we're trying to extend. To check this I created a new function in Block called GetContainingInlinedBlockWithCallSite that does exactly that. I also added a new function to Declaration for convinence of checking file/line named CompareFileAndLine. To avoid potential issues when extending an address range I added an Extend function that extends the range by the AddressRange given as an argument. This function returns true to indicate sucess when the rage was agumented, false otherwise (e.g.: the ranges are not connected). The reason I do is to make sure that we're not just blindly extending complete_line_range by whatever GetByteSize() we got. If for some reason the ranges are not connected or overlap, or even 0, this could be an issue. I also added a unit tests for this change and include the instructions on the test itself on how to generate the yaml file I use for testing. Differential Revision: https://reviews.llvm.org/D61292 llvm-svn: 360071
2019-05-07 04:01:21 +08:00
#include "TestingSupport/TestUtilities.h"
#include "llvm/ADT/SmallString.h"
#include "llvm/Support/FileSystem.h"
#include "llvm/Support/Path.h"
#include "llvm/Support/raw_ostream.h"
namespace fs = llvm::sys::fs;
namespace path = llvm::sys::path;
using namespace llvm;
using namespace lldb_private;
namespace {
class CompletionTest : public testing::Test {
protected:
/// Unique temporary directory in which all created filesystem entities must
/// be placed. It is removed at the end of the test suite.
Stability improvements for CompletionTest Summary: CompletionTest.DirCompletionAbsolute had a random failure on a CI node (in the failure, the completion count was 0, while we expected it to be 1), but there seems no good reason for it to fail. The sanitizers don't complain about the test when it's run, so I think we don't have some uninitialized memory that we access here. My best bet is that the unique directory selection randomly failed on the CI node because maybe the FS there doesn't actually guarantee the atomic fopen assumptions we make in the LLVM code (or some other funny race condition). In this case a different test run could get the same directory and clean its contents which would lead to 0 results. The other possible explanation is that someone changed the CI configuration on the node and changed the working dir to something very long, which would make our PATH_MAX test fail (which also leads to 0 results), but I think that case is unlikely. This patch is just a stab in the dark that (hopefully) fixes this random failure by giving each test a (more) unique working directory by appending the unique test name to the temp-dir prefix. Also adds one more ASSERT_NO_ERROR to one of our chdir calls just in case that is the reason for failing. The good thing is that this refactor gets rid of most of the static variables and files that we previously had as shared state between the different tests. Potentially fixes rdar://problem/43150260 Reviewers: aprantl Reviewed By: aprantl Subscribers: jfb, lldb-commits Differential Revision: https://reviews.llvm.org/D50722 llvm-svn: 339715
2018-08-15 03:36:58 +08:00
SmallString<128> BaseDir;
Stability improvements for CompletionTest Summary: CompletionTest.DirCompletionAbsolute had a random failure on a CI node (in the failure, the completion count was 0, while we expected it to be 1), but there seems no good reason for it to fail. The sanitizers don't complain about the test when it's run, so I think we don't have some uninitialized memory that we access here. My best bet is that the unique directory selection randomly failed on the CI node because maybe the FS there doesn't actually guarantee the atomic fopen assumptions we make in the LLVM code (or some other funny race condition). In this case a different test run could get the same directory and clean its contents which would lead to 0 results. The other possible explanation is that someone changed the CI configuration on the node and changed the working dir to something very long, which would make our PATH_MAX test fail (which also leads to 0 results), but I think that case is unlikely. This patch is just a stab in the dark that (hopefully) fixes this random failure by giving each test a (more) unique working directory by appending the unique test name to the temp-dir prefix. Also adds one more ASSERT_NO_ERROR to one of our chdir calls just in case that is the reason for failing. The good thing is that this refactor gets rid of most of the static variables and files that we previously had as shared state between the different tests. Potentially fixes rdar://problem/43150260 Reviewers: aprantl Reviewed By: aprantl Subscribers: jfb, lldb-commits Differential Revision: https://reviews.llvm.org/D50722 llvm-svn: 339715
2018-08-15 03:36:58 +08:00
/// The working directory that we got when starting the test. Every test
/// should chdir into this directory first because some tests maybe chdir
/// into another one during their run.
static SmallString<128> OriginalWorkingDir;
Stability improvements for CompletionTest Summary: CompletionTest.DirCompletionAbsolute had a random failure on a CI node (in the failure, the completion count was 0, while we expected it to be 1), but there seems no good reason for it to fail. The sanitizers don't complain about the test when it's run, so I think we don't have some uninitialized memory that we access here. My best bet is that the unique directory selection randomly failed on the CI node because maybe the FS there doesn't actually guarantee the atomic fopen assumptions we make in the LLVM code (or some other funny race condition). In this case a different test run could get the same directory and clean its contents which would lead to 0 results. The other possible explanation is that someone changed the CI configuration on the node and changed the working dir to something very long, which would make our PATH_MAX test fail (which also leads to 0 results), but I think that case is unlikely. This patch is just a stab in the dark that (hopefully) fixes this random failure by giving each test a (more) unique working directory by appending the unique test name to the temp-dir prefix. Also adds one more ASSERT_NO_ERROR to one of our chdir calls just in case that is the reason for failing. The good thing is that this refactor gets rid of most of the static variables and files that we previously had as shared state between the different tests. Potentially fixes rdar://problem/43150260 Reviewers: aprantl Reviewed By: aprantl Subscribers: jfb, lldb-commits Differential Revision: https://reviews.llvm.org/D50722 llvm-svn: 339715
2018-08-15 03:36:58 +08:00
SmallString<128> DirFoo;
SmallString<128> DirFooA;
SmallString<128> DirFooB;
SmallString<128> DirFooC;
SmallString<128> DirBar;
SmallString<128> DirBaz;
SmallString<128> DirTestFolder;
SmallString<128> DirNested;
SmallString<128> FileAA;
SmallString<128> FileAB;
SmallString<128> FileAC;
SmallString<128> FileFoo;
SmallString<128> FileBar;
SmallString<128> FileBaz;
void SetUp() override {
FileSystem::Initialize();
Stability improvements for CompletionTest Summary: CompletionTest.DirCompletionAbsolute had a random failure on a CI node (in the failure, the completion count was 0, while we expected it to be 1), but there seems no good reason for it to fail. The sanitizers don't complain about the test when it's run, so I think we don't have some uninitialized memory that we access here. My best bet is that the unique directory selection randomly failed on the CI node because maybe the FS there doesn't actually guarantee the atomic fopen assumptions we make in the LLVM code (or some other funny race condition). In this case a different test run could get the same directory and clean its contents which would lead to 0 results. The other possible explanation is that someone changed the CI configuration on the node and changed the working dir to something very long, which would make our PATH_MAX test fail (which also leads to 0 results), but I think that case is unlikely. This patch is just a stab in the dark that (hopefully) fixes this random failure by giving each test a (more) unique working directory by appending the unique test name to the temp-dir prefix. Also adds one more ASSERT_NO_ERROR to one of our chdir calls just in case that is the reason for failing. The good thing is that this refactor gets rid of most of the static variables and files that we previously had as shared state between the different tests. Potentially fixes rdar://problem/43150260 Reviewers: aprantl Reviewed By: aprantl Subscribers: jfb, lldb-commits Differential Revision: https://reviews.llvm.org/D50722 llvm-svn: 339715
2018-08-15 03:36:58 +08:00
// chdir back into the original working dir this test binary started with.
// A previous test may have have changed the working dir.
ASSERT_NO_ERROR(fs::set_current_path(OriginalWorkingDir));
// Get the name of the current test. To prevent that by chance two tests
// get the same temporary directory if createUniqueDirectory fails.
auto test_info = ::testing::UnitTest::GetInstance()->current_test_info();
ASSERT_TRUE(test_info != nullptr);
std::string name = test_info->name();
ASSERT_NO_ERROR(fs::createUniqueDirectory("FsCompletion-" + name, BaseDir));
const char *DirNames[] = {"foo", "fooa", "foob", "fooc",
"bar", "baz", "test_folder", "foo/nested"};
const char *FileNames[] = {"aa1234.tmp", "ab1234.tmp", "ac1234.tmp",
"foo1234.tmp", "bar1234.tmp", "baz1234.tmp"};
SmallString<128> *Dirs[] = {&DirFoo, &DirFooA, &DirFooB, &DirFooC,
&DirBar, &DirBaz, &DirTestFolder, &DirNested};
for (auto Dir : llvm::zip(DirNames, Dirs)) {
auto &Path = *std::get<1>(Dir);
Path = BaseDir;
path::append(Path, std::get<0>(Dir));
ASSERT_NO_ERROR(fs::create_directories(Path));
}
SmallString<128> *Files[] = {&FileAA, &FileAB, &FileAC,
&FileFoo, &FileBar, &FileBaz};
for (auto File : llvm::zip(FileNames, Files)) {
auto &Path = *std::get<1>(File);
Path = BaseDir;
path::append(Path, std::get<0>(File));
int FD;
ASSERT_NO_ERROR(fs::createUniqueFile(Path, FD, Path));
::close(FD);
}
}
Stability improvements for CompletionTest Summary: CompletionTest.DirCompletionAbsolute had a random failure on a CI node (in the failure, the completion count was 0, while we expected it to be 1), but there seems no good reason for it to fail. The sanitizers don't complain about the test when it's run, so I think we don't have some uninitialized memory that we access here. My best bet is that the unique directory selection randomly failed on the CI node because maybe the FS there doesn't actually guarantee the atomic fopen assumptions we make in the LLVM code (or some other funny race condition). In this case a different test run could get the same directory and clean its contents which would lead to 0 results. The other possible explanation is that someone changed the CI configuration on the node and changed the working dir to something very long, which would make our PATH_MAX test fail (which also leads to 0 results), but I think that case is unlikely. This patch is just a stab in the dark that (hopefully) fixes this random failure by giving each test a (more) unique working directory by appending the unique test name to the temp-dir prefix. Also adds one more ASSERT_NO_ERROR to one of our chdir calls just in case that is the reason for failing. The good thing is that this refactor gets rid of most of the static variables and files that we previously had as shared state between the different tests. Potentially fixes rdar://problem/43150260 Reviewers: aprantl Reviewed By: aprantl Subscribers: jfb, lldb-commits Differential Revision: https://reviews.llvm.org/D50722 llvm-svn: 339715
2018-08-15 03:36:58 +08:00
static void SetUpTestCase() {
ASSERT_NO_ERROR(fs::current_path(OriginalWorkingDir));
}
void TearDown() override {
ASSERT_NO_ERROR(fs::remove_directories(BaseDir));
FileSystem::Terminate();
}
Stability improvements for CompletionTest Summary: CompletionTest.DirCompletionAbsolute had a random failure on a CI node (in the failure, the completion count was 0, while we expected it to be 1), but there seems no good reason for it to fail. The sanitizers don't complain about the test when it's run, so I think we don't have some uninitialized memory that we access here. My best bet is that the unique directory selection randomly failed on the CI node because maybe the FS there doesn't actually guarantee the atomic fopen assumptions we make in the LLVM code (or some other funny race condition). In this case a different test run could get the same directory and clean its contents which would lead to 0 results. The other possible explanation is that someone changed the CI configuration on the node and changed the working dir to something very long, which would make our PATH_MAX test fail (which also leads to 0 results), but I think that case is unlikely. This patch is just a stab in the dark that (hopefully) fixes this random failure by giving each test a (more) unique working directory by appending the unique test name to the temp-dir prefix. Also adds one more ASSERT_NO_ERROR to one of our chdir calls just in case that is the reason for failing. The good thing is that this refactor gets rid of most of the static variables and files that we previously had as shared state between the different tests. Potentially fixes rdar://problem/43150260 Reviewers: aprantl Reviewed By: aprantl Subscribers: jfb, lldb-commits Differential Revision: https://reviews.llvm.org/D50722 llvm-svn: 339715
2018-08-15 03:36:58 +08:00
static bool HasEquivalentFile(const Twine &Path, const StringList &Paths) {
for (size_t I = 0; I < Paths.GetSize(); ++I) {
if (fs::equivalent(Path, Paths[I]))
return true;
}
return false;
}
void DoDirCompletions(const Twine &Prefix,
StandardTildeExpressionResolver &Resolver,
StringList &Results) {
// When a partial name matches, it returns all matches. If it matches both
// a full name AND some partial names, it returns all of them.
uint32_t Count =
CommandCompletions::DiskDirectories(Prefix + "foo", Results, Resolver);
ASSERT_EQ(4u, Count);
ASSERT_EQ(Count, Results.GetSize());
EXPECT_TRUE(HasEquivalentFile(DirFoo, Results));
EXPECT_TRUE(HasEquivalentFile(DirFooA, Results));
EXPECT_TRUE(HasEquivalentFile(DirFooB, Results));
EXPECT_TRUE(HasEquivalentFile(DirFooC, Results));
// If it matches only partial names, it still works as expected.
Count = CommandCompletions::DiskDirectories(Twine(Prefix) + "b", Results,
Resolver);
ASSERT_EQ(2u, Count);
ASSERT_EQ(Count, Results.GetSize());
EXPECT_TRUE(HasEquivalentFile(DirBar, Results));
EXPECT_TRUE(HasEquivalentFile(DirBaz, Results));
}
};
SmallString<128> CompletionTest::OriginalWorkingDir;
} // namespace
static std::vector<std::string> toVector(const StringList &SL) {
std::vector<std::string> Result;
for (size_t Idx = 0; Idx < SL.GetSize(); ++Idx)
Result.push_back(SL[Idx]);
return Result;
}
using testing::UnorderedElementsAre;
TEST_F(CompletionTest, DirCompletionAbsolute) {
// All calls to DiskDirectories() return only directories, even when
// there are files which also match. The tests below all check this
// by asserting an exact result count, and verifying against known
// folders.
std::string Prefixes[] = {(Twine(BaseDir) + "/").str(), ""};
StandardTildeExpressionResolver Resolver;
StringList Results;
// When a directory is specified that doesn't end in a slash, it searches
// for that directory, not items under it.
// Sanity check that the path we complete on exists and isn't too long.
size_t Count = CommandCompletions::DiskDirectories(Twine(BaseDir) + "/fooa",
Results, Resolver);
ASSERT_EQ(1u, Count);
ASSERT_EQ(Count, Results.GetSize());
EXPECT_TRUE(HasEquivalentFile(DirFooA, Results));
Count = CommandCompletions::DiskDirectories(Twine(BaseDir) + "/.", Results,
Resolver);
ASSERT_EQ(0u, Count);
ASSERT_EQ(Count, Results.GetSize());
// When the same directory ends with a slash, it finds all children.
Count = CommandCompletions::DiskDirectories(Prefixes[0], Results, Resolver);
ASSERT_EQ(7u, Count);
ASSERT_EQ(Count, Results.GetSize());
EXPECT_TRUE(HasEquivalentFile(DirFoo, Results));
EXPECT_TRUE(HasEquivalentFile(DirFooA, Results));
EXPECT_TRUE(HasEquivalentFile(DirFooB, Results));
EXPECT_TRUE(HasEquivalentFile(DirFooC, Results));
EXPECT_TRUE(HasEquivalentFile(DirBar, Results));
EXPECT_TRUE(HasEquivalentFile(DirBaz, Results));
EXPECT_TRUE(HasEquivalentFile(DirTestFolder, Results));
DoDirCompletions(Twine(BaseDir) + "/", Resolver, Results);
llvm::sys::fs::set_current_path(BaseDir);
DoDirCompletions("", Resolver, Results);
}
TEST_F(CompletionTest, FileCompletionAbsolute) {
// All calls to DiskFiles() return both files and directories The tests below
// all check this by asserting an exact result count, and verifying against
// known folders.
StandardTildeExpressionResolver Resolver;
StringList Results;
// When an item is specified that doesn't end in a slash but exactly matches
// one item, it returns that item.
size_t Count = CommandCompletions::DiskFiles(Twine(BaseDir) + "/fooa",
Results, Resolver);
ASSERT_EQ(1u, Count);
ASSERT_EQ(Count, Results.GetSize());
EXPECT_TRUE(HasEquivalentFile(DirFooA, Results));
// The previous check verified a directory match. But it should work for
// files too.
Count =
CommandCompletions::DiskFiles(Twine(BaseDir) + "/aa", Results, Resolver);
ASSERT_EQ(1u, Count);
ASSERT_EQ(Count, Results.GetSize());
EXPECT_TRUE(HasEquivalentFile(FileAA, Results));
// When it ends with a slash, it should find all files and directories.
Count =
CommandCompletions::DiskFiles(Twine(BaseDir) + "/", Results, Resolver);
ASSERT_EQ(13u, Count);
ASSERT_EQ(Count, Results.GetSize());
EXPECT_TRUE(HasEquivalentFile(DirFoo, Results));
EXPECT_TRUE(HasEquivalentFile(DirFooA, Results));
EXPECT_TRUE(HasEquivalentFile(DirFooB, Results));
EXPECT_TRUE(HasEquivalentFile(DirFooC, Results));
EXPECT_TRUE(HasEquivalentFile(DirBar, Results));
EXPECT_TRUE(HasEquivalentFile(DirBaz, Results));
EXPECT_TRUE(HasEquivalentFile(DirTestFolder, Results));
EXPECT_TRUE(HasEquivalentFile(FileAA, Results));
EXPECT_TRUE(HasEquivalentFile(FileAB, Results));
EXPECT_TRUE(HasEquivalentFile(FileAC, Results));
EXPECT_TRUE(HasEquivalentFile(FileFoo, Results));
EXPECT_TRUE(HasEquivalentFile(FileBar, Results));
EXPECT_TRUE(HasEquivalentFile(FileBaz, Results));
// When a partial name matches, it returns all file & directory matches.
Count =
CommandCompletions::DiskFiles(Twine(BaseDir) + "/foo", Results, Resolver);
ASSERT_EQ(5u, Count);
ASSERT_EQ(Count, Results.GetSize());
EXPECT_TRUE(HasEquivalentFile(DirFoo, Results));
EXPECT_TRUE(HasEquivalentFile(DirFooA, Results));
EXPECT_TRUE(HasEquivalentFile(DirFooB, Results));
EXPECT_TRUE(HasEquivalentFile(DirFooC, Results));
EXPECT_TRUE(HasEquivalentFile(FileFoo, Results));
}
TEST_F(CompletionTest, DirCompletionUsername) {
MockTildeExpressionResolver Resolver("James", BaseDir);
Resolver.AddKnownUser("Kirk", DirFooB);
Resolver.AddKnownUser("Lars", DirFooC);
Resolver.AddKnownUser("Jason", DirFoo);
Resolver.AddKnownUser("Larry", DirFooA);
std::string sep = path::get_separator();
// Just resolving current user's home directory by itself should return the
// directory.
StringList Results;
size_t Count = CommandCompletions::DiskDirectories("~", Results, Resolver);
EXPECT_EQ(Count, Results.GetSize());
EXPECT_THAT(toVector(Results), UnorderedElementsAre("~" + sep));
// With a slash appended, it should return all items in the directory.
Count = CommandCompletions::DiskDirectories("~/", Results, Resolver);
EXPECT_THAT(toVector(Results),
UnorderedElementsAre(
"~/foo" + sep, "~/fooa" + sep, "~/foob" + sep, "~/fooc" + sep,
"~/bar" + sep, "~/baz" + sep, "~/test_folder" + sep));
EXPECT_EQ(Count, Results.GetSize());
// Check that we can complete directories in nested paths
Count = CommandCompletions::DiskDirectories("~/foo/", Results, Resolver);
EXPECT_EQ(Count, Results.GetSize());
EXPECT_THAT(toVector(Results), UnorderedElementsAre("~/foo/nested" + sep));
Count = CommandCompletions::DiskDirectories("~/foo/nes", Results, Resolver);
EXPECT_EQ(Count, Results.GetSize());
EXPECT_THAT(toVector(Results), UnorderedElementsAre("~/foo/nested" + sep));
// With ~username syntax it should return one match if there is an exact
// match. It shouldn't translate to the actual directory, it should keep the
// form the user typed.
Count = CommandCompletions::DiskDirectories("~Lars", Results, Resolver);
EXPECT_EQ(Count, Results.GetSize());
EXPECT_THAT(toVector(Results), UnorderedElementsAre("~Lars" + sep));
// But with a username that is not found, no results are returned.
Count = CommandCompletions::DiskDirectories("~Dave", Results, Resolver);
EXPECT_EQ(Count, Results.GetSize());
EXPECT_THAT(toVector(Results), UnorderedElementsAre());
// And if there are multiple matches, it should return all of them.
Count = CommandCompletions::DiskDirectories("~La", Results, Resolver);
EXPECT_EQ(Count, Results.GetSize());
EXPECT_THAT(toVector(Results),
UnorderedElementsAre("~Lars" + sep, "~Larry" + sep));
}