Move the column marking functionality to the Highlighter framework

Summary:
The syntax highlighting feature so far is mutually exclusive with the lldb feature
that marks the current column in the li

Move the column marking functionality to the Highlighter framework

Summary:
The syntax highlighting feature so far is mutually exclusive with the lldb feature
that marks the current column in the line by underlining it via an ANSI color code.
Meaning that if you enable one, the other is automatically disabled by LLDB.

This was caused by the fact that both features inserted color codes into the the
source code and were likely to interfere with each other (which would result
in a broken source code printout to the user).

This patch moves the cursor code into the highlighting framework, which provides
the same feature to the user in normal non-C source code. For any source code
that is highlighted by Clang, we now also have cursor marking for the whole token
that is under the current source location. E.g., before we underlined only the '!' in the
expression '1 != 2', but now the whole token '!=' is underlined. The same for function
calls and so on. Below you can see two examples where we before only underlined
the first character of the token, but now underline the whole token.

{F7075400}
{F7075414}

It also simplifies the DisplaySourceLines method in the SourceManager as most of
the code in there was essentially just for getting this column marker to work as
a FormatEntity.

Reviewers: aprantl

Reviewed By: aprantl

Subscribers: lldb-commits

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

llvm-svn: 341003

show more ...

Remove manual byte counting from Highlighter code.

Summary:
This removes the manual byte counting mechanism from the syntax highlighting
code. This is no longer necessary as the Stream class now has

Remove manual byte counting from Highlighter code.

Summary:
This removes the manual byte counting mechanism from the syntax highlighting
code. This is no longer necessary as the Stream class now has built-in support for
automatically counting the bytes that were written to it so far.

The advantage of automatic byte counting via Stream is that it is less error-prone
than the manual version and we need to write less boilerplate code.

Reviewers: labath

Reviewed By: labath

Subscribers: labath, lldb-commits

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

llvm-svn: 339695

show more ...

[LLDB] Added syntax highlighting support

Summary:
This patch adds syntax highlighting support to LLDB. When enabled (and lldb is allowed
to use colors), printed source code is annotated with the ANS

[LLDB] Added syntax highlighting support

Summary:
This patch adds syntax highlighting support to LLDB. When enabled (and lldb is allowed
to use colors), printed source code is annotated with the ANSI color escape sequences.

So far we have only one highlighter which is based on Clang and is responsible for all
languages that are supported by Clang. It essentially just runs the raw lexer over the input
and then surrounds the specific tokens with the configured escape sequences.

Reviewers: zturner, davide

Reviewed By: davide

Subscribers: labath, teemperor, llvm-commits, mgorny, lldb-commits

Tags: #lldb

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

llvm-svn: 338662

show more ...

Reflow paragraphs in comments.

This is intended as a clean up after the big clang-format commit
(r280751), which unfortunately resulted in many of the comment
paragraphs in LLDB being very hard to r

Reflow paragraphs in comments.

This is intended as a clean up after the big clang-format commit
(r280751), which unfortunately resulted in many of the comment
paragraphs in LLDB being very hard to read.

FYI, the script I used was:

import textwrap
import commands
import os
import sys
import re
tmp = "%s.tmp"%sys.argv[1]
out = open(tmp, "w+")
with open(sys.argv[1], "r") as f:
header = ""
text = ""
comment = re.compile(r'^( *//) ([^ ].*)$')
special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$')
for line in f:
match = comment.match(line)
if match and not special.match(match.group(2)):
# skip intentionally short comments.
if not text and len(match.group(2)) < 40:
out.write(line)
continue

if text:
text += " " + match.group(2)
else:
header = match.group(1)
text = match.group(2)

continue

if text:
filled = textwrap.wrap(text, width=(78-len(header)),
break_long_words=False)
for l in filled:
out.write(header+" "+l+'\n')
text = ""

out.write(line)

os.rename(tmp, sys.argv[1])

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

llvm-svn: 331197

show more ...

iwyu fixes for lldbCore.

This adjusts header file includes for headers and source files
in Core. In doing so, one dependency cycle is eliminated
because all the includes from Core to that project w

iwyu fixes for lldbCore.

This adjusts header file includes for headers and source files
in Core. In doing so, one dependency cycle is eliminated
because all the includes from Core to that project were dead
includes anyway. In places where some files in other projects
were only compiling due to a transitive include from another
header, fixups have been made so that those files also include
the header they need. Tested on Windows and Linux, and plan
to address failures on OSX and FreeBSD after watching the
bots.

llvm-svn: 299714

show more ...

Remove FileSpec::ReadFileContents.

This functionality is subsumed by DataBufferLLVM, which is
also more efficient since it will try to mmap. However, we
don't yet support mmaping writable private s

Remove FileSpec::ReadFileContents.

