callers had to do this by hand and we ended up never actually adding initial arguments and then
reusing them by passing in the struct address separately, so the distinction wasn't needed.
llvm-svn: 252108
The Go interpreter doesn't JIT or use LLVM, so this also
moves all the JIT related code from UserExpression to a new class LLVMUserExpression.
Differential Revision: http://reviews.llvm.org/D13073
Fix merge
llvm-svn: 251820
The concept here is that languages may have different ways of communicating
results. In particular, languages may have different names for their result
variables and in fact may have multiple types of result variables (e.g.,
error results). Materializer was tied to one specific model of result handling.
Instead, now UserExpressions can register their own handlers for the result
variables they inject. This allows language-specific code in Materializer to
be moved into the expression parser plug-in, and it simplifies Materializer.
These delegates are subclasses of PersistentVariableDelegate.
PersistentVariableDelegate can provide the name of the result variable, and is
notified when the result variable is populated. It can also be used to touch
persistent variables if need be, updating language-specific state. The
UserExpression owns the delegate and can decide on its result based on
consulting all of its (potentially multiple) delegates.
The user expression itself now makes the determination of what the final result
of the expression is, rather than relying on the Materializer, and I've added a
virtual function to UserExpression to allow this.
llvm-svn: 249233
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
Jim Ingham