<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 24, 2015 at 7:07 PM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><p dir="ltr">On Mar 24, 2015 5:42 PM, "Chandler Carruth" <<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>> wrote:<br>
><br>
> Author: chandlerc<br>
> Date: Tue Mar 24 19:34:51 2015<br>
> New Revision: 233156<br>
><br>
> URL: <a href="http://llvm.org/viewvc/llvm-project?rev=233156&view=rev" target="_blank">http://llvm.org/viewvc/llvm-project?rev=233156&view=rev</a><br>
> Log:<br>
> [Modules] When writing out the on-disk hash table for the decl context<br>
> lookup tables, we need to establish a stable ordering for constructing<br>
> the hash table. This is trickier than it might seem.<br>
><br>
> Most of these cases are easily handled by sorting the lookup results<br>
> associated with a specific name that has an identifier. However for<br>
> constructors and conversion functions, the story is more complicated.<br>
> Here we need to merge all of the constructors or conversion functions<br>
> together and this merge needs to be stable. We don't have any stable<br>
> ordering for either constructors or conversion functions as both would<br>
> require a stable ordering across types.<br>
><br>
> Instead, when we have constructors or conversion functions in the<br>
> results, we reconstruct a stable order by walking the decl context in<br>
> lexical order and merging them in the order their particular declaration<br>
> names are encountered. </p>
</span><p dir="ltr">I assume for user written ctors and conversion functions they appear in the order the user wrote them. What happens for implicitly defined ctors? Is their order guaranteed?</p></blockquote></div>This relies upon the order they occur in the AST. If that isn't deterministic, we'll also emit code for them and do other things in a non-deterministic way, so we can keep fixing up the stack. But I believe it is deterministic and based on the code which implicitly generates them. There is at least no hash table or other inherently non-deterministic data source there.</div></div>