This applies the same trick for Lua that I did for python in
27b6a4e63afe.

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

FileSpec::GetFileNameExtension returns a StringRef. In some cases we
are calling it and then storing the result in a local. To prevent
cases where we store the StringRef, mutate the Filespec, and then try to
use the stored StringRef afterwards, I've audited the callsites and made
adjustments to mitigate: Either marking the FileSpec it comes from as
const (to avoid mutations) or by not storing the StringRef in a local if
it makes sense not to.

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

These don't really need to be in ConstStrings. It's nice that comparing
ConstStrings is fast (just a pointer comparison) but the cost of
creating the ConstString usually already includes the cost of doing a
StringRef comparison anyway, so this is just extra work and extra memory
consumption for basically no benefit.

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

StructuredDataImpl ownership semantics is unclear at best. Various
structures were holding a non-owning pointer to it, with a comment that
the object is owned somewhere else. From what I was able to gather that
"somewhere else" was the SBStructuredData object, but I am not sure that
all created object eventually made its way there. (It wouldn't matter
even if they did, as we are leaking most of our SBStructuredData
objects.)

Since StructuredDataImpl is just a collection of two (shared) pointers,
there's really no point in elaborate lifetime management, so this patch
replaces all StructuredDataImpl pointers with actual objects or
unique_ptrs to it. This makes it much easier to resolve SBStructuredData
leaks in a follow-up patch.

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

This is the lua equivalent of 9a14adeae0.

Add support for Lua scripted watchpoints, with basic tests.

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

Adds support for running a Lua function when a breakpoint is hit.

Example:
   breakpoint command add -s lua -F abc

The above runs the Lua function 'abc' passing 2 arguments. 'frame', 'bp_loc' and 'extra_args'.

A third parameter 'extra_args' is only present when there is structured data
declared in the command line.

Example:
   breakpoint command add -s lua -F abc -k foo -v bar

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

1 - Partial Statements

The interpreter loop runs every line it receives, so partial
Lua statements are not being handled properly. This is a problem for
multiline breakpoint scripts since the interpreter loop, for this
particular case, is just an abstraction to a partially parsed function
body declaration.

This patch addresses this issue and as a side effect improves the
general Lua interpreter loop as well. It's now possible to write partial
statements in the 'script' command.

Example:
   (lldb) script
   >>>   do
   ..>   local a = 123
   ..>   print(a)
   ..>   end
   123

The technique implemented is the same as the one employed by Lua's own REPL implementation.
Partial statements always errors out with the '<eof>' tag in the error
message.

2 - CheckSyntax in Lua.h

In order to support (1), we need an API for just checking the syntax of string buffers.

3 - Multiline scripted breakpoints

Finally, with all the base features implemented this feature is
straightforward. The interpreter loop behaves exactly the same, the
difference is that it will aggregate all Lua statements into the body of
the breakpoint function. An explicit 'quit' statement is needed to exit the
interpreter loop.

Example:
   (lldb) breakpoint command add -s lua
   Enter your Lua command(s). Type 'quit' to end.
   The commands are compiled as the body of the following Lua function
   function (frame, bp_loc, ...) end
   ..> print(456)
   ..> a = 123
   ..> quit

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

LLDB is ignoring compilation errors for one-line breakpoint scripts.
This patch fixes the issues and now the error message of the
ScriptInterpreter is shown to the user.

I had to remove a new-line character for the Lua interpreter since it
was duplicated.

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

These callbacks are set using the following:
   breakpoint command add -s lua -o "print('hello world!')"

The user supplied script is executed as:
   function (frame, bp_loc, ...)
      <body>
   end

So the local variables 'frame', 'bp_loc' and vararg are all accessible.
Any global variables declared will persist in the Lua interpreter.
A user should never hold 'frame' and 'bp_loc' in a global variable as
these userdatas are context dependent.

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