This is an archive of the discontinued LLVM Phabricator instance.

[libc] make part of libc's unit test framework independent of llvm
ClosedPublic

Authored by michaelrj on Nov 16 2020, 2:28 PM.

Details

Summary

This is mostly changing stringref to std::string, outs() to cout,
and small supporting changes. This will make running unit tests possible
on systems that are only grabbing the libc part of llvm.

Diff Detail

Event Timeline

michaelrj created this revision.Nov 16 2020, 2:28 PM
Herald added a project: Restricted Project. · View Herald TranscriptNov 16 2020, 2:28 PM
michaelrj requested review of this revision.Nov 16 2020, 2:28 PM

This will make running unit tests possible on systems that are only grabbing the libc part of llvm.

Do our tests depend on the generated headers? I thought they did, if so it will be very hard to remove our dependency on the rest of llvm.

Do our tests depend on the generated headers? I thought they did, if so it will be very hard to remove our dependency on the rest of llvm.

Yes the tests depend on the generated headers, but it's possible to handwrite the headers if necessary, or even prebuild the headergen tool. This is what I've been doing for the project I've been working on, and this patch will let me run the unit tests.

update: I was reminded of the other patch that I'm currently in the process of getting reviewed (linked here: https://reviews.llvm.org/D91394) that will make the string and math tests independent of headergen since they can use the system libc's header. This means if I can make the unit tests fully independent then you can bring up both the string and math parts of LLVM-libc without the whole project.

sivachandra accepted this revision.Nov 17 2020, 10:41 AM
This revision is now accepted and ready to land.Nov 17 2020, 10:41 AM

The LibcUnitTest and libc_test_utils targets are made with add_llvm_library and link against Support. Presumably we would need use add_library, (although it may not be the case that add_llvm_library implicitly adds any LLVM dependencies, I haven't checked).

libc_test_utils also has a small dependency on llvm::ostream and llvm::MemoryBuffer. I feel bad just bringing it up without just changing it myself because I think a lot of that code was added by me, but I don't really have time to work on it until after my semester ends, unfortunately.

The LibcUnitTest and libc_test_utils targets are made with add_llvm_library and link against Support. Presumably we would need use add_library, (although it may not be the case that add_llvm_library implicitly adds any LLVM dependencies, I haven't checked).

libc_test_utils also has a small dependency on llvm::ostream and llvm::MemoryBuffer. I feel bad just bringing it up without just changing it myself because I think a lot of that code was added by me, but I don't really have time to work on it until after my semester ends, unfortunately.

Ah yes! The build rules slipped my mind. I will take a shot at it.

The LibcUnitTest and libc_test_utils targets are made with add_llvm_library and link against Support. Presumably we would need use add_library, (although it may not be the case that add_llvm_library implicitly adds any LLVM dependencies, I haven't checked).

libc_test_utils also has a small dependency on llvm::ostream and llvm::MemoryBuffer. I feel bad just bringing it up without just changing it myself because I think a lot of that code was added by me, but I don't really have time to work on it until after my semester ends, unfortunately.

Ah yes! The build rules slipped my mind. I will take a shot at it.

To be fair though, Michael said he will make another pass and clean up the rest of the pieces having LLVM dependency.

I guess I've got some more changes ahead of me. This new commit (linked here) is where I plan on putting the next set, and it currently has a few based on what you've said.