[flang] Change how memory for Symbol instances is managed.
authorTim Keith <tkeith@nvidia.com>
Tue, 19 Jun 2018 23:06:41 +0000 (16:06 -0700)
committerTim Keith <tkeith@nvidia.com>
Tue, 19 Jun 2018 23:06:41 +0000 (16:06 -0700)
commitb40c9ee2b2f985e53086056f5333cfbc6a431552
treeeb9c81b894d69a0f2d595eab88b3d969c39d446d
parent0d701085e0cda1e1d685891c9fbf8fa4030a12a5
[flang] Change how memory for Symbol instances is managed.

With this change, all instances Symbol are stored in class Symbols.
Scope.symbols_, which used to own the symbol memory, now maps names to
Symbol* instead. This causes a bunch of reference-to-pointer changes
because of the change in type of key-value pairs. It also requires a
default constructor for Symbol, which means owner_ can't be a reference.

Symbols manages Symbol instances by allocating a block of them at a time
and returning the next one when needed. They are never freed.

The reason for the change is that there are a few cases where we need
to have a two symbols with the same name, so they can't both live in
the map in Scope. Those are:
1. When there is an erroneous redeclaration of a name we may delete the
   first symbol and replace it with a new one. If we have saved a pointer
   to the first one it is now dangling. This can be seen by running
   `f18 -fdebug-dump-symbols -fparse-only test/semantics/resolve19.f90`
   under valgrind. Subroutine s is declared twice: each results in a
   scope that contains a pointer back to the symbol for the subroutine.
   After the second symbol for s is created the first is gone so the
   pointer in the scope is invalid.
2. A generic and one of its specifics can have the same name. We currently
   handle that by moving the symbol for the specific into a unique_ptr
   in the generic. So in that case the symbol is owned by another symbol
   instead of by the scope. It is simpler if we only have to deal with
   moving the raw pointer around.
3. A generic and a derived type can have the same name. This case isn't
   handled yet, but it can be done like flang-compiler/f18#2 above. It's more complicated
   because the derived type and the generic can be declared in either
   order.

Original-commit: flang-compiler/f18@55a68cf0235c8a3ac855de7dc0e2b08690866be0
Reviewed-on: https://github.com/flang-compiler/f18/pull/107
flang/lib/semantics/resolve-names.cc
flang/lib/semantics/scope.cc
flang/lib/semantics/scope.h
flang/lib/semantics/symbol.cc
flang/lib/semantics/symbol.h