[clang] [NFC] [analyzer] Factor out SymbolManager::get<*> (PR #121781)

DonĂ¡t Nagy via cfe-commits cfe-commits at lists.llvm.org
Tue Jan 7 04:29:45 PST 2025


================
@@ -525,14 +527,14 @@ class SymbolManager {
 
   static bool canSymbolicate(QualType T);
 
-  /// Make a unique symbol for MemRegion R according to its kind.
-  const SymbolRegionValue* getRegionValueSymbol(const TypedValueRegion* R);
+  template <typename T, typename... Args> const T *get(Args &&...args);
----------------
NagyDonat wrote:

> I was considering "make" briefly, but it is not entirely correct: this function doesn't always make a `SymExpr`, sometimes it retrieves an existing one matching the arguments. Besides, most of the replaced member functions were called `get*`.

I would say that "`make`" is still reasonable in this case, because semantically it _makes the symbol_ which is determined by the arguments passed to it -- and it's just an implementation detail that symbols are immutable objects and the `make` call returns already created symbols instead of recreating them. However, I can accept a different name if you're opposed to "`make`".

> How do you like `findOrCreate`, `createIfNone`, `ensureExists`, `obtain`, `acquire`, `procure`?

I think `acquire` would be the best choice, followed by something like `makeOrGet` or `findOrCreate`. IMO `obtain` suggests that we're getting the symbol from an external source, [`procure` has unfortunate connections to sexual services](https://www.merriam-webster.com/dictionary/procure) and in my opinion `createIfNone` and `ensureExists` don't clearly imply that these functions _return the symbol_ in addition to just initializing it in some internal table.

https://github.com/llvm/llvm-project/pull/121781


More information about the cfe-commits mailing list