[GHC] #12891: Automate symbols inclusion in RtsSymbols.c from Rts.h

[GHC]

#12891: Automate symbols inclusion in RtsSymbols.c from Rts.h
-------------------------------------+-------------------------------------
        Reporter:  Phyx-             |                Owner:  bgamari
            Type:  task              |               Status:  new
        Priority:  normal            |            Milestone:  8.6.1
       Component:  Build System      |              Version:  8.0.1
      Resolution:                    |             Keywords:  newcomer
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #12846            |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by chris_r_timmons):

 I've developed a possible fix for this ticket, but I have some questions
 about the nature of GHC's runtime symbols.  Depending on the answers, I'm
 afraid my fix will just push the problem to a different location, and not
 really be a fix at all.

 This ticket's description states that it's error-prone for a developer to
 keep GHC's runtime symbols in sync between the runtime system's C header
 files (*.h) and C source files (*.c).  The goal is to remove the developer
 from having to decide if the runtime symbols are in sync, and have an
 algorithm perform that task instead.

 The runtime symbols naturally fall into mathematical sets:

 * Set "A": All runtime function symbols in `includes/Rts.h` (and its
 included headers).
 * Set "B": All runtime function symbols exported by the `rtsSyms[]` array
 in `rts/RtsSymbols.c`.

 It should be a simple matter of calculating the set difference `(A - B)`
 to discover what symbols aren't being exported.

 Unfortunately, it's not so simple.  Set "A" has about 870 symbols, and set
 "B" about 560.  This means roughly 310 symbols aren't being exported.
 These symbols appear to be legitimately intended to never be exported.
 We'll call this set "C":

 * Set "C": All runtime function symbols in `includes/Rts.h` intentionally
 **NOT** exported by the `rtsSyms[]` array in `rts/RtsSymbols.c`.

 Now the algorithm becomes `(A - B) - C`, which works.  But there's a
 problem.

 The contents of sets "A" and "B" can be determined algorithmically.
 However, the contents of set "C" must be determined semantically - i.e. a
 developer must decide what symbols should and should not be in set "C".
 The goal of removing the developer from the decision-making process has
 not been met.

 Questions:

 * Should set "C" exist?  As long as it does, a completely algorithmic
 solution will never be possible, because a developer will still be
 required to make a decision about the contents of set "C".  In other
 words, the current problem of a developer forgetting to add a symbol to
 set "B" (the rtsSyms[] array in rts/RtsSymbols.c), is replaced by a new
 problem of a developer deciding what symbols belong in set "C".  My fix
 would just shift the problem to new location (along with the addition of
 about 1000 lines of new code and documentation in GHC's code base).

 * The only fix I can think of is to eliminate set "C" by requiring any
 symbol appearing in set "A" to also appear in set "B".  Is this feasible?

 Thanks.

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12891#comment:10>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler