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

372 lines
13 KiB
C++
Raw Normal View History

Fix a couple of cornercases in FileSpec + tests Summary: This fixes a couple of corner cases in FileSpec, related to AppendPathComponent and handling of root directory (/) file spec. I add a bunch of unit tests for the new behavior. Summary of changes: FileSpec("/bar").GetCString(): before "//bar", after "/bar". FileSpec("/").CopyByAppendingPathComponent("bar").GetCString(): before "//bar", after "/bar". FileSpec("C:", ePathSyntaxWindows).CopyByAppendingPathComponent("bar").GetCString(): before "C:/bar", after "C:\bar". Reviewers: clayborg, zturner Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D18044 llvm-svn: 263207
2016-03-11 16:44:44 +08:00
//===-- FileSpecTest.cpp ----------------------------------------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
#include "gtest/gtest.h"
Move FileSpec from Host -> Utility. llvm-svn: 298536
2017-03-23 02:40:07 +08:00
#include "lldb/Utility/FileSpec.h"
Fix a couple of cornercases in FileSpec + tests Summary: This fixes a couple of corner cases in FileSpec, related to AppendPathComponent and handling of root directory (/) file spec. I add a bunch of unit tests for the new behavior. Summary of changes: FileSpec("/bar").GetCString(): before "//bar", after "/bar". FileSpec("/").CopyByAppendingPathComponent("bar").GetCString(): before "//bar", after "/bar". FileSpec("C:", ePathSyntaxWindows).CopyByAppendingPathComponent("bar").GetCString(): before "C:/bar", after "C:\bar". Reviewers: clayborg, zturner Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D18044 llvm-svn: 263207
2016-03-11 16:44:44 +08:00
using namespace lldb_private;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
TEST(FileSpecTest, FileAndDirectoryComponents) {
[FileSystem] Move path resolution logic out of FileSpec This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
2018-11-02 05:05:36 +08:00
FileSpec fs_posix("/foo/bar", FileSpec::Style::posix);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
EXPECT_STREQ("/foo/bar", fs_posix.GetCString());
EXPECT_STREQ("/foo", fs_posix.GetDirectory().GetCString());
EXPECT_STREQ("bar", fs_posix.GetFilename().GetCString());
[FileSystem] Move path resolution logic out of FileSpec This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
2018-11-02 05:05:36 +08:00
FileSpec fs_windows("F:\\bar", FileSpec::Style::windows);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
EXPECT_STREQ("F:\\bar", fs_windows.GetCString());
// EXPECT_STREQ("F:\\", fs_windows.GetDirectory().GetCString()); // It returns
// "F:/"
EXPECT_STREQ("bar", fs_windows.GetFilename().GetCString());
[FileSystem] Move path resolution logic out of FileSpec This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
2018-11-02 05:05:36 +08:00
FileSpec fs_posix_root("/", FileSpec::Style::posix);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
EXPECT_STREQ("/", fs_posix_root.GetCString());
EXPECT_EQ(nullptr, fs_posix_root.GetDirectory().GetCString());
EXPECT_STREQ("/", fs_posix_root.GetFilename().GetCString());
[FileSystem] Move path resolution logic out of FileSpec This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
2018-11-02 05:05:36 +08:00
FileSpec fs_net_drive("//net", FileSpec::Style::posix);
[FileSpec] Delegate common operations to llvm::sys::path With the recent changes in FileSpec to use LLVM's path style, it is possible to delegate a bunch of common path operations to LLVM's path helpers. This means we only have to maintain a single implementation and at the same time can benefit from the efforts made by the rest of the LLVM community. This is part one of a set of patches. There was no obvious way to split this so I just worked from top to bottom. Differential revision: https://reviews.llvm.org/D48084 llvm-svn: 334615
2018-06-14 00:23:21 +08:00
EXPECT_STREQ("//net", fs_net_drive.GetCString());
EXPECT_EQ(nullptr, fs_net_drive.GetDirectory().GetCString());
EXPECT_STREQ("//net", fs_net_drive.GetFilename().GetCString());
[FileSystem] Move path resolution logic out of FileSpec This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
2018-11-02 05:05:36 +08:00
FileSpec fs_net_root("//net/", FileSpec::Style::posix);
[FileSpec] Delegate common operations to llvm::sys::path With the recent changes in FileSpec to use LLVM's path style, it is possible to delegate a bunch of common path operations to LLVM's path helpers. This means we only have to maintain a single implementation and at the same time can benefit from the efforts made by the rest of the LLVM community. This is part one of a set of patches. There was no obvious way to split this so I just worked from top to bottom. Differential revision: https://reviews.llvm.org/D48084 llvm-svn: 334615
2018-06-14 00:23:21 +08:00
EXPECT_STREQ("//net/", fs_net_root.GetCString());
EXPECT_STREQ("//net", fs_net_root.GetDirectory().GetCString());
EXPECT_STREQ("/", fs_net_root.GetFilename().GetCString());
[FileSystem] Move path resolution logic out of FileSpec This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
2018-11-02 05:05:36 +08:00
FileSpec fs_windows_drive("F:", FileSpec::Style::windows);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
EXPECT_STREQ("F:", fs_windows_drive.GetCString());
EXPECT_EQ(nullptr, fs_windows_drive.GetDirectory().GetCString());
EXPECT_STREQ("F:", fs_windows_drive.GetFilename().GetCString());
[FileSystem] Move path resolution logic out of FileSpec This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
2018-11-02 05:05:36 +08:00
FileSpec fs_windows_root("F:\\", FileSpec::Style::windows);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
EXPECT_STREQ("F:\\", fs_windows_root.GetCString());
EXPECT_STREQ("F:", fs_windows_root.GetDirectory().GetCString());
// EXPECT_STREQ("\\", fs_windows_root.GetFilename().GetCString()); // It
// returns "/"
[FileSystem] Move path resolution logic out of FileSpec This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
2018-11-02 05:05:36 +08:00
FileSpec fs_posix_long("/foo/bar/baz", FileSpec::Style::posix);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
EXPECT_STREQ("/foo/bar/baz", fs_posix_long.GetCString());
EXPECT_STREQ("/foo/bar", fs_posix_long.GetDirectory().GetCString());
EXPECT_STREQ("baz", fs_posix_long.GetFilename().GetCString());
[FileSystem] Move path resolution logic out of FileSpec This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
2018-11-02 05:05:36 +08:00
FileSpec fs_windows_long("F:\\bar\\baz", FileSpec::Style::windows);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
EXPECT_STREQ("F:\\bar\\baz", fs_windows_long.GetCString());
// EXPECT_STREQ("F:\\bar", fs_windows_long.GetDirectory().GetCString()); // It
// returns "F:/bar"
EXPECT_STREQ("baz", fs_windows_long.GetFilename().GetCString());
[FileSystem] Move path resolution logic out of FileSpec This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
2018-11-02 05:05:36 +08:00
FileSpec fs_posix_trailing_slash("/foo/bar/", FileSpec::Style::posix);
Always normalize FileSpec paths. Always normalizing lldb_private::FileSpec paths will help us get a consistent results from comparisons when setting breakpoints and when looking for source files. This also removes a lot of complexity from the comparison routines. Modified the DWARF line table parser to use the normalized compile unit directory if needed. Differential Revision: https://reviews.llvm.org/D45977 llvm-svn: 331049
2018-04-27 23:45:58 +08:00
EXPECT_STREQ("/foo/bar", fs_posix_trailing_slash.GetCString());
EXPECT_STREQ("/foo", fs_posix_trailing_slash.GetDirectory().GetCString());
EXPECT_STREQ("bar", fs_posix_trailing_slash.GetFilename().GetCString());
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
[FileSystem] Move path resolution logic out of FileSpec This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
2018-11-02 05:05:36 +08:00
FileSpec fs_windows_trailing_slash("F:\\bar\\", FileSpec::Style::windows);
Always normalize FileSpec paths. Always normalizing lldb_private::FileSpec paths will help us get a consistent results from comparisons when setting breakpoints and when looking for source files. This also removes a lot of complexity from the comparison routines. Modified the DWARF line table parser to use the normalized compile unit directory if needed. Differential Revision: https://reviews.llvm.org/D45977 llvm-svn: 331049
2018-04-27 23:45:58 +08:00
EXPECT_STREQ("F:\\bar", fs_windows_trailing_slash.GetCString());
EXPECT_STREQ("bar", fs_windows_trailing_slash.GetFilename().GetCString());
Fix a couple of cornercases in FileSpec + tests Summary: This fixes a couple of corner cases in FileSpec, related to AppendPathComponent and handling of root directory (/) file spec. I add a bunch of unit tests for the new behavior. Summary of changes: FileSpec("/bar").GetCString(): before "//bar", after "/bar". FileSpec("/").CopyByAppendingPathComponent("bar").GetCString(): before "//bar", after "/bar". FileSpec("C:", ePathSyntaxWindows).CopyByAppendingPathComponent("bar").GetCString(): before "C:/bar", after "C:\bar". Reviewers: clayborg, zturner Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D18044 llvm-svn: 263207
2016-03-11 16:44:44 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
TEST(FileSpecTest, AppendPathComponent) {
[FileSystem] Move path resolution logic out of FileSpec This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
2018-11-02 05:05:36 +08:00
FileSpec fs_posix("/foo", FileSpec::Style::posix);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
fs_posix.AppendPathComponent("bar");
EXPECT_STREQ("/foo/bar", fs_posix.GetCString());
EXPECT_STREQ("/foo", fs_posix.GetDirectory().GetCString());
EXPECT_STREQ("bar", fs_posix.GetFilename().GetCString());
[FileSystem] Move path resolution logic out of FileSpec This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
2018-11-02 05:05:36 +08:00
FileSpec fs_posix_2("/foo", FileSpec::Style::posix);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
fs_posix_2.AppendPathComponent("//bar/baz");
EXPECT_STREQ("/foo/bar/baz", fs_posix_2.GetCString());
EXPECT_STREQ("/foo/bar", fs_posix_2.GetDirectory().GetCString());
EXPECT_STREQ("baz", fs_posix_2.GetFilename().GetCString());
[FileSystem] Move path resolution logic out of FileSpec This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
2018-11-02 05:05:36 +08:00
FileSpec fs_windows("F:\\bar", FileSpec::Style::windows);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
fs_windows.AppendPathComponent("baz");
EXPECT_STREQ("F:\\bar\\baz", fs_windows.GetCString());
// EXPECT_STREQ("F:\\bar", fs_windows.GetDirectory().GetCString()); // It
// returns "F:/bar"
EXPECT_STREQ("baz", fs_windows.GetFilename().GetCString());
[FileSystem] Move path resolution logic out of FileSpec This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
2018-11-02 05:05:36 +08:00
FileSpec fs_posix_root("/", FileSpec::Style::posix);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
fs_posix_root.AppendPathComponent("bar");
EXPECT_STREQ("/bar", fs_posix_root.GetCString());
EXPECT_STREQ("/", fs_posix_root.GetDirectory().GetCString());
EXPECT_STREQ("bar", fs_posix_root.GetFilename().GetCString());
[FileSystem] Move path resolution logic out of FileSpec This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
2018-11-02 05:05:36 +08:00
FileSpec fs_windows_root("F:\\", FileSpec::Style::windows);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
fs_windows_root.AppendPathComponent("bar");
EXPECT_STREQ("F:\\bar", fs_windows_root.GetCString());
// EXPECT_STREQ("F:\\", fs_windows_root.GetDirectory().GetCString()); // It
// returns "F:/"
EXPECT_STREQ("bar", fs_windows_root.GetFilename().GetCString());
Fix a couple of cornercases in FileSpec + tests Summary: This fixes a couple of corner cases in FileSpec, related to AppendPathComponent and handling of root directory (/) file spec. I add a bunch of unit tests for the new behavior. Summary of changes: FileSpec("/bar").GetCString(): before "//bar", after "/bar". FileSpec("/").CopyByAppendingPathComponent("bar").GetCString(): before "//bar", after "/bar". FileSpec("C:", ePathSyntaxWindows).CopyByAppendingPathComponent("bar").GetCString(): before "C:/bar", after "C:\bar". Reviewers: clayborg, zturner Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D18044 llvm-svn: 263207
2016-03-11 16:44:44 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
TEST(FileSpecTest, CopyByAppendingPathComponent) {
[FileSystem] Move path resolution logic out of FileSpec This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
2018-11-02 05:05:36 +08:00
FileSpec fs = FileSpec("/foo", FileSpec::Style::posix)
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
.CopyByAppendingPathComponent("bar");
EXPECT_STREQ("/foo/bar", fs.GetCString());
EXPECT_STREQ("/foo", fs.GetDirectory().GetCString());
EXPECT_STREQ("bar", fs.GetFilename().GetCString());
Fix a couple of cornercases in FileSpec + tests Summary: This fixes a couple of corner cases in FileSpec, related to AppendPathComponent and handling of root directory (/) file spec. I add a bunch of unit tests for the new behavior. Summary of changes: FileSpec("/bar").GetCString(): before "//bar", after "/bar". FileSpec("/").CopyByAppendingPathComponent("bar").GetCString(): before "//bar", after "/bar". FileSpec("C:", ePathSyntaxWindows).CopyByAppendingPathComponent("bar").GetCString(): before "C:/bar", after "C:\bar". Reviewers: clayborg, zturner Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D18044 llvm-svn: 263207
2016-03-11 16:44:44 +08:00
}
FileSpec: make matching separator-agnostic again Summary: In D18689, I removed the call to Normalize() in FileSpec::SetFile, because it no longer seemed needed, and it resolved a quirk in the FileSpec API (spec.GetCString() returnes a path with backslashes, but spec.GetDirectory().GetCString() has forward slashes). This turned out to be a problem because we would consider paths with different separators as different (which led to unresolved breakpoints for instance). Here, I am putting back in the call to Normalize() and adding a unittest for FileSpec::Equal. I am commenting out the GetDirectory unittests until we figure out the what is the expected behaviour here. Reviewers: zturner Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D19060 llvm-svn: 266286
2016-04-14 17:38:06 +08:00
FileSpec: Fix PrependPathComponent("/") Summary: PrependPathComponent was unconditionally inserting path separators between the path components. This is not correct if the prepended path is "/", which caused problems down the line. Fix the function to use the same algorithm as AppendPathComponent and add a test. This fixes one part of llvm.org/pr31611. Reviewers: clayborg, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D28677 llvm-svn: 292100
2017-01-16 18:07:02 +08:00
TEST(FileSpecTest, PrependPathComponent) {
[FileSystem] Move path resolution logic out of FileSpec This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
2018-11-02 05:05:36 +08:00
FileSpec fs_posix("foo", FileSpec::Style::posix);
FileSpec: Fix PrependPathComponent("/") Summary: PrependPathComponent was unconditionally inserting path separators between the path components. This is not correct if the prepended path is "/", which caused problems down the line. Fix the function to use the same algorithm as AppendPathComponent and add a test. This fixes one part of llvm.org/pr31611. Reviewers: clayborg, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D28677 llvm-svn: 292100
2017-01-16 18:07:02 +08:00
fs_posix.PrependPathComponent("/bar");
EXPECT_STREQ("/bar/foo", fs_posix.GetCString());
[FileSystem] Move path resolution logic out of FileSpec This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
2018-11-02 05:05:36 +08:00
FileSpec fs_posix_2("foo/bar", FileSpec::Style::posix);
FileSpec: Fix PrependPathComponent("/") Summary: PrependPathComponent was unconditionally inserting path separators between the path components. This is not correct if the prepended path is "/", which caused problems down the line. Fix the function to use the same algorithm as AppendPathComponent and add a test. This fixes one part of llvm.org/pr31611. Reviewers: clayborg, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D28677 llvm-svn: 292100
2017-01-16 18:07:02 +08:00
fs_posix_2.PrependPathComponent("/baz");
EXPECT_STREQ("/baz/foo/bar", fs_posix_2.GetCString());
[FileSystem] Move path resolution logic out of FileSpec This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
2018-11-02 05:05:36 +08:00
FileSpec fs_windows("baz", FileSpec::Style::windows);
FileSpec: Fix PrependPathComponent("/") Summary: PrependPathComponent was unconditionally inserting path separators between the path components. This is not correct if the prepended path is "/", which caused problems down the line. Fix the function to use the same algorithm as AppendPathComponent and add a test. This fixes one part of llvm.org/pr31611. Reviewers: clayborg, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D28677 llvm-svn: 292100
2017-01-16 18:07:02 +08:00
fs_windows.PrependPathComponent("F:\\bar");
EXPECT_STREQ("F:\\bar\\baz", fs_windows.GetCString());
[FileSystem] Move path resolution logic out of FileSpec This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
2018-11-02 05:05:36 +08:00
FileSpec fs_posix_root("bar", FileSpec::Style::posix);
FileSpec: Fix PrependPathComponent("/") Summary: PrependPathComponent was unconditionally inserting path separators between the path components. This is not correct if the prepended path is "/", which caused problems down the line. Fix the function to use the same algorithm as AppendPathComponent and add a test. This fixes one part of llvm.org/pr31611. Reviewers: clayborg, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D28677 llvm-svn: 292100
2017-01-16 18:07:02 +08:00
fs_posix_root.PrependPathComponent("/");
EXPECT_STREQ("/bar", fs_posix_root.GetCString());
[FileSystem] Move path resolution logic out of FileSpec This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
2018-11-02 05:05:36 +08:00
FileSpec fs_windows_root("bar", FileSpec::Style::windows);
FileSpec: Fix PrependPathComponent("/") Summary: PrependPathComponent was unconditionally inserting path separators between the path components. This is not correct if the prepended path is "/", which caused problems down the line. Fix the function to use the same algorithm as AppendPathComponent and add a test. This fixes one part of llvm.org/pr31611. Reviewers: clayborg, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D28677 llvm-svn: 292100
2017-01-16 18:07:02 +08:00
fs_windows_root.PrependPathComponent("F:\\");
EXPECT_STREQ("F:\\bar", fs_windows_root.GetCString());
}
Add a couple of fun unit tests for FileSpec::Equal Most of them fail right now and are commented out. The main problem is handling of backslashes on windows, but also the posix path code has a couple of issues. llvm-svn: 285393
2016-10-28 19:28:01 +08:00
TEST(FileSpecTest, EqualSeparator) {
[FileSystem] Move path resolution logic out of FileSpec This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
2018-11-02 05:05:36 +08:00
FileSpec backward("C:\\foo\\bar", FileSpec::Style::windows);
FileSpec forward("C:/foo/bar", FileSpec::Style::windows);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
EXPECT_EQ(forward, backward);
Add a couple of fun unit tests for FileSpec::Equal Most of them fail right now and are commented out. The main problem is handling of backslashes on windows, but also the posix path code has a couple of issues. llvm-svn: 285393
2016-10-28 19:28:01 +08:00
}
TEST(FileSpecTest, EqualDotsWindows) {
std::pair<const char *, const char *> tests[] = {
{R"(C:\foo\bar\baz)", R"(C:\foo\foo\..\bar\baz)"},
{R"(C:\bar\baz)", R"(C:\foo\..\bar\baz)"},
{R"(C:\bar\baz)", R"(C:/foo/../bar/baz)"},
{R"(C:/bar/baz)", R"(C:\foo\..\bar\baz)"},
{R"(C:\bar)", R"(C:\foo\..\bar)"},
Improve ".." handling in FileSpec normalization Summary: .. handling for windows path was completely broken because the function was expecting \ as path separators, but we were passing it normalized file paths, where these have been replaced by forward slashes. Apart from this, the function was incorrect for posix paths as well in some corner cases, as well as being generally hard to follow. The corner cases were: - /../bar -> should be same as /bar - /bar/.. -> should be same as / (slightly dodgy as the former depends on /bar actually existing, but since we're doing it in an abstract way, I think the transformation is reasonable) I rewrite the function to fix these corner cases and handle windows paths more correctly. The function should now handle the posix paths (modulo symlinks, but we cannot really do anything about that without a real filesystem). For windows paths, there are a couple of corner cases left, mostly to do with drive letter handling, which cannot be fixed until the rest of the class understands drive letters better. Reviewers: clayborg, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D26081 llvm-svn: 285593
2016-11-01 00:22:07 +08:00
{R"(C:\foo\bar)", R"(C:\foo\.\bar)"},
In FileSpec::Equal, short-cut GetNormalizedPath. GetNormalizedPath seems to be slow, so it's worth shortcutting it if possible. This change does so when the filenames and not equal and we can tell GetNormalizedPath would not make them equal. Also added a test for "." final component since that was missing. llvm-svn: 298876
2017-03-28 03:12:25 +08:00
{R"(C:\foo\bar)", R"(C:\foo\bar\.)"},
Add a couple of fun unit tests for FileSpec::Equal Most of them fail right now and are commented out. The main problem is handling of backslashes on windows, but also the posix path code has a couple of issues. llvm-svn: 285393
2016-10-28 19:28:01 +08:00
};
Move FileSpecTest to Utility FileSpec class was moved to the Utility module a while ago, but the test file was left behind. This corrects that. llvm-svn: 330405
2018-04-20 16:27:27 +08:00
for (const auto &test : tests) {
[FileSystem] Move path resolution logic out of FileSpec This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
2018-11-02 05:05:36 +08:00
FileSpec one(test.first, FileSpec::Style::windows);
FileSpec two(test.second, FileSpec::Style::windows);
Always normalize FileSpec paths. Always normalizing lldb_private::FileSpec paths will help us get a consistent results from comparisons when setting breakpoints and when looking for source files. This also removes a lot of complexity from the comparison routines. Modified the DWARF line table parser to use the normalized compile unit directory if needed. Differential Revision: https://reviews.llvm.org/D45977 llvm-svn: 331049
2018-04-27 23:45:58 +08:00
EXPECT_EQ(one, two);
Add a couple of fun unit tests for FileSpec::Equal Most of them fail right now and are commented out. The main problem is handling of backslashes on windows, but also the posix path code has a couple of issues. llvm-svn: 285393
2016-10-28 19:28:01 +08:00
}
}
TEST(FileSpecTest, EqualDotsPosix) {
std::pair<const char *, const char *> tests[] = {
{R"(/foo/bar/baz)", R"(/foo/foo/../bar/baz)"},
{R"(/bar/baz)", R"(/foo/../bar/baz)"},
Improve ".." handling in FileSpec normalization Summary: .. handling for windows path was completely broken because the function was expecting \ as path separators, but we were passing it normalized file paths, where these have been replaced by forward slashes. Apart from this, the function was incorrect for posix paths as well in some corner cases, as well as being generally hard to follow. The corner cases were: - /../bar -> should be same as /bar - /bar/.. -> should be same as / (slightly dodgy as the former depends on /bar actually existing, but since we're doing it in an abstract way, I think the transformation is reasonable) I rewrite the function to fix these corner cases and handle windows paths more correctly. The function should now handle the posix paths (modulo symlinks, but we cannot really do anything about that without a real filesystem). For windows paths, there are a couple of corner cases left, mostly to do with drive letter handling, which cannot be fixed until the rest of the class understands drive letters better. Reviewers: clayborg, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D26081 llvm-svn: 285593
2016-11-01 00:22:07 +08:00
{R"(/bar)", R"(/foo/../bar)"},
{R"(/foo/bar)", R"(/foo/./bar)"},
In FileSpec::Equal, short-cut GetNormalizedPath. GetNormalizedPath seems to be slow, so it's worth shortcutting it if possible. This change does so when the filenames and not equal and we can tell GetNormalizedPath would not make them equal. Also added a test for "." final component since that was missing. llvm-svn: 298876
2017-03-28 03:12:25 +08:00
{R"(/foo/bar)", R"(/foo/bar/.)"},
Add a couple of fun unit tests for FileSpec::Equal Most of them fail right now and are commented out. The main problem is handling of backslashes on windows, but also the posix path code has a couple of issues. llvm-svn: 285393
2016-10-28 19:28:01 +08:00
};
Move FileSpecTest to Utility FileSpec class was moved to the Utility module a while ago, but the test file was left behind. This corrects that. llvm-svn: 330405
2018-04-20 16:27:27 +08:00
for (const auto &test : tests) {
[FileSystem] Move path resolution logic out of FileSpec This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
2018-11-02 05:05:36 +08:00
FileSpec one(test.first, FileSpec::Style::posix);
FileSpec two(test.second, FileSpec::Style::posix);
Always normalize FileSpec paths. Always normalizing lldb_private::FileSpec paths will help us get a consistent results from comparisons when setting breakpoints and when looking for source files. This also removes a lot of complexity from the comparison routines. Modified the DWARF line table parser to use the normalized compile unit directory if needed. Differential Revision: https://reviews.llvm.org/D45977 llvm-svn: 331049
2018-04-27 23:45:58 +08:00
EXPECT_EQ(one, two);
Add a couple of fun unit tests for FileSpec::Equal Most of them fail right now and are commented out. The main problem is handling of backslashes on windows, but also the posix path code has a couple of issues. llvm-svn: 285393
2016-10-28 19:28:01 +08:00
}
}
TEST(FileSpecTest, EqualDotsPosixRoot) {
std::pair<const char *, const char *> tests[] = {
Move FileSpecTest to Utility FileSpec class was moved to the Utility module a while ago, but the test file was left behind. This corrects that. llvm-svn: 330405
2018-04-20 16:27:27 +08:00
{R"(/)", R"(/..)"},
{R"(/)", R"(/.)"},
{R"(/)", R"(/foo/..)"},
Add a couple of fun unit tests for FileSpec::Equal Most of them fail right now and are commented out. The main problem is handling of backslashes on windows, but also the posix path code has a couple of issues. llvm-svn: 285393
2016-10-28 19:28:01 +08:00
};
Move FileSpecTest to Utility FileSpec class was moved to the Utility module a while ago, but the test file was left behind. This corrects that. llvm-svn: 330405
2018-04-20 16:27:27 +08:00
for (const auto &test : tests) {
[FileSystem] Move path resolution logic out of FileSpec This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
2018-11-02 05:05:36 +08:00
FileSpec one(test.first, FileSpec::Style::posix);
FileSpec two(test.second, FileSpec::Style::posix);
Always normalize FileSpec paths. Always normalizing lldb_private::FileSpec paths will help us get a consistent results from comparisons when setting breakpoints and when looking for source files. This also removes a lot of complexity from the comparison routines. Modified the DWARF line table parser to use the normalized compile unit directory if needed. Differential Revision: https://reviews.llvm.org/D45977 llvm-svn: 331049
2018-04-27 23:45:58 +08:00
EXPECT_EQ(one, two);
Improve ".." handling in FileSpec normalization Summary: .. handling for windows path was completely broken because the function was expecting \ as path separators, but we were passing it normalized file paths, where these have been replaced by forward slashes. Apart from this, the function was incorrect for posix paths as well in some corner cases, as well as being generally hard to follow. The corner cases were: - /../bar -> should be same as /bar - /bar/.. -> should be same as / (slightly dodgy as the former depends on /bar actually existing, but since we're doing it in an abstract way, I think the transformation is reasonable) I rewrite the function to fix these corner cases and handle windows paths more correctly. The function should now handle the posix paths (modulo symlinks, but we cannot really do anything about that without a real filesystem). For windows paths, there are a couple of corner cases left, mostly to do with drive letter handling, which cannot be fixed until the rest of the class understands drive letters better. Reviewers: clayborg, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D26081 llvm-svn: 285593
2016-11-01 00:22:07 +08:00
}
}
TEST(FileSpecTest, GetNormalizedPath) {
std::pair<const char *, const char *> posix_tests[] = {
Added a couple more odd dot patterns that we got out of clang. llvm-svn: 285977
2016-11-04 09:47:59 +08:00
{"/foo/.././bar", "/bar"},
{"/foo/./../bar", "/bar"},
Improve ".." handling in FileSpec normalization Summary: .. handling for windows path was completely broken because the function was expecting \ as path separators, but we were passing it normalized file paths, where these have been replaced by forward slashes. Apart from this, the function was incorrect for posix paths as well in some corner cases, as well as being generally hard to follow. The corner cases were: - /../bar -> should be same as /bar - /bar/.. -> should be same as / (slightly dodgy as the former depends on /bar actually existing, but since we're doing it in an abstract way, I think the transformation is reasonable) I rewrite the function to fix these corner cases and handle windows paths more correctly. The function should now handle the posix paths (modulo symlinks, but we cannot really do anything about that without a real filesystem). For windows paths, there are a couple of corner cases left, mostly to do with drive letter handling, which cannot be fixed until the rest of the class understands drive letters better. Reviewers: clayborg, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D26081 llvm-svn: 285593
2016-11-01 00:22:07 +08:00
{"/foo/../bar", "/bar"},
{"/foo/./bar", "/foo/bar"},
{"/foo/..", "/"},
{"/foo/.", "/foo"},
Fix handling of consecutive slashes in FileSpec::GetNormalizedPath() The core of the function was actually handling them correctly. However, the early exit was being too optimistic and did not give the function a chance to fire if the path did not contain dots as well. Fix that and add a couple of unit tests. llvm-svn: 288247
2016-12-01 00:08:45 +08:00
{"/foo//bar", "/foo/bar"},
{"/foo//bar/baz", "/foo/bar/baz"},
{"/foo//bar/./baz", "/foo/bar/baz"},
Improve ".." handling in FileSpec normalization Summary: .. handling for windows path was completely broken because the function was expecting \ as path separators, but we were passing it normalized file paths, where these have been replaced by forward slashes. Apart from this, the function was incorrect for posix paths as well in some corner cases, as well as being generally hard to follow. The corner cases were: - /../bar -> should be same as /bar - /bar/.. -> should be same as / (slightly dodgy as the former depends on /bar actually existing, but since we're doing it in an abstract way, I think the transformation is reasonable) I rewrite the function to fix these corner cases and handle windows paths more correctly. The function should now handle the posix paths (modulo symlinks, but we cannot really do anything about that without a real filesystem). For windows paths, there are a couple of corner cases left, mostly to do with drive letter handling, which cannot be fixed until the rest of the class understands drive letters better. Reviewers: clayborg, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D26081 llvm-svn: 285593
2016-11-01 00:22:07 +08:00
{"/./foo", "/foo"},
{"/", "/"},
Remove custom path manipulation functions from FileSpec Summary: now that llvm supports host-agnostic path manipulation functions (and most of their kinks have been ironed out), we can remove our copies of the path parsing functions in favour of the llvm ones. This should be NFC except for the slight difference in handling of the "//" path, which is now normalized to "/" (this only applies to the literal "//" path; "//net" and friends still get to keep the two slashes). Reviewers: zturner, clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D46687 llvm-svn: 332088
2018-05-11 19:55:34 +08:00
{"//", "/"},
Improve ".." handling in FileSpec normalization Summary: .. handling for windows path was completely broken because the function was expecting \ as path separators, but we were passing it normalized file paths, where these have been replaced by forward slashes. Apart from this, the function was incorrect for posix paths as well in some corner cases, as well as being generally hard to follow. The corner cases were: - /../bar -> should be same as /bar - /bar/.. -> should be same as / (slightly dodgy as the former depends on /bar actually existing, but since we're doing it in an abstract way, I think the transformation is reasonable) I rewrite the function to fix these corner cases and handle windows paths more correctly. The function should now handle the posix paths (modulo symlinks, but we cannot really do anything about that without a real filesystem). For windows paths, there are a couple of corner cases left, mostly to do with drive letter handling, which cannot be fixed until the rest of the class understands drive letters better. Reviewers: clayborg, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D26081 llvm-svn: 285593
2016-11-01 00:22:07 +08:00
{"//net", "//net"},
{"/..", "/"},
{"/.", "/"},
{"..", ".."},
FileSpec objects that resolve to "." should have "." in m_filename and m_directory empty. After switching to LLVM normalization, if we init FileSpec with "." we would end up with m_directory being NULL and m_filename being "". This patch fixes this by allowing the path to be normalized and if it normalized to nothing, set it to m_filename. Differential Revision: https://reviews.llvm.org/D46783 llvm-svn: 332618
2018-05-18 00:12:38 +08:00
{".", "."},
Improve ".." handling in FileSpec normalization Summary: .. handling for windows path was completely broken because the function was expecting \ as path separators, but we were passing it normalized file paths, where these have been replaced by forward slashes. Apart from this, the function was incorrect for posix paths as well in some corner cases, as well as being generally hard to follow. The corner cases were: - /../bar -> should be same as /bar - /bar/.. -> should be same as / (slightly dodgy as the former depends on /bar actually existing, but since we're doing it in an abstract way, I think the transformation is reasonable) I rewrite the function to fix these corner cases and handle windows paths more correctly. The function should now handle the posix paths (modulo symlinks, but we cannot really do anything about that without a real filesystem). For windows paths, there are a couple of corner cases left, mostly to do with drive letter handling, which cannot be fixed until the rest of the class understands drive letters better. Reviewers: clayborg, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D26081 llvm-svn: 285593
2016-11-01 00:22:07 +08:00
{"../..", "../.."},
FileSpec objects that resolve to "." should have "." in m_filename and m_directory empty. After switching to LLVM normalization, if we init FileSpec with "." we would end up with m_directory being NULL and m_filename being "". This patch fixes this by allowing the path to be normalized and if it normalized to nothing, set it to m_filename. Differential Revision: https://reviews.llvm.org/D46783 llvm-svn: 332618
2018-05-18 00:12:38 +08:00
{"foo/..", "."},
Improve ".." handling in FileSpec normalization Summary: .. handling for windows path was completely broken because the function was expecting \ as path separators, but we were passing it normalized file paths, where these have been replaced by forward slashes. Apart from this, the function was incorrect for posix paths as well in some corner cases, as well as being generally hard to follow. The corner cases were: - /../bar -> should be same as /bar - /bar/.. -> should be same as / (slightly dodgy as the former depends on /bar actually existing, but since we're doing it in an abstract way, I think the transformation is reasonable) I rewrite the function to fix these corner cases and handle windows paths more correctly. The function should now handle the posix paths (modulo symlinks, but we cannot really do anything about that without a real filesystem). For windows paths, there are a couple of corner cases left, mostly to do with drive letter handling, which cannot be fixed until the rest of the class understands drive letters better. Reviewers: clayborg, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D26081 llvm-svn: 285593
2016-11-01 00:22:07 +08:00
{"foo/../bar", "bar"},
{"../foo/..", ".."},
{"./foo", "foo"},
Always normalize FileSpec paths. Always normalizing lldb_private::FileSpec paths will help us get a consistent results from comparisons when setting breakpoints and when looking for source files. This also removes a lot of complexity from the comparison routines. Modified the DWARF line table parser to use the normalized compile unit directory if needed. Differential Revision: https://reviews.llvm.org/D45977 llvm-svn: 331049
2018-04-27 23:45:58 +08:00
{"././foo", "foo"},
{"../foo", "../foo"},
{"../../foo", "../../foo"},
Improve ".." handling in FileSpec normalization Summary: .. handling for windows path was completely broken because the function was expecting \ as path separators, but we were passing it normalized file paths, where these have been replaced by forward slashes. Apart from this, the function was incorrect for posix paths as well in some corner cases, as well as being generally hard to follow. The corner cases were: - /../bar -> should be same as /bar - /bar/.. -> should be same as / (slightly dodgy as the former depends on /bar actually existing, but since we're doing it in an abstract way, I think the transformation is reasonable) I rewrite the function to fix these corner cases and handle windows paths more correctly. The function should now handle the posix paths (modulo symlinks, but we cannot really do anything about that without a real filesystem). For windows paths, there are a couple of corner cases left, mostly to do with drive letter handling, which cannot be fixed until the rest of the class understands drive letters better. Reviewers: clayborg, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D26081 llvm-svn: 285593
2016-11-01 00:22:07 +08:00
};
for (auto test : posix_tests) {
Remove custom path manipulation functions from FileSpec Summary: now that llvm supports host-agnostic path manipulation functions (and most of their kinks have been ironed out), we can remove our copies of the path parsing functions in favour of the llvm ones. This should be NFC except for the slight difference in handling of the "//" path, which is now normalized to "/" (this only applies to the literal "//" path; "//net" and friends still get to keep the two slashes). Reviewers: zturner, clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D46687 llvm-svn: 332088
2018-05-11 19:55:34 +08:00
SCOPED_TRACE(llvm::Twine("test.first = ") + test.first);
Improve ".." handling in FileSpec normalization Summary: .. handling for windows path was completely broken because the function was expecting \ as path separators, but we were passing it normalized file paths, where these have been replaced by forward slashes. Apart from this, the function was incorrect for posix paths as well in some corner cases, as well as being generally hard to follow. The corner cases were: - /../bar -> should be same as /bar - /bar/.. -> should be same as / (slightly dodgy as the former depends on /bar actually existing, but since we're doing it in an abstract way, I think the transformation is reasonable) I rewrite the function to fix these corner cases and handle windows paths more correctly. The function should now handle the posix paths (modulo symlinks, but we cannot really do anything about that without a real filesystem). For windows paths, there are a couple of corner cases left, mostly to do with drive letter handling, which cannot be fixed until the rest of the class understands drive letters better. Reviewers: clayborg, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D26081 llvm-svn: 285593
2016-11-01 00:22:07 +08:00
EXPECT_EQ(test.second,
[FileSystem] Move path resolution logic out of FileSpec This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
2018-11-02 05:05:36 +08:00
FileSpec(test.first, FileSpec::Style::posix).GetPath());
Improve ".." handling in FileSpec normalization Summary: .. handling for windows path was completely broken because the function was expecting \ as path separators, but we were passing it normalized file paths, where these have been replaced by forward slashes. Apart from this, the function was incorrect for posix paths as well in some corner cases, as well as being generally hard to follow. The corner cases were: - /../bar -> should be same as /bar - /bar/.. -> should be same as / (slightly dodgy as the former depends on /bar actually existing, but since we're doing it in an abstract way, I think the transformation is reasonable) I rewrite the function to fix these corner cases and handle windows paths more correctly. The function should now handle the posix paths (modulo symlinks, but we cannot really do anything about that without a real filesystem). For windows paths, there are a couple of corner cases left, mostly to do with drive letter handling, which cannot be fixed until the rest of the class understands drive letters better. Reviewers: clayborg, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D26081 llvm-svn: 285593
2016-11-01 00:22:07 +08:00
}
std::pair<const char *, const char *> windows_tests[] = {
{R"(c:\bar\..\bar)", R"(c:\bar)"},
{R"(c:\bar\.\bar)", R"(c:\bar\bar)"},
{R"(c:\bar\..)", R"(c:\)"},
{R"(c:\bar\.)", R"(c:\bar)"},
{R"(c:\.\bar)", R"(c:\bar)"},
{R"(\)", R"(\)"},
Remove custom path manipulation functions from FileSpec Summary: now that llvm supports host-agnostic path manipulation functions (and most of their kinks have been ironed out), we can remove our copies of the path parsing functions in favour of the llvm ones. This should be NFC except for the slight difference in handling of the "//" path, which is now normalized to "/" (this only applies to the literal "//" path; "//net" and friends still get to keep the two slashes). Reviewers: zturner, clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D46687 llvm-svn: 332088
2018-05-11 19:55:34 +08:00
{R"(\\)", R"(\)"},
{R"(\\net)", R"(\\net)"},
Improve ".." handling in FileSpec normalization Summary: .. handling for windows path was completely broken because the function was expecting \ as path separators, but we were passing it normalized file paths, where these have been replaced by forward slashes. Apart from this, the function was incorrect for posix paths as well in some corner cases, as well as being generally hard to follow. The corner cases were: - /../bar -> should be same as /bar - /bar/.. -> should be same as / (slightly dodgy as the former depends on /bar actually existing, but since we're doing it in an abstract way, I think the transformation is reasonable) I rewrite the function to fix these corner cases and handle windows paths more correctly. The function should now handle the posix paths (modulo symlinks, but we cannot really do anything about that without a real filesystem). For windows paths, there are a couple of corner cases left, mostly to do with drive letter handling, which cannot be fixed until the rest of the class understands drive letters better. Reviewers: clayborg, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D26081 llvm-svn: 285593
2016-11-01 00:22:07 +08:00
{R"(c:\..)", R"(c:\)"},
{R"(c:\.)", R"(c:\)"},
Always normalize FileSpec paths. Always normalizing lldb_private::FileSpec paths will help us get a consistent results from comparisons when setting breakpoints and when looking for source files. This also removes a lot of complexity from the comparison routines. Modified the DWARF line table parser to use the normalized compile unit directory if needed. Differential Revision: https://reviews.llvm.org/D45977 llvm-svn: 331049
2018-04-27 23:45:58 +08:00
// TODO: fix llvm::sys::path::remove_dots() to return "\" below.
{R"(\..)", R"(\..)"},
Improve ".." handling in FileSpec normalization Summary: .. handling for windows path was completely broken because the function was expecting \ as path separators, but we were passing it normalized file paths, where these have been replaced by forward slashes. Apart from this, the function was incorrect for posix paths as well in some corner cases, as well as being generally hard to follow. The corner cases were: - /../bar -> should be same as /bar - /bar/.. -> should be same as / (slightly dodgy as the former depends on /bar actually existing, but since we're doing it in an abstract way, I think the transformation is reasonable) I rewrite the function to fix these corner cases and handle windows paths more correctly. The function should now handle the posix paths (modulo symlinks, but we cannot really do anything about that without a real filesystem). For windows paths, there are a couple of corner cases left, mostly to do with drive letter handling, which cannot be fixed until the rest of the class understands drive letters better. Reviewers: clayborg, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D26081 llvm-svn: 285593
2016-11-01 00:22:07 +08:00
// {R"(c:..)", R"(c:..)"},
{R"(..)", R"(..)"},
FileSpec objects that resolve to "." should have "." in m_filename and m_directory empty. After switching to LLVM normalization, if we init FileSpec with "." we would end up with m_directory being NULL and m_filename being "". This patch fixes this by allowing the path to be normalized and if it normalized to nothing, set it to m_filename. Differential Revision: https://reviews.llvm.org/D46783 llvm-svn: 332618
2018-05-18 00:12:38 +08:00
{R"(.)", R"(.)"},
Always normalize FileSpec paths. Always normalizing lldb_private::FileSpec paths will help us get a consistent results from comparisons when setting breakpoints and when looking for source files. This also removes a lot of complexity from the comparison routines. Modified the DWARF line table parser to use the normalized compile unit directory if needed. Differential Revision: https://reviews.llvm.org/D45977 llvm-svn: 331049
2018-04-27 23:45:58 +08:00
// TODO: fix llvm::sys::path::remove_dots() to return "c:\" below.
{R"(c:..\..)", R"(c:\..\..)"},
Improve ".." handling in FileSpec normalization Summary: .. handling for windows path was completely broken because the function was expecting \ as path separators, but we were passing it normalized file paths, where these have been replaced by forward slashes. Apart from this, the function was incorrect for posix paths as well in some corner cases, as well as being generally hard to follow. The corner cases were: - /../bar -> should be same as /bar - /bar/.. -> should be same as / (slightly dodgy as the former depends on /bar actually existing, but since we're doing it in an abstract way, I think the transformation is reasonable) I rewrite the function to fix these corner cases and handle windows paths more correctly. The function should now handle the posix paths (modulo symlinks, but we cannot really do anything about that without a real filesystem). For windows paths, there are a couple of corner cases left, mostly to do with drive letter handling, which cannot be fixed until the rest of the class understands drive letters better. Reviewers: clayborg, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D26081 llvm-svn: 285593
2016-11-01 00:22:07 +08:00
{R"(..\..)", R"(..\..)"},
FileSpec objects that resolve to "." should have "." in m_filename and m_directory empty. After switching to LLVM normalization, if we init FileSpec with "." we would end up with m_directory being NULL and m_filename being "". This patch fixes this by allowing the path to be normalized and if it normalized to nothing, set it to m_filename. Differential Revision: https://reviews.llvm.org/D46783 llvm-svn: 332618
2018-05-18 00:12:38 +08:00
{R"(foo\..)", R"(.)"},
Improve ".." handling in FileSpec normalization Summary: .. handling for windows path was completely broken because the function was expecting \ as path separators, but we were passing it normalized file paths, where these have been replaced by forward slashes. Apart from this, the function was incorrect for posix paths as well in some corner cases, as well as being generally hard to follow. The corner cases were: - /../bar -> should be same as /bar - /bar/.. -> should be same as / (slightly dodgy as the former depends on /bar actually existing, but since we're doing it in an abstract way, I think the transformation is reasonable) I rewrite the function to fix these corner cases and handle windows paths more correctly. The function should now handle the posix paths (modulo symlinks, but we cannot really do anything about that without a real filesystem). For windows paths, there are a couple of corner cases left, mostly to do with drive letter handling, which cannot be fixed until the rest of the class understands drive letters better. Reviewers: clayborg, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D26081 llvm-svn: 285593
2016-11-01 00:22:07 +08:00
{R"(foo\..\bar)", R"(bar)"},
{R"(..\foo\..)", R"(..)"},
{R"(.\foo)", R"(foo)"},
Always normalize FileSpec paths. Always normalizing lldb_private::FileSpec paths will help us get a consistent results from comparisons when setting breakpoints and when looking for source files. This also removes a lot of complexity from the comparison routines. Modified the DWARF line table parser to use the normalized compile unit directory if needed. Differential Revision: https://reviews.llvm.org/D45977 llvm-svn: 331049
2018-04-27 23:45:58 +08:00
{R"(.\.\foo)", R"(foo)"},
{R"(..\foo)", R"(..\foo)"},
{R"(..\..\foo)", R"(..\..\foo)"},
Improve ".." handling in FileSpec normalization Summary: .. handling for windows path was completely broken because the function was expecting \ as path separators, but we were passing it normalized file paths, where these have been replaced by forward slashes. Apart from this, the function was incorrect for posix paths as well in some corner cases, as well as being generally hard to follow. The corner cases were: - /../bar -> should be same as /bar - /bar/.. -> should be same as / (slightly dodgy as the former depends on /bar actually existing, but since we're doing it in an abstract way, I think the transformation is reasonable) I rewrite the function to fix these corner cases and handle windows paths more correctly. The function should now handle the posix paths (modulo symlinks, but we cannot really do anything about that without a real filesystem). For windows paths, there are a couple of corner cases left, mostly to do with drive letter handling, which cannot be fixed until the rest of the class understands drive letters better. Reviewers: clayborg, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D26081 llvm-svn: 285593
2016-11-01 00:22:07 +08:00
};
for (auto test : windows_tests) {
EXPECT_EQ(test.second,
[FileSystem] Move path resolution logic out of FileSpec This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
2018-11-02 05:05:36 +08:00
FileSpec(test.first, FileSpec::Style::windows).GetPath())
Improve ".." handling in FileSpec normalization Summary: .. handling for windows path was completely broken because the function was expecting \ as path separators, but we were passing it normalized file paths, where these have been replaced by forward slashes. Apart from this, the function was incorrect for posix paths as well in some corner cases, as well as being generally hard to follow. The corner cases were: - /../bar -> should be same as /bar - /bar/.. -> should be same as / (slightly dodgy as the former depends on /bar actually existing, but since we're doing it in an abstract way, I think the transformation is reasonable) I rewrite the function to fix these corner cases and handle windows paths more correctly. The function should now handle the posix paths (modulo symlinks, but we cannot really do anything about that without a real filesystem). For windows paths, there are a couple of corner cases left, mostly to do with drive letter handling, which cannot be fixed until the rest of the class understands drive letters better. Reviewers: clayborg, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D26081 llvm-svn: 285593
2016-11-01 00:22:07 +08:00
<< "Original path: " << test.first;
Add a couple of fun unit tests for FileSpec::Equal Most of them fail right now and are commented out. The main problem is handling of backslashes on windows, but also the posix path code has a couple of issues. llvm-svn: 285393
2016-10-28 19:28:01 +08:00
}
FileSpec: make matching separator-agnostic again Summary: In D18689, I removed the call to Normalize() in FileSpec::SetFile, because it no longer seemed needed, and it resolved a quirk in the FileSpec API (spec.GetCString() returnes a path with backslashes, but spec.GetDirectory().GetCString() has forward slashes). This turned out to be a problem because we would consider paths with different separators as different (which led to unresolved breakpoints for instance). Here, I am putting back in the call to Normalize() and adding a unittest for FileSpec::Equal. I am commenting out the GetDirectory unittests until we figure out the what is the expected behaviour here. Reviewers: zturner Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D19060 llvm-svn: 266286
2016-04-14 17:38:06 +08:00
}
Add methods to enable using formatv syntax in LLDB. This adds formatv-backed formatting functions in various places in LLDB such as StreamString, logging, constructing error messages, etc. A couple of callsites are changed from Printf style syntax to formatv style syntax to illustrate its usage. Additionally, a FileSpec formatter is introduced so that FileSpecs can be formatted natively. Differential Revision: https://reviews.llvm.org/D27632 llvm-svn: 289922
2016-12-16 12:27:00 +08:00
TEST(FileSpecTest, FormatFileSpec) {
FileSpec: Remove PathSyntax enum and use llvm version instead Summary: The llvm version of the enum has the same enumerators, with stlightly different names, so this is mostly just a search&replace exercise. One concrete benefit of this is that we can remove the function for converting between the two enums. To avoid typing llvm::sys::path::Style::windows everywhere I import the enum into the FileSpec class, so it can be referenced as FileSpec::Style::windows. Reviewers: zturner, clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D46753 llvm-svn: 332247
2018-05-14 22:52:47 +08:00
auto win = FileSpec::Style::windows;
Add methods to enable using formatv syntax in LLDB. This adds formatv-backed formatting functions in various places in LLDB such as StreamString, logging, constructing error messages, etc. A couple of callsites are changed from Printf style syntax to formatv style syntax to illustrate its usage. Additionally, a FileSpec formatter is introduced so that FileSpecs can be formatted natively. Differential Revision: https://reviews.llvm.org/D27632 llvm-svn: 289922
2016-12-16 12:27:00 +08:00
FileSpec F;
EXPECT_EQ("(empty)", llvm::formatv("{0}", F).str());
EXPECT_EQ("(empty)", llvm::formatv("{0:D}", F).str());
EXPECT_EQ("(empty)", llvm::formatv("{0:F}", F).str());
[FileSystem] Move path resolution logic out of FileSpec This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
2018-11-02 05:05:36 +08:00
F = FileSpec("C:\\foo\\bar.txt", win);
Add methods to enable using formatv syntax in LLDB. This adds formatv-backed formatting functions in various places in LLDB such as StreamString, logging, constructing error messages, etc. A couple of callsites are changed from Printf style syntax to formatv style syntax to illustrate its usage. Additionally, a FileSpec formatter is introduced so that FileSpecs can be formatted natively. Differential Revision: https://reviews.llvm.org/D27632 llvm-svn: 289922
2016-12-16 12:27:00 +08:00
EXPECT_EQ("C:\\foo\\bar.txt", llvm::formatv("{0}", F).str());
EXPECT_EQ("C:\\foo\\", llvm::formatv("{0:D}", F).str());
EXPECT_EQ("bar.txt", llvm::formatv("{0:F}", F).str());
[FileSystem] Move path resolution logic out of FileSpec This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
2018-11-02 05:05:36 +08:00
F = FileSpec("foo\\bar.txt", win);
Add methods to enable using formatv syntax in LLDB. This adds formatv-backed formatting functions in various places in LLDB such as StreamString, logging, constructing error messages, etc. A couple of callsites are changed from Printf style syntax to formatv style syntax to illustrate its usage. Additionally, a FileSpec formatter is introduced so that FileSpecs can be formatted natively. Differential Revision: https://reviews.llvm.org/D27632 llvm-svn: 289922
2016-12-16 12:27:00 +08:00
EXPECT_EQ("foo\\bar.txt", llvm::formatv("{0}", F).str());
EXPECT_EQ("foo\\", llvm::formatv("{0:D}", F).str());
EXPECT_EQ("bar.txt", llvm::formatv("{0:F}", F).str());
[FileSystem] Move path resolution logic out of FileSpec This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
2018-11-02 05:05:36 +08:00
F = FileSpec("foo", win);
Add methods to enable using formatv syntax in LLDB. This adds formatv-backed formatting functions in various places in LLDB such as StreamString, logging, constructing error messages, etc. A couple of callsites are changed from Printf style syntax to formatv style syntax to illustrate its usage. Additionally, a FileSpec formatter is introduced so that FileSpecs can be formatted natively. Differential Revision: https://reviews.llvm.org/D27632 llvm-svn: 289922
2016-12-16 12:27:00 +08:00
EXPECT_EQ("foo", llvm::formatv("{0}", F).str());
EXPECT_EQ("foo", llvm::formatv("{0:F}", F).str());
EXPECT_EQ("(empty)", llvm::formatv("{0:D}", F).str());
FileSpec: Fix PrependPathComponent("/") Summary: PrependPathComponent was unconditionally inserting path separators between the path components. This is not correct if the prepended path is "/", which caused problems down the line. Fix the function to use the same algorithm as AppendPathComponent and add a test. This fixes one part of llvm.org/pr31611. Reviewers: clayborg, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D28677 llvm-svn: 292100
2017-01-16 18:07:02 +08:00
}
Always normalize FileSpec paths. Always normalizing lldb_private::FileSpec paths will help us get a consistent results from comparisons when setting breakpoints and when looking for source files. This also removes a lot of complexity from the comparison routines. Modified the DWARF line table parser to use the normalized compile unit directory if needed. Differential Revision: https://reviews.llvm.org/D45977 llvm-svn: 331049
2018-04-27 23:45:58 +08:00
Fix PathMappingList for relative and empty paths after recent FileSpec normalization changes PathMappingList was broken for relative and empty paths after normalization changes in FileSpec. There were also no tests for PathMappingList so I added those. Changes include: Change PathMappingList::ReverseRemapPath() to take FileSpec objects instead of ConstString. The only client of this was doing work to convert to and from ConstString objects for no reason. Normalize all paths prefix and replacements that are added to the PathMappingList vector so they match the paths that have been already normalized in the debug info Unify code in the two forms of PathMappingList::RemapPath() so only one contains the actual functionality. Prior to this, there were two versions of this code. Use FileSpec::AppendPathComponent() and remove a long standing TODO so paths are correctly appended to each other. Added tests for absolute, relative and empty paths. Differential Revision: https://reviews.llvm.org/D47021 llvm-svn: 332842
2018-05-21 22:14:36 +08:00
TEST(FileSpecTest, IsRelative) {
llvm::StringRef not_relative[] = {
"/",
"/a",
"/a/",
"/a/b",
"/a/b/",
"//",
"//a/",
"//a/b",
"//a/b/",
"~",
"~/",
"~/a",
"~/a/",
"~/a/b"
"~/a/b/",
"/foo/.",
"/foo/..",
"/foo/../",
"/foo/../.",
};
for (const auto &path: not_relative) {
[FileSystem] Move path resolution logic out of FileSpec This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
2018-11-02 05:05:36 +08:00
FileSpec spec(path, FileSpec::Style::posix);
Fix PathMappingList for relative and empty paths after recent FileSpec normalization changes PathMappingList was broken for relative and empty paths after normalization changes in FileSpec. There were also no tests for PathMappingList so I added those. Changes include: Change PathMappingList::ReverseRemapPath() to take FileSpec objects instead of ConstString. The only client of this was doing work to convert to and from ConstString objects for no reason. Normalize all paths prefix and replacements that are added to the PathMappingList vector so they match the paths that have been already normalized in the debug info Unify code in the two forms of PathMappingList::RemapPath() so only one contains the actual functionality. Prior to this, there were two versions of this code. Use FileSpec::AppendPathComponent() and remove a long standing TODO so paths are correctly appended to each other. Added tests for absolute, relative and empty paths. Differential Revision: https://reviews.llvm.org/D47021 llvm-svn: 332842
2018-05-21 22:14:36 +08:00
EXPECT_FALSE(spec.IsRelative());
}
llvm::StringRef is_relative[] = {
".",
"./",
".///",
"a",
"./a",
"./a/",
"./a/",
"./a/b",
"./a/b/",
"../foo",
"foo/bar.c",
"./foo/bar.c"
};
for (const auto &path: is_relative) {
[FileSystem] Move path resolution logic out of FileSpec This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
2018-11-02 05:05:36 +08:00
FileSpec spec(path, FileSpec::Style::posix);
Fix PathMappingList for relative and empty paths after recent FileSpec normalization changes PathMappingList was broken for relative and empty paths after normalization changes in FileSpec. There were also no tests for PathMappingList so I added those. Changes include: Change PathMappingList::ReverseRemapPath() to take FileSpec objects instead of ConstString. The only client of this was doing work to convert to and from ConstString objects for no reason. Normalize all paths prefix and replacements that are added to the PathMappingList vector so they match the paths that have been already normalized in the debug info Unify code in the two forms of PathMappingList::RemapPath() so only one contains the actual functionality. Prior to this, there were two versions of this code. Use FileSpec::AppendPathComponent() and remove a long standing TODO so paths are correctly appended to each other. Added tests for absolute, relative and empty paths. Differential Revision: https://reviews.llvm.org/D47021 llvm-svn: 332842
2018-05-21 22:14:36 +08:00
EXPECT_TRUE(spec.IsRelative());
}
}
[FileSpec] Re-implmenet removeLastPathComponent When reading DBGSourcePathRemapping from a dSYM, we remove the last two path components to make the source lookup more general. However, when dealing with a relative path that has less than 2 components, we ended up with an invalid (empty) FileSpec. This patch changes the behavior of removeLastPathComponent to remove the last path component, if possible. It does this by checking whether a parent path exists, and if so using that as the new path. We rely entirely on LLVM's path implementation to do the heavy lifting. We now also return a boolean which indicates whether the operator was successful or not. Differential revision: https://reviews.llvm.org/D47495 rdar://37791687 llvm-svn: 333540
2018-05-30 21:03:16 +08:00
TEST(FileSpecTest, RemoveLastPathComponent) {
[FileSystem] Move path resolution logic out of FileSpec This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
2018-11-02 05:05:36 +08:00
FileSpec fs_posix("/foo/bar/baz", FileSpec::Style::posix);
[FileSpec] Re-implmenet removeLastPathComponent When reading DBGSourcePathRemapping from a dSYM, we remove the last two path components to make the source lookup more general. However, when dealing with a relative path that has less than 2 components, we ended up with an invalid (empty) FileSpec. This patch changes the behavior of removeLastPathComponent to remove the last path component, if possible. It does this by checking whether a parent path exists, and if so using that as the new path. We rely entirely on LLVM's path implementation to do the heavy lifting. We now also return a boolean which indicates whether the operator was successful or not. Differential revision: https://reviews.llvm.org/D47495 rdar://37791687 llvm-svn: 333540
2018-05-30 21:03:16 +08:00
EXPECT_STREQ("/foo/bar/baz", fs_posix.GetCString());
EXPECT_TRUE(fs_posix.RemoveLastPathComponent());
EXPECT_STREQ("/foo/bar", fs_posix.GetCString());
EXPECT_TRUE(fs_posix.RemoveLastPathComponent());
EXPECT_STREQ("/foo", fs_posix.GetCString());
EXPECT_TRUE(fs_posix.RemoveLastPathComponent());
EXPECT_STREQ("/", fs_posix.GetCString());
EXPECT_FALSE(fs_posix.RemoveLastPathComponent());
EXPECT_STREQ("/", fs_posix.GetCString());
[FileSystem] Move path resolution logic out of FileSpec This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
2018-11-02 05:05:36 +08:00
FileSpec fs_posix_relative("./foo/bar/baz", FileSpec::Style::posix);
[FileSpec] Re-implmenet removeLastPathComponent When reading DBGSourcePathRemapping from a dSYM, we remove the last two path components to make the source lookup more general. However, when dealing with a relative path that has less than 2 components, we ended up with an invalid (empty) FileSpec. This patch changes the behavior of removeLastPathComponent to remove the last path component, if possible. It does this by checking whether a parent path exists, and if so using that as the new path. We rely entirely on LLVM's path implementation to do the heavy lifting. We now also return a boolean which indicates whether the operator was successful or not. Differential revision: https://reviews.llvm.org/D47495 rdar://37791687 llvm-svn: 333540
2018-05-30 21:03:16 +08:00
EXPECT_STREQ("foo/bar/baz", fs_posix_relative.GetCString());
EXPECT_TRUE(fs_posix_relative.RemoveLastPathComponent());
EXPECT_STREQ("foo/bar", fs_posix_relative.GetCString());
EXPECT_TRUE(fs_posix_relative.RemoveLastPathComponent());
EXPECT_STREQ("foo", fs_posix_relative.GetCString());
EXPECT_FALSE(fs_posix_relative.RemoveLastPathComponent());
EXPECT_STREQ("foo", fs_posix_relative.GetCString());
[FileSystem] Move path resolution logic out of FileSpec This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
2018-11-02 05:05:36 +08:00
FileSpec fs_posix_relative2("./", FileSpec::Style::posix);
[FileSpec] Re-implmenet removeLastPathComponent When reading DBGSourcePathRemapping from a dSYM, we remove the last two path components to make the source lookup more general. However, when dealing with a relative path that has less than 2 components, we ended up with an invalid (empty) FileSpec. This patch changes the behavior of removeLastPathComponent to remove the last path component, if possible. It does this by checking whether a parent path exists, and if so using that as the new path. We rely entirely on LLVM's path implementation to do the heavy lifting. We now also return a boolean which indicates whether the operator was successful or not. Differential revision: https://reviews.llvm.org/D47495 rdar://37791687 llvm-svn: 333540
2018-05-30 21:03:16 +08:00
EXPECT_STREQ(".", fs_posix_relative2.GetCString());
EXPECT_FALSE(fs_posix_relative2.RemoveLastPathComponent());
EXPECT_STREQ(".", fs_posix_relative2.GetCString());
EXPECT_FALSE(fs_posix_relative.RemoveLastPathComponent());
EXPECT_STREQ(".", fs_posix_relative2.GetCString());
[FileSystem] Move path resolution logic out of FileSpec This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
2018-11-02 05:05:36 +08:00
FileSpec fs_windows("C:\\foo\\bar\\baz", FileSpec::Style::windows);
[FileSpec] Re-implmenet removeLastPathComponent When reading DBGSourcePathRemapping from a dSYM, we remove the last two path components to make the source lookup more general. However, when dealing with a relative path that has less than 2 components, we ended up with an invalid (empty) FileSpec. This patch changes the behavior of removeLastPathComponent to remove the last path component, if possible. It does this by checking whether a parent path exists, and if so using that as the new path. We rely entirely on LLVM's path implementation to do the heavy lifting. We now also return a boolean which indicates whether the operator was successful or not. Differential revision: https://reviews.llvm.org/D47495 rdar://37791687 llvm-svn: 333540
2018-05-30 21:03:16 +08:00
EXPECT_STREQ("C:\\foo\\bar\\baz", fs_windows.GetCString());
EXPECT_TRUE(fs_windows.RemoveLastPathComponent());
EXPECT_STREQ("C:\\foo\\bar", fs_windows.GetCString());
EXPECT_TRUE(fs_windows.RemoveLastPathComponent());
EXPECT_STREQ("C:\\foo", fs_windows.GetCString());
EXPECT_TRUE(fs_windows.RemoveLastPathComponent());
EXPECT_STREQ("C:\\", fs_windows.GetCString());
EXPECT_TRUE(fs_windows.RemoveLastPathComponent());
EXPECT_STREQ("C:", fs_windows.GetCString());
EXPECT_FALSE(fs_windows.RemoveLastPathComponent());
EXPECT_STREQ("C:", fs_windows.GetCString());
}