r233156 - [Modules] When writing out the on-disk hash table for the decl context

[Chandler Carruth]

On Tue, Mar 24, 2015 at 7:07 PM, David Blaikie <dblaikie at gmail.com> wrote:

> On Mar 24, 2015 5:42 PM, "Chandler Carruth" <chandlerc at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150325/ac95e05d/attachment.html>