Commit Graph

10 Commits

Author SHA1 Message Date
Zachary Turner 6f9e690199 Move Log from Core -> Utility.
All references to Host and Core have been removed, so this
class can now safely be lowered into Utility.

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

llvm-svn: 296909
2017-03-03 20:56:28 +00:00
Richard Smith 2245293541 Update to match clang r291737.
llvm-svn: 291738
2017-01-12 02:37:54 +00:00
Kate Stone b9c1b51e45 *** 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-06 20:57:50 +00:00
Jim Ingham 3a45e03442 Check whether Sema::CreateBuiltinUnaryOp returns an empty result.
If it does, calling AddInitializerToDecl will crash, so we should
abort the result synthesis in this case.

<rdar://problem/27205383>

llvm-svn: 274787
2016-07-07 19:06:37 +00:00
Jim Ingham bed6779c7a Add an "experimental" setting to disable injecting local variables into expressions.
This feature was added to solve a lookup problem in expressions when local variables
shadow ivars.  That solution requires fully realizing all local variables to evaluate
any expression, and can cause significant performance problems when evaluating 
expressions in frames that have many complex locals.

Until we get a better solution, this setting mitigates the problem when you don't
have local variables that shadow ivars.

<rdar://problem/27226122>

llvm-svn: 274783
2016-07-07 18:25:48 +00:00
Sean Callanan 00294b34a3 Backend support for top-level Clang epxressions
This patch adds a new ExecutionPolicy, eExecutionPolicyTopLevel, which
tells the expression parser that the expression should be JITted as top
level code but nothing (except static initializers) should be run.  I
have modified the Clang expression parser to recognize this execution
policy.  On top of the existing patches that support storing IR and
maintaining a map of arbitrary Decls, this is mainly just patching up a
few places in the expression parser.

I intend to submit a patch for review that exposes this functionality
through the "expression" command and through the SB API.  That patch
also includes a testcase for all of this.

<rdar://problem/22864976>

llvm-svn: 264095
2016-03-22 21:05:51 +00:00
Sean Callanan b3a36df39e Handle any persistent Decl in the Clang expression parser, not just types.
Persistent decls have traditionally only been types.  However, we want to
be able to persist more things, like functions and global variables.  This
changes some of the nomenclature and the lookup rules to make this possible.

<rdar://problem/22864976>

llvm-svn: 263864
2016-03-19 00:51:43 +00:00
Sean Callanan b92bd7538e Made Target hold a map of languages to TypeSystems, and added some accessors.
Also added some target-level search functions so that persistent variables and
symbols can be searched for without hand-iterating across the map of
TypeSystems.

llvm-svn: 249027
2015-10-01 16:28:02 +00:00
Sean Callanan 8f1f9a1be3 Now persistent expression data no longer lives with the Target, but rather with
the corresponding TypeSystem.  This makes sense because what kind of data there
is -- and how it can be looked up -- depends on the language.

Functionality that is common to all type systems is factored out into
PersistentExpressionState.

llvm-svn: 248934
2015-09-30 19:57:57 +00:00
Sean Callanan 4dbb271fcc Moved more Clang-specific parts of the expression parser into the Clang plugin.
There are still a bunch of dependencies on the plug-in, but this helps to
identify them.
There are also a few more bits we need to move (and abstract, for example the
ClangPersistentVariables).

llvm-svn: 248612
2015-09-25 20:35:58 +00:00