Skip to content

Refactor AvailInfo to be more sensible

AvailInfo has been the bane of my life for the last 12 months and I want to tame it. There are two main problems with it.

  1. There is this horrible invariant where if the parent is also exported then it is the first element of the list of children.
  2. The set of children and field labels are represented as lists which means many expensive calls to functions from ListSetOps.

1 Is easy enough to solve by adding a flag which says whether the parent is exported or not.

My naive attempt to solve the second problem was to replace the list by a NameSet. At the interface file boundary, the NameSet is converted into a list using nameSetElemsStable to maintain determinism and only pay the cost of using this expensive function once. This ran into problems in RnModIface where there are several functions which map over the list of children. NameSets don't support mapping and so this is difficult to implement in a satisfactory way.

The next plan of attack is to distinguish between IfaceAvailInfo and AvailInfo. The former will use the old representation (lists) in order to maintain determinism but the latter will use sets. Distinguishing the two modes is useful conceptually and practically.

The data type is used in quite a few different ways in lots of places which makes writing a nice interface hard.

This ticket is to record my trail in case I don't make it to the end.

Trac metadata
Trac field Value
Version 8.0.1
Type Task
TypeOfFailure OtherFailure
Priority low
Resolution Unresolved
Component Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information