-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
test: Fix running spec tests that expect NaN result #484
Conversation
afa6887
to
9e58854
Compare
Codecov Report
@@ Coverage Diff @@
## master #484 +/- ##
========================================
Coverage 99.56% 99.56%
========================================
Files 54 54
Lines 16858 17015 +157
========================================
+ Hits 16784 16941 +157
Misses 74 74 |
a1c54c0
to
20beae1
Compare
test/spectests/spectests.cpp
Outdated
const uint64_t uint_value = std::stoull(v.at("value").get<std::string>()); | ||
/// The unsigned integer type matching the size of this floating-point type. | ||
using UintType = std::conditional_t<std::is_same_v<T, float>, uint32_t, uint64_t>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
using UintType = std::conditional_t<std::is_same_v<T, float>, uint32_t, uint64_t>; | |
using UintType = FP<T>::UintType; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please squash two last commits.
v.at("type").get<std::string>() == "f32" || v.at("type").get<std::string>() == "f64"); | ||
assert(!is_canonical_nan(v) && !is_arithmetic_nan(v)); | ||
|
||
// JSON tests have all values including floats serialized as 64-bit unsigned integers. | ||
const uint64_t uint_value = std::stoull(v.at("value").get<std::string>()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gumb0 Did not mention before merging, because this question affected master
too (e.g. not introduced via this PR): do we want to wrap any of these in proper exception handling for invalid inputs (see https://en.cppreference.com/w/cpp/string/basic_string/stoul for invalid_argument
or out_of_range
) or it is fine leaving it to the general exception catching we have?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually it would be nice to output a line number in the case of exception, now you see only that exception happened somewhere in the file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wait until it happens again.
No description provided.