[PATCH] RFC: fail-fast iterators for DenseMap

[Chandler Carruth]

(relaying from IRC)

The key is that default constructing an iterator must form a valid end
iterator for an empty range. This is a requirement for a lot of iterator
types, and so the epoch stuff should support it. I think it would be fine
to say that the epoch test is passed if both handles have a nullptr epoch
address or both handles have a non-null epoch address and the epoch's match
for both. Seem reasonable?

On Mon, Mar 2, 2015 at 7:49 PM, Sanjoy Das <sanjoy at playingwithpointers.com>
wrote:

> As far as I can tell, DeclContext::lookups [1] tries to create an
> empty range using two default constructed
> DeclContext::all_lookups_iterator[2].
> DeclContext::all_lookups_iterator contains DenseMapIterators.
>
> [1]:
> https://github.com/llvm-mirror/clang/blob/master/include/clang/AST/DeclLookups.h#L81
> [2]:
> https://github.com/llvm-mirror/clang/blob/master/include/clang/AST/DeclLookups.h#L35
>
> On Mon, Mar 2, 2015 at 7:21 PM, Daniel Berlin <dberlin at dberlin.org> wrote:
> >
> >
> > On Tue, Mar 3, 2015 at 12:53 PM, Sanjoy Das <
> sanjoy at playingwithpointers.com>
> > wrote:
> >>
> >> I'm about to revert this because it broke clang.
> >>
> >> The reason it broke clang is that clang assumes a default constructed
> >> DenseMapIterator is comparable with another default constructed
> >> DenseMapIterator.
> >
> >
> >
> > Where does this happen?
> > I'd really like to see an actual example of how this makes sense to do
> >
> > i have no idea whether it's generally considered "normal" to do this, but
> > i'm actually really curious to see a case where it is the right thing to
> do
> > :)
> >
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150302/46e90cce/attachment.html>