nonloc::SymbolVal that contains a pointer-type or reference-type symbol is ill-formed; our code isn't prepared to work with such values. The canonical way of representing symbolic pointers is loc::MemRegionVal that wraps a SymbolicRegion for the respective symbol. For representing results of casting pointers into integers we have nonloc::LocAsInteger.
This is the one assertion that i regret accidentally omitting in D26837, because it's very fundamental.
The assertion indeed mostly holds on our tests; i found one violation (in my own code), but the ill-formed SVal was only used in intermediate computations and was never put into the program state.
https://bugs.llvm.org/show_bug.cgi?id=37802 contains another example of an ill-formed SVal of this kind, which causes a crash. This patch doesn't address that crash yet.
So what is the difference here? That SVB.makeSymbolVal is not always a nonloc?