Without this, GCC gets upset that this class has a field, output, that has
hidden visibility while the class itself has default visibility.

This option was deprecated in ad022eb0 in favor
of the more general --smt-prelude option.

This was previously deprecated in
f375d67d, over six months ago.

No need to implement this within murphi2c now that an equivalent exists inside
the library.

This replicates murphi2c/src/name_rules.cc inside librumur. It turns out this
functionality is generally useful for most code generators. There are some
latent plans to implement translation to some other languages. Rather than
requiring these translators to reimplement the same functionality, we can
consolidate this within librumur itself.

The symbols that are intended to be part of the public librumur API are now
qualified with visibility("default") when compiling the library and then
visibility("hidden") when including the public rumur.h header. The exception are
symbols that need Run-Time Type Information (RTTI), exceptions that are thrown
and classes that may need to be dynamically disambiguated. These need to always
have default visibility to work across library boundaries.

This occurs with the model tests/for-step-0-dynamic.m.

The underflow check discussed in the prior commit was being done on raw values,
which in many cases involves converting a signed comparison to an unsigned
comparison. Additionally the comparison operator was incorrect in this reverse
iteration case.

Github: closes #211 “for loop underflow check incorrect?”

Rumur emits code to detect whether the final iteration of a for loop would cause
numeric overflow, resulting in an infinite loop or undefined behaviour in C, and
safely handles this situation. However, in the case of a reverse iteration
(negative step) we were incorrectly checking against the “lower bound” of the
loop which actually ends up being the upper bound in a reverse iteration. E.g.

  for i := 0 to -127 by 10 do
    …
  end;

In the above loop, the bound we need to check against for overflow is -127 which
is conceptually the lower bound, but during code generation is actually in the
`ub` variable.

Note that this is only part of the changes required for #211, because this is
only the condition of whether we *could* overflow. The test for whether we are
about to *actually* overflow is also broken.

Github: related to #211 “for loop underflow check incorrect?”

When Rumur infers a narrow signed type (e.g. int8_t) can be used to represent
scalars, the initialisation sequence used in for loops resulted in implicit
promotion to int and then implicit conversion back to the value type. This is
all intentional and not incorrect, but it appeared to the compiler as if the
generated code did not intend this final implicit conversion. By introducing
some casts, we squash this compiler warning.

The upcoming for-step-neg-overflow.m test case will demonstrate how to provoke
this situation.

Similarly to the previous commit, when using a fast type (e.g. int_fast8_t) the
backing type may not be the precise fixed width type (e.g int8_t). This can
result in VALUE_C(x) not actually producing a value of value_t type. There is no
fast type equivalent to e.g. INT8_C -- and if there was, we would not want to
use it as it might be overly permissive -- so we address this by simply casting
the VALUE_C result.

For some reason, in f5c8cc54 we did not switch
the lower limits of unsigned types to also use the _fast_ variants. I don't
think this caused any correctness issues, but it may be the cause of some
current -Wsign-compare warnings with tests/for-step-0-dynamic.m.

The previous refactor pushed us to 302 jobs. Travis’ limit is 200. This reduces
us down to 165.

Github: closes #208 "port test suite back to unittest"
Github: closes #210 "`optimised` is a no-op in the test suite"

This at least gets closer to what clang-format wants.

Time to stop caring about formatting. The one thing we unfortunately cannot
abide is moving the #include of location.hh above cstddef. Flex on some
platforms generates a location.hh that does not include stddef.h but uses
size_t, so it causes a compilation failure if we rearrange the headers.

The Bison-generated parser is now aware of the actual characters behind a token
name it has. So instead of syntax errors like "unexpected RSH" you get
"unexpected >>".

Currently debugging a curious problem wherein the murphi2c test of
tests/comment-escape.m passes on FreeBSD and macOS but fails on Linux. My
suspicion is that Glibc's isspace is returning something non-zero but with the
LSB unset for isspace(' ') which, when ANDed with the promoted value of `true`,
results in 0. I don't know if this hypothesis is correct or not, but it seems
wise to avoid these sort of bitwise operations on pseudo boolean values anyway.

Helpful for debugging.

This helps us find the murphi-comment-ls binary. We no longer test the installed
binaries, but I think we just have to live with that infidelity.

This is more straightforward and more bulletproof for dropping comments in
functions.

Github: related to #206 "murphi2c: preserve comments in translation"

Despite claims to the contrary, it seems GCC 4.7.3 doesn't fully support uniform
initialisation.

I was staring at the similar code in rumur/src/main.cc casting position scalars
and wondering why it was written that way. Then a CI failure reminded me that
old Bison does not generate a position with counter_type and, to add insult to
injury, it uses a different numeric type to newer Bison.

Github: closes #206 "murphi2c: preserve comments in translation"

Github: related to #206 "murphi2c: preserve comments in translation"