Previously there were several attempts to make the format checks for NaN
and Inf work across platforms, like AIX and Solaris, that print these
values slightly differently. This resulted in a number of forward fixes,
until we finally disabled the tests for NaN and Inf. This change should
make the test robust across different platforms, and reduce the overall
amount of code by delegating to helper functions that use the same
format strings as the implementations used by PrintNumber().
This additionally reverts commit 5a9bad171be5dfdf9430a0f6cbff14d29ca54181
and fa56e362af475e0758cfb41c42f78db50da7235c.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D146851
This is still breaking on some platforms. The underlying implementation
doesn't seem to be the cause, rather the test is not robust across
platforms. So, we'll just disable this for the time being, to unblock
builds until we have a proper fix.
Reviewed By: abhina.sreeskantharajan
Differential Revision: https://reviews.llvm.org/D146834
NaN and Inf are still causing some problems in a formatting test.
This patch makes the checked format string exactly match the internal
JSON format string. If there are still problems, we should disable
testing Inf and NaN values until we can come to a portable solution.
Reviewed By: abhina.sreeskantharajan
Differential Revision: https://reviews.llvm.org/D146818
When fixing the test earlier, we missed the JSON case for NaN and INF,
so handle those the same as for non-JSON, by creating the string
dynamically.
Reviewed By: abhina.sreeskantharajan
Differential Revision: https://reviews.llvm.org/D146739
The test strings we used for infinity and NAN were not correct on AIX.
This patch creates those dynamically instead of hard-coded.
Reviewed By: abhina.sreeskantharajan
Differential Revision: https://reviews.llvm.org/D146542
llvm-readobj will need the ability to print floats for use in
HashHistograms. This adds that functionality to the ScopedPrinter and
JSONScopedPrinter.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D145277
Today the JSON uses `Value` and `RawValue` when printing `Flags`, when really
the `Value` field is always the name of an Enum variant, and `RawValue` is its
underlying numeric value. Similarly, we rename the `RawFlags` key to `Value`,
to match the new scheme. This also allows JSON parsing to use consistent logic
for `Flag` types.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D137091
Use deduction guides instead of helper functions.
The only non-automatic changes have been:
1. ArrayRef(some_uint8_pointer, 0) needs to be changed into ArrayRef(some_uint8_pointer, (size_t)0) to avoid an ambiguous call with ArrayRef((uint8_t*), (uint8_t*))
2. CVSymbol sym(makeArrayRef(symStorage)); needed to be rewritten as CVSymbol sym{ArrayRef(symStorage)}; otherwise the compiler is confused and thinks we have a (bad) function prototype. There was a few similar situation across the codebase.
3. ADL doesn't seem to work the same for deduction-guides and functions, so at some point the llvm namespace must be explicitly stated.
4. The "reference mode" of makeArrayRef(ArrayRef<T> &) that acts as no-op is not supported (a constructor cannot achieve that).
Per reviewers' comment, some useless makeArrayRef have been removed in the process.
This is a follow-up to https://reviews.llvm.org/D140896 that introduced
the deduction guides.
Differential Revision: https://reviews.llvm.org/D140955
