Patch title: Release 85 bulk changes
Abstract:
File: /pliant/welcome/bugs.page
Key:
    Removed line
    Added line
title "Pliant known bugs list"


header "Setting fields"

  [The following program does not work:]
  listing
    var Array:Int a
    function foo i
      arg_rw Int i
      i := 3
    foo a:size
  [The reason is that the ] ; link "setfield.pli" "/pliant/language/basic/setfield.pli" ; [ module has to be extended so that it overwrites the functions call compiling mechanism in order to compile the previous program as:]
  listing
    var Array:Int a
    function foo i
      arg_w Int i
      i := 3
    var Int j
    j := a size
    foo j
    a 'size :=' j


header "Memory allocation"

  image "/pliant/welcome/image/crazy.jpeg" right
    [Setting 'decommit_step' in /pliant/language/declare/struct.c will prevent 'process_restore' in ] ; link "dump.c" "/pliant/language/os/dump.c" ; [ to work in some rare cases. ]
    [It means that freeing the pages of large free chunks in the memory (the improvement I added to Doug Lea algorithm) is buggy.]
  box right
    image "/pliant/welcome/image/crazy.jpeg"
  [Setting 'decommit_step' in /pliant/language/declare/struct.c will prevent 'process_restore' in ] ; link "dump.c" "/pliant/language/os/dump.c" ; [ to work in some rare cases. ]
  [It means that freeing the pages of large free chunks in the memory (the improvement I added to Doug Lea algorithm) is buggy.]


header "Reserved keywords"

  [Using 'function' as an identifier for a local variable seems to have bad effects on the code generator.] ; eol
  para
    [This is only the tip of a tricky problem with the Pliant compiler: incorrect handling of backtracking in the high level compiler. Backtracking means uncompiling an expression because several instances succeeded to compile the expression and another one has finally been selected. When compiling the expression has some side effects (such as adding a field to a data type) backtracking may be tricky and is poorly handled in the current implementation] ; how "/pliant/language/compiler/expression/expression.c" section "backtrack" ; [ of the compiler.]
  para
    [There may also be other bad side effects in the Pliant high level compiling mechanism. Say you compile an expression that defines a few  keywords then asks its arguments to compile; if the function fails then the successful compilation of the arguments can be semantically incorrect, so should be reversed, but that is not automatically done for compilation speed reasons. The expression is responsible for uncompiling its arguments before exiting in such a situation, but I have not yet carefully checked all the Pliant system against that so there are surely some remaining bugs here.]


header "Memory leak checking"

  [Pliant uses reference counting rather than a garbage collector. ]
  [The reason is performance; see ] ; link "Pliant design" "design" ; [ for the arguments about this design choice.] ; eol
  [In order to help check the possible memory leaks due to circular references, when executing at debugging level 2, before exiting, Pliant will unlock the roots and, as a result, all objects up to the last one should get freed and all bytes of dynamically allocated memory should be freed. ]
  [Now the problem with this very useful feature (that greatly helps tracking memory leaks due either to circular references or to explicitly allocated areas that have not been freed) is that types and functions are Pliant objects so these will be freed as well. Also when an object is built, its type reference count is not incremented so objects may get freed in the wrong order and lead to a core dump.]