On Tue, Mar 24, 2015 at 7:07 PM, David Blaikie <dblai...@gmail.com> wrote:
> On Mar 24, 2015 5:42 PM, "Chandler Carruth" <chandl...@gmail.com> wrote: > > > > Author: chandlerc > > Date: Tue Mar 24 19:34:51 2015 > > New Revision: 233156 > > > > URL: http://llvm.org/viewvc/llvm-project?rev=233156&view=rev > > Log: > > [Modules] When writing out the on-disk hash table for the decl context > > lookup tables, we need to establish a stable ordering for constructing > > the hash table. This is trickier than it might seem. > > > > Most of these cases are easily handled by sorting the lookup results > > associated with a specific name that has an identifier. However for > > constructors and conversion functions, the story is more complicated. > > Here we need to merge all of the constructors or conversion functions > > together and this merge needs to be stable. We don't have any stable > > ordering for either constructors or conversion functions as both would > > require a stable ordering across types. > > > > Instead, when we have constructors or conversion functions in the > > results, we reconstruct a stable order by walking the decl context in > > lexical order and merging them in the order their particular declaration > > names are encountered. > > 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? > 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.
_______________________________________________ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
