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

[Donát Nagy via cfe-commits]

NagyDonat wrote:

Thanks for the clarifications!

> 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.

The relevant member variables are a `Block` and a `LocationContext`.

The ideal access pattern of these variables would be:
- There is a single canonical source for this information.
- These are set once per `dispatchWorkItem` call, as close to the beginning of `dispatchWorkItem` as possible. [2]
- They can be queried practically anywhere (where the `ExprEngine` or a `CheckerContext` is accessible). 

The current situation is much worse than this:
- There is no consistent location: many functions use `currBldrCtx` but others pass around the `NodeBuilderContext` as a parameter.
- There are many random scattered redundant places where `NodeBuilderContext`s are initialized and perhaps placed in `currBldrCtx`.
- They can be queried anywhere, but the correct way of querying them is not always clear (because there is no consistent locations).

My current commit series aim to gradually convert the current situation into the ideal one. Once I reach the ideal access pattern, it will be possible to "harden" it by introducing compile-time constraints (which would break compilation in the intermediate stages of the conversion).

Personally, I hope that the end result will be so straightforward that there won't be need for compile-time guardrails, but if you feel that they would be useful, it would be easy to add them, e.g. with the approach that you mention:

> 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).

-----

[1] There is an `unsigned currStmtIndex` which is a bit similar to them, but is undefined on the work items that are not in the middle of a `CFGBlock`. I will eventually involve it, but it is far less problematic.

[2] Plus once at the beginning of the analysis, because apparently some nontrivial traversal happens before the first `dispatchWorkItem`.

[3] This information is used to conjure symbols, and need for new conjured symbols can arise practically anywhere deep within the call stack, so there is no natural boundary for restricting read access. This is why I don't want to pass around this info in parameters -- it would constantly force refactoring.

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