to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
The whole point of this change was making it possible to resolve paths
without depending on the FileSystem, which is not what I did here. Not
sure what I was thinking...
llvm-svn: 346466
In order to call real_path from the TildeExpressionResolver we need
access to the FileSystem. Since the resolver lives under utility we have
to pass in the FS.
llvm-svn: 346457
TestCompletion was failing quite frequently on our Linux bots. Some tracing
revealed that when we are iterating BaseDir we are not getting all the entries.
More specifically, we are sometimes missing the entry corresponding to the
TestCompletion directory that the first test in DirCompletionAbsolute is
looking for. BaseDir is the directory where lit is creating all the temporary
files. The semantics of opendir/readdir are unclear when it comes to iterating
over a directory that changes contents, but it seems like on Linux you might
fail to list an entry even if it was there before opendir and is still present
throughout the iteration. Changing the test to only look inside of the test-
specific directory seems to fix the instability.
This commit also removes some assertions that were added to try to track down
this issue.
llvm-svn: 341425
If you tried to complete somwthing like ~/., lldb would come up with a lot
of non-existent filenames by concatenating every exisitng file in the directory
with an initial '.'.
This was due to a workaround for an llvm::fs::path::filename behavior that
was not applied selectively enough.
llvm-svn: 341268
As we only use PATH_MAX for an assert in a unit test that is supposed
to catch the random failures on the Swift CI bots, we might as well
just ifdef this assert out on Windows.
llvm-svn: 340652
Summary:
The DirCompletionAbsolute is still randomly failing on the nodes even after D50722, so this patch adds more asserts
that verify certain properties on which the actual completion implementation relies on.
The first assert checks that the directory we complete on actually exists. If the directory doesn't exist on the
next CI failure, this assert should catch it and we know that the 0 matches come from a missing base directory.
The second assert is just checking that we are below the PATH_MAX limit that the completion checks against.
This check could randomly fail if the temporary directories we generate are sometimes longer than PATH_MAX,
and the assert can tell us that this is the reason we failed (instead of the mysterious '0 matches').
(As a sidenote: We shouldn't be checking against PATH_MAX anyway in the code (as this is just wrong). Also
the disk completion API really needs a better error mechanism than returning 0 on both error or no-results.)
Reviewers: aprantl, friss
Reviewed By: aprantl
Subscribers: abidh
Differential Revision: https://reviews.llvm.org/D51111
llvm-svn: 340589
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
Now that we have gmock, we can use its matchers to better express the
test assertions. The main advantage of this is that when things fail,
the test will now print the expected and actual lists of completed
strings instead of just a not-very-helpful "false is not true" message.
llvm-svn: 335955
Summary:
The test fails because we don't rewrite the slash behind `foo` to the OS specific
separator (as the completion API doesn't support this kind of rewriting). However,
we assume that this part of the string is rewritten in the test case, which broke
on Windows.
Reviewers: stella.stamenova
Reviewed By: stella.stamenova
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D48746
llvm-svn: 335934
Summary:
At present, several gtests in the lldb open source codebase are using
#include statements rooted at $(SOURCE_ROOT)/${LLDB_PROJECT_ROOT}.
This patch cleans up this directory/include structure for both CMake and
Xcode build systems.
rdar://problem/33835795
Reviewers: zturner, jingham, beanz
Reviewed By: beanz
Subscribers: emaste, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D36598
llvm-svn: 314849
Summary:
Fetching an input file required about five lines of code, and this was
repeated in multiple unit tests, with slight variations. Add a helper
function for doing that into the lldbUtilityMocks module (which I rename
to lldbUtilityHelpers to commemorate the fact it includes more than
mocks)
Reviewers: zturner, eugene
Subscribers: emaste, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D34683
llvm-svn: 306668
This was causing a test failure in one of LLDB's tests which
specifically dealt with a limitation in LLVM's implementation
of home_directory() that LLDB's own implementation had worked
around.
This limitation has been addressed in r298513 on the LLVM side,
so the failing test (which is now unnecessary as the limitation
no longer exists) was removed in r298519, allowing this patch to
be re-submitted without modification.
llvm-svn: 298526
One of the file name templates was occasionally generating the name
"fooa***", which conflicted with the one of the tests expectation that
there is only one item beginning with "fooa".
There doesn't seem to be a good reason for using random file templates
here, so just switch to a fixed set of files to increase
reproducibility.
llvm-svn: 297743
This reverts commit a6a29374662716710f80c8ece96629751697841e.
It has a few compilation failures that I don't have time to fix
at the moment.
llvm-svn: 297589
There were a couple of problems with this function on Windows. Different
separators and differences in how tilde expressions are resolved for
starters, but in addition there was no clear indication of what the
function's inputs or outputs were supposed to be, and there were no tests
to demonstrate its use.
To more easily paper over the differences between Windows paths,
non-Windows paths, and tilde expressions, I've ported this function to use
LLVM-based directory iteration (in fact, I would like to eliminate all of
LLDB's directory iteration code entirely since LLVM's is cleaner / more
efficient (i.e. it invokes fewer stat calls)). and llvm's portable path
manipulation library.
Since file and directory completion assumes you are referring to files and
directories on your local machine, it's safe to assume the path syntax
properties of the host in doing so, so LLVM's APIs are perfect for this.
I've also added a fairly robust set of unit tests. Since you can't really
predict what users will be on your machine, or what their home directories
will be, I added an interface called TildeExpressionResolver, and in the
unit test I've mocked up a fake implementation that acts like a unix
password database. This allows us to configure some fake users and home
directories in the test, so we can exercise all of those hard-to-test
codepaths that normally otherwise depend on the host.
Differential Revision: https://reviews.llvm.org/D30789
llvm-svn: 297585
Chandler Carruth