Merge pull request swiftlang#30694 from CodaFi/mission-accomplished

[Gardening] Strike an Acchieved Request Evaluator Goal

Author: CodaFi

docs/RequestEvaluator.md

@@ -57,7 +57,6 @@ Until then, the request-evaluator lives in a compiler that has mutable ASTs, and
 The request-evaluator is relatively new to the Swift compiler, having been introduced in mid-2018. There are a number of improvements that can be made to the evaluator itself and how it is used in the compiler:
 
 * The evaluator uses a `DenseMap<AnyRequest, AnyValue>` as its cache: we can almost certainly do better with per-request-kind caches that don't depend on so much type erasure.
-* The stack of active requests uses a `SetVector<AnyRequest>`: we can almost certainly do better with some kind of heterogeneous on-stack representation that only realizes `AnyRequest` instances in the failure cases (e.g., to diagnose a cycle).
 * Explore how best to cache data structures in the evaluator. For example, caching `std::vector<T>` or `std::string` implies that we'll make copies of the underlying data structure each time we access the data. Could we automatically intern the data into an allocation arena owned by the evaluator, and vend `ArrayRef<T>` and `StringRef` to clients instead?
 * Cycle diagnostics are far too complicated and produce very poor results. Consider replacing the current `diagnoseCycle`/`noteCycleStep` scheme with a single method that produces summary information (e.g., a short summary string + source location information) and provides richer diagnostics from that string.
 * The `isCached()` check to determine whether a specific instance of a request is worth caching may be at the wrong level, because one generally has to duplicate effort (or worse, code!) to make the decision in `isCached()`. Consider whether the `evaluator()` function could return something special to say "produce this value without caching" vs. the normal "produce this value with caching".