Revert "[NFC] Improve FileSpec internal APIs and usage in preparation for adding caching of resolved/absolute." and follow-ups

This reverts commit 9429b67b8e300e638d7828bbcb95585f85c4df4d.

It broke

Revert "[NFC] Improve FileSpec internal APIs and usage in preparation for adding caching of resolved/absolute." and follow-ups

This reverts commit 9429b67b8e300e638d7828bbcb95585f85c4df4d.

It broke the build on Windows, see comments on https://reviews.llvm.org/D130309

It also reverts these follow-ups:

Revert "Fix buildbot breakage after https://reviews.llvm.org/D130309."
This reverts commit f959d815f4637890ebbacca379f1c38ab47e4e14.

Revert "Fix buildbot breakage after https://reviews.llvm.org/D130309."
This reverts commit 0bbce7a4c2d2bff622bdadd4323f93f5d90e6d24.

Revert "Cache the value for absolute path in FileSpec."
This reverts commit dabe877248b85b34878e75d5510339325ee087d0.

show more ...

Cache the value for absolute path in FileSpec.

Checking if a path is absolute can be expensive and currently the result is not cached in the FileSpec object. This patch adds caching and also code to

Cache the value for absolute path in FileSpec.

Checking if a path is absolute can be expensive and currently the result is not cached in the FileSpec object. This patch adds caching and also code to clear the cache if the file is modified.

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

show more ...

[NFC] Improve FileSpec internal APIs and usage in preparation for adding caching of resolved/absolute.

The FileSpect APIs allow users to modify instance variables directly by getting a non const ref

[NFC] Improve FileSpec internal APIs and usage in preparation for adding caching of resolved/absolute.

The FileSpect APIs allow users to modify instance variables directly by getting a non const reference to the directory and filename instance variables. This makes it impossibly to control all of the times the FileSpec object is modified so we can clear the cache. This patch modifies the APIs of FileSpec so no one can modify the directory or filename directly by adding set accessors and by removing the get accessors that are non const.

Many clients were using FileSpec::GetCString(...) which returned a unique C string from a ConstString'ified version of the result of GetPath() which returned a std::string. This caused many locations to use this convenient function incorrectly and could cause many strings to be added to the constant string pool that didn't need to. Most clients were converted to using FileSpec::GetPath().c_str() when possible. Other clients were modified to use the newly renamed version of this function which returns an actualy ConstString:
ConstString FileSpec::GetPathAsConstString(bool denormalize = true) const;

This avoids the issue where people were getting an already uniqued "const char *" that came from a ConstString only to put the "const char *" back into a "ConstString" object. By returning the ConstString instead of a "const char *" clients can be more efficient with the result.

The patch:
- Removes the non const GetDirectory() and GetFilename() get accessors
- Adds set accessors to replace the above functions: SetDirectory() and SetFilename().
- Adds ClearDirectory() and ClearFilename() to replace usage of the FileSpec::GetDirectory().Clear()/FileSpec::GetFilename().Clear() call sites
- Fixed all incorrect usage of FileSpec::GetCString() to use FileSpec::GetPath().c_str() where appropriate, and updated other call sites that wanted a ConstString to use the newly returned ConstString appropriately and efficiently.

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

show more ...

[lldb] Fix interpreting absolute Windows paths with forward slashes

In practice, Windows paths can use either backslashes or forward slashes.

This fixes an issue reported downstream at
https://gith

[lldb] Fix interpreting absolute Windows paths with forward slashes

In practice, Windows paths can use either backslashes or forward slashes.

This fixes an issue reported downstream at
https://github.com/mstorsjo/llvm-mingw/issues/266.

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

show more ...

[lldb] Fix windows path guessing for root paths

Fix recognizing "<letter>:\" as a windows path.

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

[lldb] Fix incorrect test data in FileSpecTest.IsRelative

Found by clang-tidy's bugprone-suspicious-missing-comma.

Update LLDB filespec tests for remove_dots change

It looks like the new implementation is correct, since there were TODOs
here about getting the new behavior.

I am not sure if "C:..\.." should beco

Update LLDB filespec tests for remove_dots change

It looks like the new implementation is correct, since there were TODOs
here about getting the new behavior.

I am not sure if "C:..\.." should become "C:" or "C:\", though. The new
output doesn't precisely match the TODO message, but it seems
appropriate given the specification of remove_dots and how .. traversals
work at the root directory.

show more ...

[lldb/Test] Add unittest for FileSpec::operator bool()

[lldb/Utility] Add YAML traits for ConstString and FileSpec.

Add YAML traits for the ConstString and FileSpec classes so they can be
serialized as part of ProcessInfo. The latter needs to be seriali

[lldb/Utility] Add YAML traits for ConstString and FileSpec.

Add YAML traits for the ConstString and FileSpec classes so they can be
serialized as part of ProcessInfo. The latter needs to be serializable
for the reproducers.

Differential revision: https://reviews.llvm.org/D76002

show more ...

[lldb][NFC] Fix all formatting errors in .cpp file headers

Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp ----------------------------------------