This functionality is subsumed by DataBufferLLVM, which is
also more efficient since it will try to mmap. However, we
don't yet support mmaping writable private sections, and in
some cases we were using ReadFileContents and then modifying
the buffer. To address that I've added a flag to the
DataBufferLLVM methods that allow you to map privately, which
disables the mmaping path entirely. Eventually we should teach
DataBufferLLVM to use mmap with writable private, but that is
orthogonal to this effort.

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

llvm-svn: 297095

show more ...

Move DataBuffer / DataExtractor and friends from Core -> Utility.

llvm-svn: 296943

Move classes from Core -> Utility.

This moves the following classes from Core -> Utility.

ConstString
Error
RegularExpression
Stream
StreamString

The goal here is to get lldbUtility into a state w

Move classes from Core -> Utility.

This moves the following classes from Core -> Utility.

ConstString
Error
RegularExpression
Stream
StreamString

The goal here is to get lldbUtility into a state where it has
no dependendencies except on itself and LLVM, so it can be the
starting point at which to start untangling LLDB's dependencies.
These are all low level and very widely used classes, and
previously lldbUtility had dependencies up to lldbCore in order
to use these classes. So moving then down to lldbUtility makes
sense from both the short term and long term perspective in
solving this problem.

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

llvm-svn: 293941

show more ...

Remove TimeValue usage from lldb/Core. NFC.

llvm-svn: 286366

Remove TimeValue usage from FileSpec.h

Summary:
The only usage there was in GetModificationTime(). I also took the opportunity
to move this function from FileSpec to the FileSystem class - since we

Remove TimeValue usage from FileSpec.h

Summary:
The only usage there was in GetModificationTime(). I also took the opportunity
to move this function from FileSpec to the FileSystem class - since we are
using FileSpecs to also represent remote files for which we cannot (easily)
retrieve modification time, it makes sense to make the decision to get the
modification time more explicit.

The new function returns a llvm::sys::TimePoint<>. To aid the transition
from TimeValue, I have added a constructor to it which enables implicit
conversion from a time_point.

Reviewers: zturner, clayborg

Subscribers: mehdi_amini, tberghammer, danalbert, beanz, mgorny, lldb-commits

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

llvm-svn: 285702

show more ...

Make lldb -Werror clean on Windows.

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

llvm-svn: 283344

Fix for loop sign fix in r282112 for column = 0

llvm-svn: 282119

Fix integer sign warning from r282105

llvm-svn: 282112

add stop column highlighting support

This change introduces optional marking of the column within a source
line where a thread is stopped. This marking will show up when the
source code for a threa

add stop column highlighting support

This change introduces optional marking of the column within a source
line where a thread is stopped. This marking will show up when the
source code for a thread stop is displayed, when the debug info
knows the column information, and if the optional column marking is
enabled.

There are two separate methods for handling the marking of the stop
column:

* via ANSI terminal codes, which are added inline to the source line
display. The default ANSI mark-up is to underline the column.

* via a pure text-based caret that is added in the appropriate column
in a newly-inserted blank line underneath the source line in
question.

There are some new options that control how this all works.

* settings set stop-show-column

This takes one of 4 values:

* ansi-or-caret: use the ANSI terminal code mechanism if LLDB
is running with color enabled; if not, use the caret-based,
pure text method (see the "caret" mode below).

* ansi: only use the ANSI terminal code mechanism to highlight
the stop line. If LLDB is running with color disabled, no
stop column marking will occur.

* caret: only use the pure text caret method, which introduces
a newly-inserted line underneath the current line, where
the only character in the new line is a caret that highlights
the stop column in question.

* none: no stop column marking will be attempted.

* settings set stop-show-column-ansi-prefix

This is a text format that indicates the ANSI formatting
code to insert into the stream immediately preceding the
column where the stop column character will be marked up.
It defaults to ${ansi.underline}; however, it can contain
any valid LLDB format codes, e.g.

${ansi.fg.red}${ansi.bold}${ansi.underline}

* settings set stop-show-column-ansi-suffix

This is the text format that specifies the ANSI terminal
codes to end the markup that was started with the prefix
described above. It defaults to: ${ansi.normal}. This
should be sufficient for the common cases.

Significant leg-work was done by Adrian Prantl. (Thanks, Adrian!)

differential review: https://reviews.llvm.org/D20835

reviewers: clayborg, jingham
llvm-svn: 282105

show more ...

Make lldb::Regex use StringRef.

This updates getters and setters to use StringRef instead of
const char *. I tested the build on Linux, Windows, and OSX
and saw no build or test failures. I cannot

Make lldb::Regex use StringRef.

This updates getters and setters to use StringRef instead of
const char *. I tested the build on Linux, Windows, and OSX
and saw no build or test failures. I cannot test any BSD
or Android variants, however I expect the required changes
to be minimal or non-existant.

