This is an archive of the discontinued LLVM Phabricator instance.

[flang][msvc] Fix external-io unittest.
ClosedPublic

Authored by Meinersbur on Jul 23 2021, 4:43 PM.

Details

Summary

Fix the external-io unittest under Windows.

In particular, fixes the following issues:

  1. When creating a temporary file, open it with read+write permissions.
  2. _chsize returns 0 on success (just like ftruncate).
  3. To set a std::optional, use its assign-operator overload instead of getting a reference of its value an overwrite that. The latter is invalid if the std::optional has no value, and is caught by msvc's debug STL.

The non-GTest unittest is currently not executed under Windows because of the added .exe extension to the output file: external-io.text.exe. llvm-lit skips the file because .exe is not in the lists of test suffixes (.test is). D105315 is going to change that by converting it to a gtest-test.

Diff Detail

Event Timeline

Meinersbur created this revision.Jul 23 2021, 4:43 PM
Meinersbur requested review of this revision.Jul 23 2021, 4:43 PM
Herald added a project: Restricted Project. · View Herald TranscriptJul 23 2021, 4:43 PM
awarzynski accepted this revision.Jul 26 2021, 11:34 AM

These changes make a lot of sense to me. This is making sure that WIN32 implementation is consistent with Linux/Unix and it fixes bugs that we probably missed because the affected tests are skipped on Windows.

I don't have a Windows machine to test this on, but this looks fairly straightforward and I think that it is safe to approve it as is. I think that Phabricator's CI would highlight any potential issues with this.

Does it make sense to make D105315 depend on this and let the CI on Phabricator test it for us?

This revision is now accepted and ready to land.Jul 26 2021, 11:34 AM
This revision was automatically updated to reflect the committed changes.

I don't have a Windows machine to test this on, but this looks fairly straightforward and I think that it is safe to approve it as is. I think that Phabricator's CI would highlight any potential issues with this.

I just pushed the patch. That is, when https://reviews.llvm.org/D105315 is updated and the pre-merge bot runs again (maybe re-upload the same diff again?),we should see the result.

Does it make sense to make D105315 depend on this and let the CI on Phabricator test it for us?

Since I just pushed the patch, it does not matter. Otherwise it could have made sense such that the pre-merge builder would apply this patch beforehande before compiling D105315.

I added D105315 as a child revision; maybe this also triggers a re-run of the pre-merge check of D105315.