Commit Graph

6 Commits

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

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

Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere

Reviewed By: JDevlieghere

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

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D73258
2020-01-24 08:52:55 +01:00
Jonas Devlieghere
a4304f96d6 [lldb/CMake] Rename LLDB_DISABLE_CURSES to LLDB_ENABLE_CURSES
This matches the naming scheme used by LLVM.

Differential revision: https://reviews.llvm.org/D71377
2019-12-12 09:13:31 -08:00
Jonas Devlieghere
59998b7b7f [lldb/Host] Use Host/Config.h entries instead of a global define.
As suggested by Pavel in a code review:

> Can we replace this (and maybe python too, while at it) with a
> Host/Config.h entry? A global definition means that one has to
> recompile everything when these change in any way, whereas in
> practice only a handful of files need this..

Differential revision: https://reviews.llvm.org/D71280
2019-12-10 11:16:52 -08:00
Eric Christopher
5312139f77 Add a default copy-assignment or copy-constructor for -Wdeprecated-copy warnings. 2019-12-04 20:35:32 -08:00
Pavel Labath
532290e69f [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
2019-12-04 10:42:32 +01:00
Raphael Isemann
7caa17caf8 [lldb][NFC] Move Curses interface implementation to own file
Summary:
The IOHandler class source file is currently around 4600 LOC. However only 200
of these lines are concerned with the actual IOHandler class and the rest are the
implementations for Editline, IOHandlerConfirm and the Curses interface. All these
large features also cause that the IOHandler (which is in Core) has a large set of dependencies
on other parts of LLDB.

This patch splits out the code for the curses interface into its own file. This way
the simple IOHandler code is no longer buried in-between much larger functionalities.

Next up is splitting out the other IOHandlers into their own files and then move them
to more appropriate parts of LLDB.

Reviewers: labath, clayborg, JDevlieghere

Reviewed By: labath

Subscribers: mgorny, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D70946
2019-12-03 14:01:18 +01:00