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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
They are usually provided by clang's BackendUtil - which we don't use and which
has no support for incremental ("streaming") compilation but runs the passes on
the whole module the whole time, and does end-of-TU cleanup (e.g. "dead" code
removal) that we cannot use because subsequent transactions might create new
uses - think force_inline functions that must stay.
Instead BackendPass wraps what's in clang's BackendUtil into a
TransactionTransformer. It gets added to the IR transformers. In the future this
should only transform the delta of one Transaction instead of the whole Module.
This fixes the libc++ issue we worked around by
templates' symbols are not exported anymore and cause missing symbols with
XCode 5.1.
We include ObjC passes even though this blows up the list of linked libraries to
make it easier to port cling to ObjC(++).
This is triggered by emitting operator<< 'class std::__1::basic_ostream<char,
struct std::__1::char_traits<char> > &(int)' even though its marked as exported
in general. Now that clang and libc++ agree on the handling of exported
templates we can remove our work-around.
GetPartiallyDesaguredType now desugar template alias
but does not yet properly propagate the opaque typedef
and thus:
template <typename T> using myvector = std::vector<T>;
myvector<Double32_t> vd32d;
template<class T> using ptr = T*;
ptr<Double32_t> p3;
Both currently result in the Double32_t being ignored.
The partial desugaring (part of normalization) now strips a typedef
even when it original from std and points to compiler details (__gnu_cxx, etc.).
The cost of this convenience was the fact the same entity could have different
'name' and thus different class even-though they were supposed to be strictly
equivalent. i.e. depending on the way to get to the class it could be name
vector<int*>::iterator or __gnu_cxx::iterator<int*> or std::iterator<int*>.
This different from the case where we have a strictly bidirectional equivalent
between the class and its unique typedef (yes, we are talking about you std::string).
This also different from the case where there is a semantic difference between
the two possible name. I.e. where an opaque typedef is used. For example,
vector<Double32_t> and vector<double> and where the 'way' to get to the type[name]
is relevant.
