[clang] [NFC][analyzer] Improve tracking of the current Block & LocCtx (PR #185107)

[Balázs Benics via cfe-commits]

steakhal wrote:

> > Looking at the diff I think it might be marginally better than what we had before but I'm still really unhappy with how local reasoning techniques can be applied.
> 
> What do you mean under "local reasoning techniques"? What property/invariant would you want to check/understand locally?
> 
> > I'll admit that I don't really have the bandwidth to propose constructive feedback for alternatives. I''m sure you have considered some but in case you didn't then:
> > How could we ensure at compile-time that these global-like variables are kept in sync across the handlers?
> 
> "kept in sync" with what?
> 
> * Are you speaking about keeping these global-like variables in sync with other objects that "know" the Block / LocationContext (e.g. the `ExplodedNode`s have a `LocationContext`) ?
> * Or are you speaking about keeping the different "handlers" (the "Handle" methods?) in sync with each other?
> 
> (Excuse me for my lack of understanding 😅)

Right, worth explaining what I had in mind. Sorry for being lazy.

Because we have so many "handlers", the member variables start to behave as global variables. As such, the principle of avoiding mutable global variables start to apply, and if we can avoid them that's going to improve local reasoning.
Local reasoning what and how can or should change inside different "handlers" or their transitive callees (helpers, other functions they dispatch to).

For example, if we pass everything as parameters, then we can limit what is const and what is not - clearly documenting what is intended with a given variable.
If there is a pressure on the number of parameters, one could bundle them up and have "config", "context" , or "manager" variables grouping things up. -- I'm not suggesting that's what we should do, I'm just arguing that that's one other way of solving consistency issues about who needs to set what.

On top of this, strong typing could help with the problem that something needs to be done (e.g. set) exactly once per handler at the very beginning. We just need a type can be only constructed by one thing, and expect an instance of that in the handler parameters. That would mean that a handler can't be called without going through the hoops of creating one of those objects that would (either directly or indirectly as a side-effect) establish some invariant (aka. set the context in this example).

There could be many other (probably less intrusive) ways of achieving consistency.

> "kept in sync" with what?

I was intentionally vague, I don't exactly know when you want to set the effectively-global member variables (whatever block context, and whatever LocationContext). But I presumed that those should be set at once, and in every handler. These where the places that would need to be "in-sync" with each other. This is what I had in mind.

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