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.
Details
- Reviewers
Mordante - Group Reviewers
Restricted Project - Commits
- rGe1ce3dabf0c7: [libc++] Fix some tests that were broken in the single-threaded configuration
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
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 ;-) )
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. |
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. |
libcxx/utils/generate_feature_test_macro_components.py | ||
---|---|---|
657 | Makes sense - thanks for the discussion. |
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.
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.