store Symbols in a table as well, like positions

this slightly increases the amount of memory used for any given symbol, but this
increase is more than made up for if the symbol is referenced more than once in
the EvalState that holds it. on average every symbol should be referenced at
least twice (once to introduce a binding, once to use it), so we expect no
increase in memory on average.

symbol tables are limited to 2³² entries like position tables, and similar
arguments apply to why overflow is not likely: 2³² symbols would require as many
string instances (at 24 bytes each) and map entries (at 24 bytes or more each,
assuming that the map holds on average at most one item per bucket as the docs
say). a full symbol table would require at least 192GB of memory just for
symbols, which is well out of reach. (an ofborg eval of nixpks today creates
less than a million symbols!)

1 files changed, 8 insertions, 0 deletions

diff --git a/src/libutil/types.hh b/src/libutil/types.hh
index 22bc2b8dd..bd1dd8bee 100644
--- a/src/libutil/types.hh
+++ b/src/libutil/types.hh
@@ -152,6 +152,14 @@ public:
     {
         return chunks[idx / ChunkSize][idx % ChunkSize];
     }
+
+    template<typename Fn>
+    void forEach(Fn fn) const
+    {
+        for (const auto & c : chunks)
+            for (const auto & e : c)
+                fn(e);
+    }
 };
 
 }