Instead of having one function per precedence level, mirroring the BNF grammar,
this uses the "precedence climbing" algorithm with a table of operator
precedences (and a few special cases that don't fit into the table as it is).
This is a first pass -- it's probably possible to put more of the parser
into this form, e.g. to support prefix/suffix operators with precedence, if
necessary, or just to simplify the code more.
It may also be possible to speed this up by putting more useful information
into the tokens during tokenization, to avoid the extra branch on the token in
operInfo.
When trying to retrieve 80bit fp values from clang using
getValueAsApproximateDouble we'd eventually hit the ceiling value and
return infinity, an invalid value for a fp literal.
Add some logic to prevent this error and warn the user.
Closes#8602
It turns out that the endianness-detection header delivered with the
softfloat library is extremely brittle and gives wrong results when
targeting FreeBSD (long story short, _BIG_ENDIAN is always defined there
and that breaks the #if defined() chain).
Use our own endianness detection header to work around any potential
problem.
- original PR #7949 (incorrectly) patched a generated-file and changes
have subsequently been lost/overwritten
- fix#7947 in a different way: drop `ppc32` because `ppc` already exists
std/crypto: use finer-grained error sets in function signatures
Returning the `crypto.Error` error set for all crypto operations
was very convenient to ensure that errors were used consistently,
and to avoid having multiple error names for the same thing.
The flipside is that callers were forced to always handle all
possible errors, even those that could never be returned by a
function.
This PR makes all functions return union sets of the actual errors
they can return.
The error sets themselves are all limited to a single error.
Larger sets are useful for platform-specific APIs, but we don't have
any of these in `std/crypto`, and I couldn't find any meaningful way
to build larger sets.
These are currently incorrect according to the gitattributes(5) and
gitignore(5) man pages. However, it seems github ended up treating them
as we intended due to a bug until recently when that bug was fixed.
