Description
As part of #117 I added an assembler type that wraps spirv-tools' assembler, however, I ran into a super strange issue that I still haven't found the root cause of.
Basically usage of some of C++'s (i)stringstream would work when being called from eg and example executable that statically linked the spirv-tools library (but not the c++ stdlib), but would, when part of the librustc_codegen_spirv shared library, result in, in the case of std::stringstream bad cast exception with a perfect ordinary uint32_t, or, in the case of std::istringstream fail to parse eg "42" and set the "bad" bit.
It is kind of frustrating as, AFAICT, the inputs would be the exact same (I even hashed them) going through the same calls, with the same options, and then one would work as intended and the other would fail, suggesting some kind of global state or possibly memory stomps? Anway, this only seemed to effect libstdc++, as windows and mac builds worked fine.
I finally just got fed up and replaced most of the number parsing in the assembler, see the diff for what I ended up doing to work around this in most cases (need to support hexadecimals floats still).
Anyway, long story short, the spir-v assembly syntax is relatively straightforward, it shouldn't? be terribly difficult to replace the need for the spirv-tools' assembler, we can even take advantage of their excellent suite of tests.