Rewrote name lookup, should improve perf of #904

After a couple of passes of optimizing get_declaration_of to make its traversal of the symbol table more efficient, I decided to rewrite it entirely to build the information during the initial visitation and not scour at the symbol table afterwards to rediscover the information.

The code generation for all `*.cpp2` and `*.h2` files in the project is unchanged, so it seems likely that this rewrite is not introducing bugs. If we do find some, they should be easier to fix as the lookup logic is now more direct and built and consumed in just two places.

To prevent accidental behavior change, I exhaustively checked every call to get_declaration_of to check whether it returned a different result before and after this change. There were quite a few during debugging which pointed out where I'd overlooked a lookup case, and those are now all fixed. There remained only a few (<10) calls in this entire corpus where g_d_o is now giving a different result, but all are cases where g_d_o was not being consistent previously (repeated calls with the same arguments in the same execution sometimes gave a result and sometimes gave null) and it's now giving the same answer consistently that it gave "sometimes" before. So I think this change is fixing those as (latent) bugs... latent because the compilation output before/after is unchanged, because the previous inconsistency was in cases that didn't actually affect compilation behavior.

Author: hsutter

include/cpp2util.h

@@ -511,6 +511,12 @@ template <typename T>
     requires requires { *std::declval<T&>(); }
 using deref_t = decltype(*std::declval<T&>());
 
+//  Guaranteed to be a total order, unlike built-in operator== for T*
+template <typename T>
+auto pointer_eq(T const* a, T const* b) {
+    return std::compare_three_way{}(a, b) == std::strong_ordering::equal;
+}
+
 
 //-----------------------------------------------------------------------
 //

source/common.h

@@ -1248,90 +1248,8 @@ std::vector<stackinstr::entry> stackinstr::largest;
 //  timer:  a little profiling timer to measure time spent in
 //          specific sections of code
 //
-//  This is a tool for cppfront developers to measure the run-time of
-//  specific parts of cppfront code.
-//
-//  Do still use a profiler too. But once you know where to measure,
-//  this has some advantages:
-//
-//    - Precise: It's easy to accurately measure specific parts of
-//      code across the run of the program, not relying on sampling to
-//      representatively hit those regions
-//
-//    - Flexible: You can have as many timers as you want, each with
-//      a clearly readable name, including nested timers (see example
-//      below)
-//
-//    - Portable: It's part of cppfront itself, no separate tool needed
-//
-//    - Integrated: Reports are printed automatically by -verbose
-//
-//  Usage guide
-//  -----------
-//
-//  To measure the total time spent in a specific section of code, create
-//  a scope_timer guard object in that scope and give it a readable
-//  string name that will remind you what it's measuring.
-//
-//  Example: Today I wanted to measure how long get_declaration_of is
-//  taking. So add this line at the start of that function's body:
-// 
-//     auto timer = scope_timer("get_declaration_of");
-//
-//  Recompile cppfront, then run with -verbose:
-//
-//      cppfront pure2-last-use.cpp2 -p -verb
-//
-//  Sample output:
-// 
-//      pure2-last-use.cpp2... ok (all Cpp2, passes safety checks)
-//         Cpp1  0 lines
-//         Cpp2  1,050 lines (100%)
-//         Time  1,629 ms
-//               1,120 ms in get_declaration_of
-//
-//  The first "Time:" is the total run time of the compiland. It is then
-//  followed by any active scope_timer names, in alphabetical order
-//  (you can choose names so that related timers appear together).
-//
-//  Here, this one function is taking most of the total runtime. It
-//  consists of two major loops, one run before the other, so we can
-//  measure the cost of each part, using names that will be
-//  reported together and in understandable order with -verbose:
-//
-//    - The function's first loop is to find a starting point, so
-//      enclose that in { } with a scope_timer:
-// 
-//          {
-//           auto timer1 = scope_timer("get_declaration_of step 1, initial find loop");
-//           /* the code I want to measure */
-//          }
-//
-//    - Immediately after that, install a second timer to measure the
-//      second loop which covers the entire rest of the function body:
-//
-//          auto timer2 = scope_timer("get_declaration_of step 2, rest of lookup");
-//          /* followed by the rest of the function's body */
-//
-//    - And, since it's easy, throw in a third timer to measure one
-//      sub-part of the step 2 loop... right before the 'move this'
-//      branch we can add this to measure the time spent in oly that
-//      trailing 1/3 of each loop iteration (starting and stopping the
-//      timer at those points in each loop iteration to measure just
-//      the sum of all those loop fragments):
-//
-//          auto timer2b = scope_timer("get_declaration_of step 2b, 'move this' branch");
-//
-//  Recompile cppfront and run again with -verbose... sample output:
-//
-//      pure2-last-use.cpp2... ok (all Cpp2, passes safety checks)
-//         Cpp1  0 lines
-//         Cpp2  1,050 lines (100%)
-//         Time  1,471 ms
-//               1,139 ms in get_declaration_of
-//                 540 ms in get_declaration_of step 1, initial find loop
-//                 567 ms in get_declaration_of step 2, rest of lookup
-//                 148 ms in get_declaration_of step 2b, 'move this' branch
+//  Use CPP2_SCOPE_TIMER("unique name") to declare local objects whose
+//  total timings will be reported in -verbose in CPP2_DEBUG_BUILD builds.
 //
 //-----------------------------------------------------------------------
 //