Cool! A couple of thoughts that might simplify this...<div><br></div><div>Do we need to provide a full map-iterator? My suspicion is that all of the places where we use this, iterating the dense map directly is a bug. I'd like to see if we colud get away with the MapVector essentially only exposing the vector iteration, but exposing an operator[] which accepts a key type, and a find which accepts a key type (the find still returning a vector iterator).</div>
<div><br></div><div>Also, could we specialize the DenseMapInfo to make -1 and -2 (in unsigned) be the empty and tombstone values (resp.)? That should remove the need for the values in the map being 1-based. It would be nice to be able to directly forward to the vector for a lot of this.</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 29, 2012 at 12:43 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The attached patch adds a MapVector class to ADT. It behaves mostly<br>
like a DenseMap (including the iteration order), but provides a<br>
getValues method that can be used to iterate the values in a<br>
deterministic order.<br>
<br>
This will be used to fix a non deterministic output order in clang<br>
when two virtual functions are marked used because we output a vtable.<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div>