[PATCH] Introducing initial UseAuto transform

[Richard Smith]

On Tue, Feb 12, 2013 at 2:04 PM, Dmitri Gribenko <gribozavr at gmail.com>wrote:

> On Tue, Feb 12, 2013 at 9:48 PM, Vane, Edwin <edwin.vane at intel.com> wrote:
> >>   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.
>
> All of these look good (they should be processed by that algorithm
> correctly), except for the 'class __gnu_cxx::...' -- it comes from a
> '__begin' variable in the range-based for, which comes from 'auto'
> deduction, which is implemented as argument type deduction.  Might be
> fixable, though non-trivial.


I was looking into maintaining type sugar in 'auto' deduction recently.
Ideally, we should teach template type deduction to minimally desugar while
deducing, but that's a little tricky, since it has some pretty in-grained
assumptions that its types are canonical. I have a WIP patch, but it's a
fair way off being ready for use.


> > 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?
>
> Yes.
>
> > How do you propose we deal with custom iterators? The canonical type may
> then be the LHS type.
>
> The user is free to do whatever crazy stuff they like with their
> iterators, I don't think we should check anything there.
>
> Given the apparent complexity of implementing the check for all cases,
> I think we can leave it for later.
>
> Dmitri
>
> --
> main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
> (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130212/bdbc4ff4/attachment.html>