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