<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 24, 2015 at 5:34 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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. This doesn't generalize as there might be found<br>
declaration names which don't actually occur within the lexical context,<br>
but for constructors and conversion functions it is safe. It does<br>
require loading the entire decl context if necessary to establish the<br>
ordering but there doesn't seem to be a meaningful way around that.<br>
<br>
Many thanks to Richard for talking through all of the design choices<br>
here. While I wrote the code, he guided all the actual decisions about<br>
how to establish the order of things.<br>
<br>
No test case yet because the test case I have doesn't pass yet -- there<br>
are still more sources of non-determinism. However, this is complex<br>
enough that I wanted it to go into its own commit in case it causes some<br>
unforseen issue or needs to be reverted.<br>
<br></blockquote><div>This patch is causing several tests to fail.  However, reverting also seems to cause a test to fail.</div><div><br></div><div>Release build compiled with Clang</div><div>Failing Tests (2):<br></div><div><div>    Clang :: Modules/cxx-decls.cpp</div><div>    Clang :: PCH/cxx11-inheriting-ctors.cpp</div></div><div><br></div><div>Release build compiled with GCC</div><div><div>Failing Tests (1):</div><div>    Clang :: PCH/cxx-method.cpp</div></div><div><br></div><div>Debug build compiled with Clang with revision 233156 reverted</div><div><div>Failing Tests (1):</div><div>    Clang :: Modules/stress1.cpp</div></div><div><br></div></div></div></div>