FWIW, I think I actually prefer defining the range in terms of the iterators rather than vice-versa... At least, until the non-range variants go away.<br><br><div>On Fri Mar 07 2014 at 4:37:09 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Mar 7, 2014 at 4:18 PM, Aaron Ballman <<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.com</a>> wrote:<br>

> On Fri, Mar 7, 2014 at 6:35 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>> wrote:<br>
>> On Fri, Mar 7, 2014 at 2:43 PM, Aaron Ballman <<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.com</a>><br>
>> wrote:<br>
>>><br>
>>> On Fri, Mar 7, 2014 at 5:28 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br>
>>> > On Fri, Mar 7, 2014 at 2:17 PM, Aaron Ballman <<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.com</a>><br>
>>> > wrote:<br>
>>> >> Author: aaronballman<br>
>>> >> Date: Fri Mar  7 16:17:20 2014<br>
>>> >> New Revision: 203299<br>
>>> >><br>
>>> >> URL: <a href="http://llvm.org/viewvc/llvm-project?rev=203299&view=rev" target="_blank">http://llvm.org/viewvc/llvm-<u></u>project?rev=203299&view=rev</a><br>
>>> >> Log:<br>
>>> >> In my tests, I'm finding that declaring iterators in terms of ranges<br>
>>> >> can sometimes have dangerous side-effects where the range temporary is<br>
>>> >> destroyed, taking the underlying iterators out with it.<br>
>>> ><br>
>>> > Um... what? do you have a concrete example because that doesn't sound<br>
>>> > right at all, at least not for iterator_range<T> which just holds<br>
>>> > copies of the iterator - are some of our iterators non-copyable (or<br>
>>> > not safely/sanely copyable in some way)? All the begin/end's return by<br>
>>> > value, so I don't see how they could be related to the copy that<br>
>>> > happens to be in the range temporary...<br>
>>><br>
>>> I've found this to be the case anywhere the iterator doesn't wind up<br>
>>> being a simple pointer. attributes (which I had to roll back),<br>
>><br>
>><br>
>> I thought the problem in the attributes case was that an accidental copy of<br>
>> the collection of attributes was being made? Or does this still break with<br>
>> that fixed?<br>
><br>
> It was still breaking with that fixed, once upon a time. Now, not as confident.<br>
><br>
>><br>
>>> enums<br>
>>> (which I've yet to commit while trying to figure this out). In all<br>
>>> cases, the commonality is that it compiles fine, but exhibits<br>
>>> use-after-free behavior on test cases in some circumstances.<br>
>>><br>
>>> Regarding the attribute patch (which was committed this morning as<br>
>>> r203236 and reverted as r203237), Takumi found that these specific<br>
>>> changes were causing test cases to fail:<br>
>>> <a href="https://gist.github.com/chapuni/9412576" target="_blank">https://gist.github.com/<u></u>chapuni/9412576</a><br>
>>><br>
>>> So I agree, I find is really surprising that it behaves this way, but<br>
>>> prefer to err on the side of caution at least while doing this initial<br>
>>> push. Once things are pretty well range-ified, then I intend to<br>
>>> revisit the problem (unless someone beats me to it).<br>
>><br>
>><br>
>> Does this happen with multiple compilers, or is it an MSVC-specific<br>
>> miscompile?<br>
><br>
> I'm starting to doubt my sanity. I just locally reverted this commit,<br>
> applied my enums patch, and everything passes whereas it was<br>
> consistently failing before.<br>
><br>
> Let's pretend I've got a goblin (I should probably reboot this<br>
> machine, it's been quite a while and I've been taxing it lately). Do<br>
> you (or David) see any problems with the code as it was written prior<br>
> to this commit? I originally thought the code was fine, and only<br>
> rolled it back to the state it's currently in because of local worries<br>
> that don't seem so valid now. I'd like to go with a second set of eyes<br>
> to reduce any further churn.<br>
><br>
> Assuming that you and/or David don't see anything wrong with the code<br>
> I reverted, I'll re-revert this as being a valid pattern and chalk<br>
> this up to solar flares or some such.  :-/<br>
<br>
Yeah, I certainly can't see any fault with the implementation as it<br>
was before you reverted it - hence my surprise at the revert.<br>
<br>
- David<br>
______________________________<u></u>_________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@cs.uiuc.edu" target="_blank">cfe-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/cfe-commits</a><br>
</blockquote>