================
@@ -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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
