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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Here we don't want to depend on the JIT runFunction, because of its limitations,
when it comes to return value handling. There it is not clear who provides the
storage and who cleans it up in a platform independent way.
Depending on the type we need to synthesize a call to cling:
0) void : do nothing;
1) enum, integral, float, double, referece, pointer types :
call to cling::internal::setValueNoAlloc(...);
2) object type (alloc on the stack) :
cling::internal::setValueWithAlloc
2.1) constant arrays:
call to cling::runtime::internal::copyArray(...)
We need to synthesize later (see RuntimeUniverse.h)
Wrapper has signature: void w(cling::StoredValueRef SVR)
case 1):
setValueNoAlloc(gCling, &SVR, lastExprTy, lastExpr())
case 2):
new (setValueWithAlloc(gCling, &SVR, lastExprTy)) (lastExpr)
case 2.1):
copyArray(src, placement, N)
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.