[lldb][NFC] Fix all formatting errors in .cpp file headers

Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp -------------------------------------------------===//
```
However in LLDB most of our source files have arbitrary changes to this format and
these changes are spreading through LLDB as folks usually just use the existing
source files as templates for their new files (most notably the unnecessary
editor language indicator `-*- C++ -*-` is spreading and in every review
someone is pointing out that this is wrong, resulting in people pointing out that this
is done in the same way in other files).

This patch removes most of these inconsistencies including the editor language indicators,
all the different missing/additional '-' characters, files that center the file name, missing
trailing `===//` (mostly caused by clang-format breaking the line).

Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere

Reviewed By: JDevlieghere

Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits

Tags: #lldb

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

show more ...

[lldb] s/FileSpec::Equal/FileSpec::Match

Summary:
The FileSpec class is often used as a sort of a pattern -- one specifies
a bare file name to search, and we check if in matches the full file
name o

[lldb] s/FileSpec::Equal/FileSpec::Match

Summary:
The FileSpec class is often used as a sort of a pattern -- one specifies
a bare file name to search, and we check if in matches the full file
name of an existing module (for example).

These comparisons used FileSpec::Equal, which had some support for it
(via the full=false argument), but it was not a good fit for this job.

For one, it did a symmetric comparison, which makes sense for a function
called "equal", but not for typical searches (when searching for
"/foo/bar.so", we don't want to find a module whose name is just
"bar.so"). This resulted in patterns like:
if (FileSpec::Equal(pattern, file, pattern.GetDirectory()))
which would request a "full" match only if the pattern really contained
a directory. This worked, but the intended behavior was very unobvious.

On top of that, a lot of the code wanted to handle the case of an
"empty" pattern, and treat it as matching everything. This resulted in
conditions like:
if (pattern && !FileSpec::Equal(pattern, file, pattern.GetDirectory())
which are nearly impossible to decipher.

This patch introduces a FileSpec::Match function, which does exactly
what most of FileSpec::Equal callers want, an asymmetric match between a
"pattern" FileSpec and a an actual FileSpec. Empty paterns match
everything, filename-only patterns match only the filename component.

I've tried to update all callers of FileSpec::Equal to use a simpler
interface. Those that hardcoded full=true have been changed to use
operator==. Those passing full=pattern.GetDirectory() have been changed
to use FileSpec::Match.

There was also a handful of places which hardcoded full=false. I've
changed these to use FileSpec::Match too. This is a slight change in
semantics, but it does not look like that was ever intended, and it was
more likely a result of a misunderstanding of the "proper" way to use
FileSpec::Equal.

[In an ideal world a "FileSpec" and a "FileSpec pattern" would be two
different types, but given how widespread FileSpec is, it is unlikely
we'll get there in one go. This at least provides a good starting point
by centralizing all matching behavior.]

Reviewers: teemperor, JDevlieghere, jdoerfert

Subscribers: emaste, lldb-commits

Tags: #lldb

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

show more ...

[lldb] Add FileSpec::Equal unit tests

this is in preparation of a refactor of this method.

[lldb] Simplify and improve FileSpecTest

Summary:
A most of these tests create FileSpecs with a hardcoded style. Add
utility functions which create a file spec of a given style to simplify
things.

[lldb] Simplify and improve FileSpecTest

Summary:
A most of these tests create FileSpecs with a hardcoded style. Add
utility functions which create a file spec of a given style to simplify
things.

While in there add SCOPED_TRACE messages to tests which loop over
multiple inputs to ensure it's clear which of the inputs failed.

Reviewers: teemperor

Subscribers: lldb-commits

Tags: #lldb

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

show more ...

Breakpad: auto-detect path style of file entries

Summary:
This adds support for auto-detection of path style to SymbolFileBreakpad
(similar to how r351328 did the same for DWARF). We guess each file

Breakpad: auto-detect path style of file entries

Summary:
This adds support for auto-detection of path style to SymbolFileBreakpad
(similar to how r351328 did the same for DWARF). We guess each file
entry separately, as we have no idea which file came from which compile
units (and different compile units can have different path styles). The
breakpad generates should have already converted the paths to absolute
ones, so this guess should be reasonable accurate, but as always with
these kinds of things, it is hard to give guarantees about anything.

In an attempt to bring some unity to the path guessing logic, I move the
guessing logic from inside SymbolFileDWARF into the FileSpec class and
have both symbol files use it to implent their desired behavior.

Reviewers: clayborg, lemo, JDevlieghere

Subscribers: aprantl, markmentovai, lldb-commits

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

llvm-svn: 353702

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

[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

[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

show more ...

[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
hel

[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

show more ...

[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

[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

show more ...

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 we

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

show more ...

Fix buildbots after it 332618

llvm-svn: 332633

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 N

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

show more ...

Revert 332511 after reverting llvm revision 332508.

llvm-svn: 332556

Fix FileSpecTest after LLVM changes to remove_dots (https://reviews.llvm.org/D46887)

llvm-svn: 332511

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

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

show more ...

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 co

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

show more ...