[XLA] Fix compilation errors in exhaustive test

[DavidNorman]

When I compile the code in the exchaustive ops tests, I get an error. The internet seems to think that this error is due to the code being out of spec for standard C++, as shown here:

https://stackoverflow.com/questions/3052579/explicit-specialization-in-non-namespace-scope

and

https://stackoverflow.com/questions/2097811/c-syntax-for-explicit-specialization-of-a-template-function-in-a-template-clas

This change moves the template out of the enclosing class into a namespace, as the standard requires.

It also adds a constructor for the ErrorSpec class, which also fails to compile due to the use of the braces initialization.

My compiler version is gcc (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0

[DavidNorman]

done :)

[sanjoy]

lgtm

[bixia1]

I realized that this is not use, we can replace the use of IntegralT in the routine with int64.

[DavidNorman]

ok. will do.

[DavidNorman]

are you sure this is true? IntegralT is a type which depends on the template type T. This does vary from use to use of FillInput.

[bixia1]

Yes, IntegralT was left here while it should be remove after I added ConvertAndReplaceKnownIncorrectValueWith.

If input_val is a int64, ConvertAndReplaceKnownIncorrectValueWith will convert it to IntegralT.

  IntegralT input_val = i + begin;
  input_arr[i] = ConvertAndReplaceKnownIncorrectValueWith<T>(input_val, 0);

[bixia1]

After we remove the use of this template in the exhaustive_unary_test.cc, would it be better to put this back to the class as "private" or use anonymous namespace here?

[DavidNorman]

you still cannot have a specialization of a template class embedded inside a class in official c++. so it has to remain in a separate namespace.

[DavidNorman]

although it could be an anonymous namespace as you say

[DavidNorman]

see comment above - i don't think that IntegralT can be removed from the FillInput function

[bixia1]

See my reply above - I think we should be able to remove IntegralT from FillInput.

[bixia1]

I understand that IntegralT is not int64, but we can still replace IntegralT with int64 here, because ConvertAndReplaceKnownIncorrectValueWith will ensure that we will retrieve the right bits from input_val. I am approving this and will make the change I am talking about later.

[DavidNorman]

regarding the windows test failure, it seems very very unlikely that this change can have caused the failure:

AttributeError: Can't pickle local object 'TFRecordWriterCloseAndFlushTests.testFlush.<locals>.childProcess'