This is an archive of the discontinued LLVM Phabricator instance.

[libc++] Fix some tests that were broken in the single-threaded configuration
ClosedPublic

Authored by ldionne on Nov 19 2021, 6:51 AM.

Details

Summary

We never noticed it because our CI doesn't actually build against a C
library that doesn't have threading functionality, however building
against a truly thread-free platform surfaces these issues.

Diff Detail

Event Timeline

ldionne created this revision.Nov 19 2021, 6:51 AM
ldionne requested review of this revision.Nov 19 2021, 6:51 AM
Herald added a project: Restricted Project. · View Herald TranscriptNov 19 2021, 6:51 AM
Herald added a reviewer: Restricted Project. · View Herald Transcript
Mordante accepted this revision as: Mordante.Nov 19 2021, 7:08 AM
Mordante added a subscriber: Mordante.

LGTM when the CI is happy. Should we add a CI that test this configuration?

LGTM when the CI is happy. Should we add a CI that test this configuration?

Thanks for the review. We have CI for that configuration, however we don't have an actual C library that lacks support for threads. So we do have coverage, but it's not perfect. For each "freestanding slice" configuration, we could in theory create a small C library that forwards everything to the underlying C library, but which doesn't have the functionality we're excluding from that slice. But I believe that would reach diminishing returns.

LGTM when the CI is happy. Should we add a CI that test this configuration?

Thanks for the review. We have CI for that configuration, however we don't have an actual C library that lacks support for threads. So we do have coverage, but it's not perfect. For each "freestanding slice" configuration, we could in theory create a small C library that forwards everything to the underlying C library, but which doesn't have the functionality we're excluding from that slice. But I believe that would reach diminishing returns.

Fair point. At some point it would be nice to have an actual "freestanding" C library for these test purposes. But I agree it would be a waste of our time to try to create that. (Unless we have somebody with too much time on their hands ;-) )

jloser added a subscriber: jloser.Nov 19 2021, 7:41 AM
jloser added inline comments.
libcxx/utils/generate_feature_test_macro_components.py
657

I find it interesting that including <thread> would be a hard error rather than a no-op like other "unsupported features" when it comes to including other headers (like ranges, concepts, etc.). No action required, but just an observation.

ldionne marked an inline comment as done.Nov 19 2021, 7:54 AM

Fair point. At some point it would be nice to have an actual "freestanding" C library for these test purposes. But I agree it would be a waste of our time to try to create that. (Unless we have somebody with too much time on their hands ;-) )

Well, I wouldn't say it would be a waste of time -- I think it would be super useful and in fact it could help formalize what it means to support various levels of Freestanding, even for other C++ Standard Library implementations. However, yeah, it's not the highest on the priority list.

libcxx/utils/generate_feature_test_macro_components.py
657

We do have some inconsistency around that, however all features like "no-localization", "no-wide-characters", "no-random-device" are hard errors, and I think it makes the most sense. Indeed, what we're trying to model here is a platform that literally does not support these features. For example, on some platforms, you literally can't include <wchar.h>, because there is no such header. Putting an #error on our side is what models that best IMO.

Features like concepts are somewhat different, in that it's a matter of compiler support, where we try to be flexible and accommodate compilers that have incomplete support for X.

jloser added inline comments.Nov 19 2021, 8:37 AM
libcxx/utils/generate_feature_test_macro_components.py
657

Makes sense - thanks for the discussion.

Fair point. At some point it would be nice to have an actual "freestanding" C library for these test purposes. But I agree it would be a waste of our time to try to create that. (Unless we have somebody with too much time on their hands ;-) )

Well, I wouldn't say it would be a waste of time -- I think it would be super useful and in fact it could help formalize what it means to support various levels of Freestanding, even for other C++ Standard Library implementations. However, yeah, it's not the highest on the priority list.

Don't get me wrong, I would love to have better support for non-hosted builds. But I think it would be better to see whether we can use an existing non-hosted C library instead of writing our own. Maybe it would be possible to use LLVM's libc for that purpose. That is if we can easily disable some of their features.

ldionne accepted this revision as: Restricted Project.Nov 19 2021, 11:24 AM
ldionne marked an inline comment as done.

Don't get me wrong, I would love to have better support for non-hosted builds. But I think it would be better to see whether we can use an existing non-hosted C library instead of writing our own. Maybe it would be possible to use LLVM's libc for that purpose. That is if we can easily disable some of their features.

That's actually an interesting idea, I had not thought about that.

Generally speaking, it might also be a good idea to test whether libc++ even works on top of LLVM's on libc.

This revision is now accepted and ready to land.Nov 19 2021, 11:24 AM