llvm-svn: 282079

show more ...

*** 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 t

*** 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

show more ...

Silence some MSVC warnings.

Summary:
Just `assert("string" && false)` instead of `assert("string" == NULL)`.

This avoid errors like

[...]\Core\SourceManager.cpp(647): warning C4130: '==' : log

Silence some MSVC warnings.

Summary:
Just `assert("string" && false)` instead of `assert("string" == NULL)`.

This avoid errors like

[...]\Core\SourceManager.cpp(647): warning C4130: '==' : logical operation on address of string constant

Reviewers: zturner

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D12388

llvm-svn: 246123

show more ...

Final bit of type system cleanup that abstracts declaration contexts into lldb_private::CompilerDeclContext and renames ClangType to CompilerType in many accessors and functions.

Create a new "lldb_

Final bit of type system cleanup that abstracts declaration contexts into lldb_private::CompilerDeclContext and renames ClangType to CompilerType in many accessors and functions.

Create a new "lldb_private::CompilerDeclContext" class that will replace all direct uses of "clang::DeclContext" when used in compiler agnostic code, yet still allow for conversion to clang::DeclContext subclasses by clang specific code. This completes the abstraction of type parsing by removing all "clang::" references from the SymbolFileDWARF. The new "lldb_private::CompilerDeclContext" class abstracts decl contexts found in compiler type systems so they can be used in internal API calls. The TypeSystem is required to support CompilerDeclContexts with new pure virtual functions that start with "DeclContext" in the member function names. Converted all code that used lldb_private::ClangNamespaceDecl over to use the new CompilerDeclContext class and removed the ClangNamespaceDecl.cpp and ClangNamespaceDecl.h files.

Removed direct use of clang APIs from SBType and now use the abstract type systems to correctly explore types.

Bulk renames for things that used to return a ClangASTType which is now CompilerType:

"Type::GetClangFullType()" to "Type::GetFullCompilerType()"
"Type::GetClangLayoutType()" to "Type::GetLayoutCompilerType()"
"Type::GetClangForwardType()" to "Type::GetForwardCompilerType()"
"Value::GetClangType()" to "Value::GetCompilerType()"
"Value::SetClangType (const CompilerType &)" to "Value::SetCompilerType (const CompilerType &)"
"ValueObject::GetClangType ()" to "ValueObject::GetCompilerType()"
many more renames that are similar.

llvm-svn: 245905

show more ...

Centralize where we update the source file contents in SourceManager::GetFile() in case APIs are called that don't update the source.

The following functions were the only functions that updates the

Centralize where we update the source file contents in SourceManager::GetFile() in case APIs are called that don't update the source.

The following functions were the only functions that updates the source file:

SourceManager::File::DisplaySourceLines()
SourceManager::File::FindLinesMatchingRegex()

But there we API calls that were using the SourceManager::File and asking it questions, like "is line 12 valid" and that might respond incorrectly if the source file had been updated.

<rdar://problem/21269402>

llvm-svn: 243551

show more ...

Don't #include "lldb-python.h" from anywhere.

Since interaction with the python interpreter is moving towards
being more isolated, we won't be able to include this header from
normal files anymore,

Don't #include "lldb-python.h" from anywhere.

Since interaction with the python interpreter is moving towards
being more isolated, we won't be able to include this header from
normal files anymore, all includes of it should be localized to
the python library which will live under source/bindings/API/Python
after a future patch.

None of the files that were including this header actually depended
on it anyway, so it was just a dead include in every single instance.

llvm-svn: 238581

show more ...

Further reduce header footprint of Debugger.h.

llvm-svn: 231202

Fix the missleading indentation. Fix CID 1096332

llvm-svn: 215893

Merging the iohandler branch back into main.

The many many benefits include:
1 - Input/Output/Error streams are now handled as real streams not a push style input
2 - auto completion in python embe

Merging the iohandler branch back into main.

The many many benefits include:
1 - Input/Output/Error streams are now handled as real streams not a push style input
2 - auto completion in python embedded interpreter
3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use
4 - it is now possible to use curses to drive LLDB (please try the "gui" command)

We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases.

llvm-svn: 200263

show more ...

Fix a bunch of compile time warnings and a build failure on ubuntu.

llvm-svn: 189683

<rdar://problem/13443931>

Fixed a crasher in the SourceManager where it wasn't checking the m_target member variable for NULL.

In doing this fix, I hardened this class to have weak pointers to the

<rdar://problem/13443931>

Fixed a crasher in the SourceManager where it wasn't checking the m_target member variable for NULL.

In doing this fix, I hardened this class to have weak pointers to the debugger and target in case they do go away. I also changed SBSourceManager to hold onto weak pointers to the debugger and target so they don't keep objects alive by holding a strong reference to them.

llvm-svn: 177365

show more ...