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, 2 insertions, 6 deletions

diff --git a/src/libexpr/eval-cache.hh b/src/libexpr/eval-cache.hh
index b0709ebc2..f4481c72a 100644
--- a/src/libexpr/eval-cache.hh
+++ b/src/libexpr/eval-cache.hh
@@ -96,13 +96,9 @@ public:
 
     Suggestions getSuggestionsForAttr(Symbol name);
 
-    std::shared_ptr<AttrCursor> maybeGetAttr(Symbol name, bool forceErrors = false);
+    std::shared_ptr<AttrCursor> maybeGetAttr(std::string_view name, bool forceErrors = false);
 
-    std::shared_ptr<AttrCursor> maybeGetAttr(std::string_view name);
-
-    ref<AttrCursor> getAttr(Symbol name, bool forceErrors = false);
-
-    ref<AttrCursor> getAttr(std::string_view name);
+    ref<AttrCursor> getAttr(std::string_view name, bool forceErrors = false);
 
     /* Get an attribute along a chain of attrsets. Note that this does
        not auto-call functors or functions. */