Age | Commit message (Collapse) | Author |
|
A lot of comments in LLDB are surrounded by an ASCII line to delimit the
begging and end of the comment.
Its use is not really consistent across the code base, sometimes the
lines are longer, sometimes they are shorter and sometimes they are
omitted. Furthermore, it looks kind of weird with the 80 column limit,
where the comment actually extends past the line, but not by much.
Furthermore, when /// is used for Doxygen comments, it looks
particularly odd. And when // is used, it incorrectly gives the
impression that it's actually a Doxygen comment.
I assume these lines were added to improve distinguishing between
comments and code. However, given that todays editors and IDEs do a
great job at highlighting comments, I think it's worth to drop this for
the sake of consistency. The alternative is fixing all the
inconsistencies, which would create a lot more churn.
Differential revision: https://reviews.llvm.org/D60508
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@358135 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This was found by the green dragon sanitizer bot.
rdar://problem/48536644
Differential Revision: https://reviews.llvm.org/D59314
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@356090 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This changes '@' prefix to '\'.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@355841 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@351636 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This patch removes the comments grouping header includes. They were
added after running IWYU over the LLDB codebase. However they add little
value, are often outdates and burdensome to maintain.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@346626 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This brings the LLDB configuration closer to LLVM's and removes visual
clutter in the source code by removing the @brief commands from
comments.
This patch also reflows the paragraphs in all doxygen comments.
See also https://reviews.llvm.org/D46290.
Differential Revision: https://reviews.llvm.org/D46321
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@331373 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
These methods can be used by the derived expression types to perform expression
specific and/or language specific actions before and after the expression runs.
(ThreadPlanCallUserExpression is modified to call these methods on the
expression immediately before/after execution of the expression).
The immediate motivation is allowing Swift expressions to notify the swift
runtime that exclusivity enforcement should be suspended while the expression
runs (we want LLDB expressions to be able to access variables even when they're
considered exclusively owned by someone else in the original program).
Reviewed in https://reviews.llvm.org/D32889
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@302314 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
*** 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.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@280751 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
UserExpression. This
isn't used in this commit but will be in a future commit.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@251887 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13018
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@248176 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
that lldb currently vends.
Before we had:
ClangFunction
ClangUtilityFunction
ClangUserExpression
and code all over in lldb that explicitly made Clang-based expressions. This patch adds an Expression
base class, and three pure virtual implementations for the Expression kinds:
FunctionCaller
UtilityFunction
UserExpression
You can request one of these expression types from the Target using the Get<ExpressionType>ForLanguage.
The Target will then consult all the registered TypeSystem plugins, and if the type system that matches
the language can make an expression of that kind, it will do so and return it.
Because all of the real expression types need to communicate with their ExpressionParser in a uniform way,
I also added a ExpressionTypeSystemHelper class that expressions generically can vend, and a ClangExpressionHelper
that encapsulates the operations that the ClangExpressionParser needs to perform on the ClangExpression types.
Then each of the Clang* expression kinds constructs the appropriate helper to do what it needs.
The patch also fixes a wart in the UtilityFunction that to use it you had to create a parallel FunctionCaller
to actually call the function made by the UtilityFunction. Now the UtilityFunction can be asked to vend a
FunctionCaller that will run its function. This cleaned up a lot of boiler plate code using UtilityFunctions.
Note, in this patch all the expression types explicitly depend on the LLVM JIT and IR, and all the common
JIT running code is in the FunctionCaller etc base classes. At some point we could also abstract that dependency
but I don't see us adding another back end in the near term, so I'll leave that exercise till it is actually necessary.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@247720 91177308-0d34-0410-b5e6-96231b3b80d8
|