[PATCH] D152947: [DebugInfo] Change DWARFDebugAbbrev initialization

[David Blaikie via Phabricator via llvm-commits]

dblaikie added a comment.

In D152947#4430336 <https://reviews.llvm.org/D152947#4430336>, @fdeazeve wrote:

>> using lazy fallible iterators might be suitable:
>
> @bulbazord, if you end up using these, let's chat as I'd love to understand them better. To name a couple of things that puzzled me, it exposes these methods:
>
>   /// Construct a fallible iterator that *cannot* be used as an end-of-range
>   /// value.
>   static fallible_iterator itr(Underlying I, Error &Err) {
>   
>   /// Construct a fallible iterator that can be used as an end-of-range value.
>   /// A value created by this method can be dereferenced (if the underlying
>   /// value points at a valid value)
>   static fallible_iterator end(Underlying I) {
>
> Not being able to construct a "begin" that is also "end" seems counter-intuitive (iterators often test emptiness through begin==end). Similarly, constructing an "end" that can be dereferenced is not usual? In the process of asking these questions, I think I now know the answer, but I don't want to bias your investigation ;)

I think the idea here is an attempt to generalize, perhaps overly so - to cover cases where you might expose iterators to subranges (and the consumer might know it's a subrange, so it's an "end" iterator in that it's the end of a subrange, but not necessarily an invalid iterator) - I think the words are all a bit more complicated/generalizing than may be necessary. The point is that the iterator you might increment forward is the one you get from the function that also takes an Error out parameter, and the other iterator that doesn't have such a parameter is the one you compare the former to.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D152947/new/

https://reviews.llvm.org/D152947