Interface ProgramFactory

public interface ProgramFactory

This factory is used to produce a whole Program from a set of ASTs representing individual translation units. This is similar to the process of "linking". The resulting program is represented by a single AST that is obtained by carefully merging the given ASTs. In the process of merging, some entities may have to be re-named to avoid name conflicts, as described below.

  1. For any entity that is renamed, the new name will be obtained by appending a string beginning with $TU to the original name. Hence the substring $TU should never be used in any identifier in the original program, as it is reserved for this use.
  2. The determination of compatibility for two tagged types will first strip any suffix beginning with $TU from the tags. So, for example, structs with tags such as foo, foo$TU1, and foo$TU2 may still be compatible, because all of them will be considered to have the tag foo for the purpose of compatibility checking.
  3. After renaming, any two complete compatible tagged file-scope entities will have the same name. The (redundant) complete definitions after the first complete definition will be converted to incomplete declarations. That is, in any subtree of the form struct S { ... }, the node {...} will be replaced with null.
  4. If all of the complete tagged file-scope entities with a given name are compatible, then all those entities will keep the original name (including the incomplete ones), and will therefore become one entity in the resulting merged AST.
  5. If there exist two incompatible file-scope tagged entities with the same name from different translation units: the incompatible entities will be given different names. Furthermore, any incomplete file-scope tagged entity with that name will be given a name unique to its translation unit. However, an incomplete type may still be considered compatible to any of these types, due to the renaming scheme described above.
  6. Given an ordinary file-scope entity E1 with internal or no linkage, if there is another file-scope entity with the same name as E1 in a different translation unit, the name of E1 will be modified to be unique in the whole program, e.g., by appending a string of the form TUi to its name, where i is the ID of the translation unit to which E1 belongs.

Possible further work:

  1. A second analysis pass on the merged AST could be implemented to update the types of functions and objects. For example, the type of a function might change after its definition. This could happen for example if a parameter type had the form struct S *p and S was incomplete at the point at which the function was analyzed. If S is completed later, the type of that parameter (and the function) changes. Hence the analysis of the body of the function should be re-done with the updated type of p---this might lead to discovering an incompatibility. See example a0.c, a1.c, a2.c in examples/link.
  2. the Pruner could merge compatible typedefs. This has to happen after the merged AST is anaylzed, because the new type information is needed.

  • Method Summary

    Modifier and Type
    Returns the AST factory associated to this program factory.
    Forms a new program from the given AST.
    newProgram(AST[] asts)
    Forms a new program by merging the given ASTs.
  • Method Details

    • getASTFactory

      ASTFactory getASTFactory()
      Returns the AST factory associated to this program factory. This AST factory is used, for example, to create the new merged AST from a set of translation units.
      the AST factory
    • newProgram

      Program newProgram(AST ast) throws SyntaxException
      Forms a new program from the given AST. The given AST is cleaned (i.e., any residual analysis information from some previous analysis is removed) and analyzed in the process of creating the new program.
      ast - an AST
      the program wrapping the given AST
      SyntaxException - if any kind of static error is detected in the AST
    • newProgram

      Program newProgram(AST[] asts) throws SyntaxException
      Forms a new program by merging the given ASTs. Each AST represents a single translation unit. The ASTs will be cleared and analyzed in the process, so any existing analysis data will be discarded. In the process of merging, entities may have to be renamed to avoid name conflicts.
      asts - a sequence of ASTs
      the program obtained by merging the given ASTs
      SyntaxException - if any kind of static error is detected in any AST, or any problem occurs in merging them