This is an archive of the discontinued LLVM Phabricator instance.

[libc] Improve information printed on failure of a math test which uses MPFR.
ClosedPublic

Authored by sivachandra on May 1 2020, 12:30 PM.

Details

Summary

A new test matcher class MPFRMatcher is added along with helper macros
EXPECT|ASSERT_MPFR_MATCH.

New type traits classes RemoveCV and IsFloatingPointType have been
added and used to implement the above class and its helpers.

Diff Detail

Event Timeline

sivachandra created this revision.May 1 2020, 12:30 PM
Herald added a project: Restricted Project. · View Herald TranscriptMay 1 2020, 12:30 PM

Remove the long double instantiation.
Can add it back when we deal with long double in future.

I don't want to make any suggestions yet because I don't fully understand why we need a MPFR_TEST. Would you mind clarifying the need for TEST_WITH_BASE_CLASS? Instead of MPFR_TEST could we have TEST_EXTENSION's first argument take a class with compare, would that simplify it? I'm by no means a gtest expert, I'm not sure how someone would use gtest to fill these kinds of needs. Maybe they would make their own macros which end up calling FAIL or using matchers. We aren't limited to that though so perhaps these would end up being more complicated than this solution.

libc/utils/CPP/TypeTraits.h
50–52

type -> Type

On that note, we could make an analog to std::type_identity and make this
template <typename T> struct RemoveCV : TypeIdentity<T> {};. No strong preference though.

libc/utils/MPFRWrapper/MPFRUtils.cpp
26–27

Is there a reason that this is not just a static method of MPFRNumber?

91

Might as well use mpfr_snprintf?

121–123

We can just keep streaming instead of ending the statement and calling llvm::outs() again perhaps? That would be stylistically similar to what we have in Test.cpp

libc/utils/MPFRWrapper/MPFRUtils.h
72–74

We aren't enabling another specialization when this isn't true so could we just make this a static_assert?

I don't want to make any suggestions yet because I don't fully understand why we need a MPFR_TEST. Would you mind clarifying the need for TEST_WITH_BASE_CLASS? Instead of MPFR_TEST could we have TEST_EXTENSION's first argument take a class with compare, would that simplify it? I'm by no means a gtest expert, I'm not sure how someone would use gtest to fill these kinds of needs. Maybe they would make their own macros which end up calling FAIL or using matchers. We aren't limited to that though so perhaps these would end up being more complicated than this solution.

Huh! I totally missed that we have matchers now with which we can do the exact same thing as in this patch. Will change it to use the matcher API and update soon.

sivachandra marked 3 inline comments as done.
  • Use a matcher instead of special test class.
  • Addressed relevant comments.
sivachandra edited the summary of this revision. (Show Details)May 4 2020, 3:30 PM
sivachandra added inline comments.May 4 2020, 3:33 PM
libc/utils/CPP/TypeTraits.h
50–52

At the least it avoid typos like the one you found. So, done.

abrachet added inline comments.May 4 2020, 7:36 PM
libc/utils/CPP/TypeTraits.h
57

I believe that typename shouldn't be required and RemoveCV<T>::Type should be enough.

libc/utils/MPFRWrapper/MPFRUtils.cpp
11

No longer needed, I believe

29–41

Do these need to be enable if specializations could they just be overloads?

43–44

Could this also be just a static_assert?

libc/utils/MPFRWrapper/MPFRUtils.h
75–77

Can this one also be static_assert?

sivachandra marked 6 inline comments as done.
sivachandra edited the summary of this revision. (Show Details)

Address comments.

sivachandra added inline comments.May 4 2020, 10:38 PM
libc/utils/CPP/TypeTraits.h
57

RemoveCV<T>::Type is a dependent type and should require typename? I tried your suggestion and that is what the compiler also tells me:

TypeTraits.h:57:44: error: missing 'typename' prior to dependent type name 'RemoveCV<T>::Type'
libc/utils/MPFRWrapper/MPFRUtils.cpp
29–41

Yes. Having explicit enables avoids implicit conversions of the arguments. Implicit conversions can potentially lead of loss of precision. Added a comment saying the same.

43–44

Again, are you suggesting to put a static_assert inside the function body? If yes, it feels a bit odd to error-out with a custom message rather than give a normal compiler message for a constructor.

libc/utils/MPFRWrapper/MPFRUtils.h
75–77

Done, but I assumed you meant we should instead put a static_assert inside the function body? I think that makes sense. But, see my comment at the other place. I don't have any strong preference, but I do see that in this case the static_assert inside the function body is much nicer.

abrachet accepted this revision.May 4 2020, 10:42 PM

LGTM

libc/utils/CPP/TypeTraits.h
57

My mistake, I thought it wasn't necessary because the right hand side of a using can only be a type.

libc/utils/MPFRWrapper/MPFRUtils.cpp
43–44

Sounds good to keep it like this then

This revision is now accepted and ready to land.May 4 2020, 10:42 PM
This revision was automatically updated to reflect the committed changes.