Keep record members in the corpus

[K-ballo]

• keep a list of members in RecordInfo: vector< tuple< Access, InfoKind, SymbolID > > Members; (that is part of the corpus),
• preserve order of declared members

note some transformations like overload folding will have to happen in two places (or maybe the record interface should be computed later, after all transformations).

compute the record interface (which is not part of the corpus) once all transformations have finalized

[alandefreitas]

keep a list of members in RecordInfo: vector< tuple< Access, InfoKind, SymbolID > > Members; (that is part of the corpus),

If we're going to change RecordInterface in favor of something else, I'd like to suggest:

1. We do it for all symbol kinds that are contexts for other symbols: records, namespaces, and enums.
2. I'd suggest only vector< SymbolID > Members

Access and InfoKind are O(1) derivable information. There's no good motivation to store them in the corpus. They can't even be used for sorting because we're now going to "preserve order of declared members" anyway.

preserve order of declared members

We have configuration options to sort context members according to various criteria. I'm assuming we're not removing this option that users clamoured for, so I'm assuming that "preserve order of declared members" means to maintain two lists.

So symbol contexts would have vector< SymbolID > Members and vector< SymbolID > sortedMembers (or vector< SymbolID > Members and vector< SymbolID > interfaceMembers, if the second list is the also also includes the interface resolution, etc).

That technically works. But if that's the case, Members is now storing information that's either:

1. cheaply derivable from interfaceMembers (the subset of parents), and
2. unnecessary to users who asked for sorted members

In other words, it works despite of it. Not because of it. It's something we're going to store and ignore because we don't need it.

order of declared members

I'm not sure this means what you guys think this means. You are probably assuming that:

1. clang gives us the elements in some deterministic order as they appear in the source file (or at least for Records), and
2. MrDocs always breaks this ordering

We as know, # 1 is false for namespaces because the TUs are processed in arbitrary order. But it's also false for Record because even though ASTVisitor::traverseMembers or clang::DeclContext::decls typically gives me members in the order they appear in the source file, the nature of the traversal is depth-first. If any member of the higher-level record happens to be mentioned at a lower level for the first time, this member will be extracted first. The way to be sure you get members in the order they appear in the source files by using the MrDocs "sort-members-by" location option. Not to do nothing.

And as we know, # 2 is also false because members are only sorted if you enable "sort-members". The question becomes whether we should keep copies of that. I already discussed that in the previous point.

[K-ballo]

order of declared members

I'm not sure this means what you guys think this means.

This means to preserve the order in which the members are declared.

This is not necessarily the order in which clang visits them. If we need to sort by line-number to reflect the actual C++ order then that's what we'll do.

[vinniefalco]

This issue describes a proposed change to how metadata is stored. It doesn't immediately strike me as a bad idea, yet these types of architectural changes would be easier to understand and digest if they provided the motivation. Why do we want to change it to this?

[alandefreitas]

This is not necessarily the order in which clang visits them. If we need to sort by line-number to reflect the actual C++ order then that's what we'll do.

That's great. So that's already implemented. So preserve order of declared members is done and the issue we have left is "replace record tranches with vector of tuples". What problem are we tackling with this change?

[vinniefalco]

Not so fast. Sorting by line number is a nice hack but what happens with:

struct T {
  void f0(); void f1(); void f2();
};

f0, f1, and f2 all have the same line number. What is the order?

[alandefreitas]

Not so fast

lol

f0, f1, and f2 all have the same line number. What is the order?

True.

The current algorithm already sorts by relative filename (for an stable order just in case there are more files involved), then line number.

I recently introduced the column number in the corpus. It just didn't exist. You're right. We do need an extra comparison in SortMembersFinalizer.cpp.

(That's one extra problem with these issues that don't describe the problem: they can include two "orders"/things to do that should be independent issues and the discussion becomes confusing)