IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
In CallFunc we currently always (intentionally and somewhat necessarily)
always fully specify member function template, however this can lead to
an ambiguity with a class template. For example in
roottest/cling/functionTemplate we get:
input_line_171:3:15: warning: lookup of 'set' in member access expression is ambiguous; using member of 't'
((t*)obj)->set<int>(*(int*)args[0]);
^
/local2/pcanal/cint_working/rootcling/root/roottest/cling/functionTemplate/t.h:19:9: note: lookup in the object type 't' refers here
void set(T targ) {
^
/usr/lib/gcc/x86_64-redhat-linux/4.4.5/../../../../include/c++/4.4.5/bits/stl_set.h:87:11: note: lookup from the current scope refers here
class set
^
This is an intention warning implemented in clang, see
http://llvm.org/viewvc/llvm-project?view=revision&revision=105518
This fixes a failure in pythoncintrun in roottest/cling/functionTemplate.
The problem was that the remapping happened on the first executeFunction, which
was fine. Now that we have the Transaction's empty wrapper functions removed it's
not enough.
NOTE: that any decls coming within the RuntimeUniverse.h which need 'managed'
storage will still trigger the same problem.
If we had:
struct MyClass {
void f() {}
}
MyClass::f(){} // expected error redefinition of f.
In that case we would have tried to remove the lookup entry for the decl from
the primary decl context of the lexical decl context, which entry doesn't exist.
It is registered in the semantic decl context of the decl itself.
When we tear down, the ExecutionContext must destroy all 'managed' addresses.
For example the LifetimeHandlers that came from the DynamicLookup. This needs
the interpreter to be in a 'sane' state, because they might call back the
Interpreter. For example gCling->execute("delete ...");
We don't need the intepreter to store clang's state. We can use a separate object
for that which allows to be reused.
Provide *much* shorter and cleaner implementation.
Implementation of .files moved in the Interpreter.cpp
storeState now calls three functions: dumpAST(), dumpLookup(), printIncludedFiles().
compareState now calls three functions: compareAST(), compareLookup(), compareIncludedFiles().
It's working for the included files and the AST, and it needs a new patch for
being able to dump the lookup tables (we cannot use dumpLookups() for the moment).
There are cases where cling needs to 'rollback' its state to a previous one.
Examples for that are cling's error recovery and code unloading. This can become
easily tricky to implement. One step reducing the complexity is the verification
of the 'interesting' data structures.
Implement .storeState and .compareState commands, which dump the internal compiler
data structures like AST (implemented), included files (in progress) and lookup
tables (unimplemented yet). The information is dumped into a file and then that
file is diff-ed to the one taken with .compareState. If they were identical all
files are deleted otherwise a .diff file with the differences remains for debug.
