This is an archive of the discontinued LLVM Phabricator instance.

ADT: Add explicit conversions for reverse ilist iterators
ClosedPublic

Authored by dexonsmith on Feb 6 2017, 10:46 PM.

Details

Summary

Add explicit conversions between forward and reverse ilist iterators.
These follow the conversion conventions of std::reverse_iterator, which
are off-by-one: the newly-constructed "reverse" iterator dereferences to
the previous node of the one sent in. This has the benefit of
converting reverse ranges in place:

  • If [I, E) is a valid range,
  • then [reverse(E), reverse(I)) gives the same range in reverse order.

ilist_iterator::getReverse() is unchanged: it returns a reverse iterator
to the *same* node.

Note: we should probably add some release notes for LLVM 4.0 around the
ilist changes, and I think it makes sense to have these conversions in
(and described there). There's been some debate about whether to keep,
delete, or rename getReverse(), but for now I'd just like to get the
explicit conversions in and we can decide later whether to make
getReverse() harder to access.

Diff Detail

Event Timeline

dexonsmith created this revision.Feb 6 2017, 10:46 PM
dblaikie accepted this revision.Feb 7 2017, 9:28 AM

Seems (to my best understanding) this is necessary (there must be an iterator->reverse_iterator ctor that does the off-by-1 thing) and sufficient (it can/must be explicit) to meet the C++ standard "reversible container" requirements. (I was curious if 'explicit' was OK, seems it may be necessary - so, great!)

(some optional feedback on the testing - wrote it about one of the test cases, applies equally to the other)

llvm/unittests/ADT/IListIteratorTest.cpp
147–165

Is it necessary to test all these dimensions together? (I take it this is testing all conversions to/from reverse iterators, const (reverse) iterators, and begin/end, and one off begin, so that's 2 * 2 * 2 * 3.

Are some of these in useful equivalence classes that could be reduced down? (for example the const V non-const seems pretty orthogonal to the value set (begin/end/begin+1) - actually they all seem pretty orthogonal & so perhaps 2 + 2 + 2 + 3 test cases would suffice (or maybe even less if some of the tests cross equivalence classes)?)

168–173

static_assert instead?

This revision is now accepted and ready to land.Feb 7 2017, 9:28 AM
dexonsmith closed this revision.Feb 7 2017, 1:18 PM

Thanks for the review! I made the suggested changes to the tests and committed in r294349.