[clang] [clang-tools-extra] RFC: [clang-tidy] [analyzer] Nondeterministic pointer usage improvements (PR #110471)

[via cfe-commits]

whisperity wrote:

> And to determine if it's bad one needs to understand how the result of the lookup or the individual elements of the iteration are used.

And the issue here is that, in the extreme case, even a completely omniscient call graph oracle would still fail at proving immunity to non-determinism even in your second case, because the determinism requirement could come from something like `FileCheck` ran externally to the code that executed a non-deterministic order.

I'm unsure as to what the right approach would be here. I was thinking about instead marking every variable or field declared with a type like `known-unordered-container-type <T*>` instead of the for loops themselves, but then we are essentially trying to say that this partial specialisation is "deprecated" in a way... "you shouldn't put pointers into this because no matter what you do, it will have a non-deterministic order"... and???

But your second example, @steakhal, touches on the problem nicely. What if we tried to match archetypes of "container elements are printed" or "container elements are sent to the network"? It will never be a complete list, but we *could* reasonably assume (at least this is a safe-ish generalisation, and for everything else, there is NOLINT...) that if the order escapes via some I/O, then non-determinism is... maybe if not outright __bad__, but definitely uncanny, if for nothing else, due to the troubles it causes when debugging. 😉 

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