> It can be done easier, I think. We know that all functions that return
> iterators have a return value type with correct sugar. That is,
> `vector<T>::begin()` return value is always `vector<T>::iterator`.
>
> [REV] This isn't always true. When dealing with for-loops I found from
> dumping the AST that you don't get vector<T>::iterator but whatever
> vector<T>::iterator typedefs to which is quite long and complex with
> libstdc++. It was this realization that prompted the comparison of canonical
> types.
I guess there is something not entirely correct in that test, because this is
what I see in my copy of libstdc++ 4.7:
iterator
begin() _GLIBCXX_NOEXCEPT /*...*/
[REV] I put this:
llvm::errs() << D->getType().getAsString() << " = " <<
E->getType().getAsString() << "\n";
right before the cananonical type equality test. Here's the output when running
the iterator.cpp test:
class MyIterator = class MyIterator
class DummyIterator = class DummyIterator
std::vector<int>::iterator = iterator
int_iterator = std::vector<int>::iterator
std::vector<int>::iterator = iterator
std::vector<int>::reverse_iterator = reverse_iterator
std::vector<int>::iterator = iterator
std::vector<int>::iterator = class __gnu_cxx::__normal_iterator<int *, class
std::vector<int, class std::allocator<int> > >
int_iterator = iterator
int_iterator = iterator
Notice how the RHS type, even though not user-provided, varies quite a lot.
This is with libstdc++4.7. I'm not entirely sure this matters. From what you're
suggesting about unsugaring user types it sounds like we do the canonical type
test and then do an extra bit of work to make sure the user-provided type is no
less sugared than the types allowed by the spec? How do you propose we deal
with custom iterators? The canonical type may then be the LHS type.
_______________________________________________
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
