[clang] [clang][dataflow] Treat comma operator correctly in `getResultObjectLocation()`. (PR #78427)

[via cfe-commits]

martinboehme wrote:

> On the other hand, I am still wondering whether it is a good idea to expose this publicly to the checks or we could do it automatically when necessary in the engine code. That being said, I think the "publicness" of this API is not that important to solve at this point.

You mean the publicness of `getResultObjectLocation()`?

I don't really see a good alternative. Consider the UncheckedOptionalAccessModel. It needs to provide its own custom transfer function for the constructor of an `optional`, which initializes the state of the optional object, and to do so, it needs to answer the question "in which location will this end up getting stored". Put differently, it needs to know what the constructor's implicit `this` argument is. That's what `getResultObjectLocation()` returns.

Maybe you're reacting to the verbose and slightly opaque name? I don't love the name either, but it kind of follows from the terms that the standard uses. ["Result object"](https://en.cppreference.com/w/cpp/language/value_category) is the term that the standard uses for "what is the object that this prvalue ends up initializing", and given that term, `getResultObjectLocation()` is a pretty obvious (though verbose) name for the function.

But we'll certainly keep this on the table -- maybe we come up with a good alternative in the future.

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