charN_t represent code units of different UTF encodings. Therefore the
values of 2 different charN_t objects do not represent the same
characters.
In order to avoid comparing apples and oranges, we add new warnings to
warn on:
- Implicit conversions
- Comparisons
- Other cases involving arithmetic conversions
We only produce the warning if we cannot establish the comparison would
be safe through constant evaluation.
The new `-Wimplicit-unicode-conversion` warning is enabled by default.
Note that this PR intentionally doesn;t touches char/wchar_t, but it
would be worth considering also warning on extending the new warnings to
these types (in a follow up)
Additionally most arithmetic operations on charN_t don't really make
sense (ie what does it mean to addition code units), so we could add
warnings for that.
Fixes#138526
This test currently hardcodes which environments have got 80 bit long
doubles on x86_64 with a suitable printf formatting; convert the
architecture check into a check specifically for 80 bit long doubles.
Not all x86_64 configurations do have 80 bit long doubles (e.g.
Android doesn't), and i386 configurations can also have 80 bit long
doubles, compatible with this test.
Also clarify the exact reasons for why specific OSes such as FreeBSD are
skipped for these tests, even though they have 80 bit long doubles.
The Apple runners automatically pick up newer XCode versions breaking
the CI. This disables the test to get the CI green which allows us to
investigate the issue properly later on.
This reverts commit d1156fcb56891fb1a426c3e8331a51d47f98a1b8.
This patch fixes the reported incorrect formatting changes and adds
tests for them. The performance should be unaffected, since there are no
significant changes required to fix the bugs.
Specifically, a `>` was changed to a `>=` to also add a `+` in the zero
case, and we're checking for zero now before printing the octal and
hexadecimal prefixes.
Closes#131710
In 0547e573c555, I introduced backdeployment testing on macOS using
Github-provided builders. This was done by basically building libc++ on
a slightly older macOS (like macOS 13) and then running against the
system library on that machine. However, that created a dependency that
libc++ must keep working on macOS 13, which doesn't support the
latest-released Xcode.
This patch solves that problem by moving the deployment testing to a
newer version of macOS which supports the latest-released version of
Xcode.
Sadly, that also reduces the backdeployment coverage we have since we're
not actually testing on older OSes, but is necessary to satisfy the
documented libc++ support policy. In the future, we could improve the
situation by providing a Lit configuration that allows compiling (but
not running) all the tests, building the tests on a supported macOS, and
then shipping those tests on an older backdeployment target in order to
run them against the system library. Since that requires significant
engineering, this isn't done at this time.
`money_get::do_get` needs to be fixed to handle extremely huge input
(e.g. more than 100 digits).
1. `__double_or_nothing` needs to copy the contents of the stack buffer
on the initial allocation.
2. The `sscanf` call in `do_get` needs to scan the dynamic buffer if
dynamic allocation happens.
There are 2 problems today that this PR resolves:
libcxx tests assume the thousands separator for fr_FR locale is x00A0 on
Windows. This currently fails when run on newer versions of Windows (it
seems to have been updated to the new correct value of 0x202F around
windows 11. The exact windows version where it changed doesn't seem to
be documented anywhere). Depending the OS version, you need different
values.
There are several ifdefs to determine the environment/platform-specific
locale conversion values and it leads to maintenance as things change
over time.
This PR includes the following changes:
- Provide the environment's locale conversion values through a
substitution. The test can opt in by placing the substitution value in a
define flag.
- Remove the platform ifdefs (the swapping of values between Windows,
Linux, Apple, AIX).
This is accomplished through a lit feature action that fetches the
environment's locale conversions (lconv) for members like
'thousands_sep' that we need to provide. This should ensure that we
don't lose the effectiveness of the test itself.
In addition, as a result of the above, this PR:
- Fixes a handful of locale tests which unexpectedly fail on newer
Windows versions.
- Resolves 3 XFAIL FIX-MEs.
Originally submitted in https://github.com/llvm/llvm-project/pull/86649.
Co-authored-by: Rodrigo Salazar <4rodrigosalazar@gmail.com>
This patch adds a large number of missing includes in the libc++ headers
and the test suite. Those were found as part of the effort to move
towards a mostly monolithic top-level std module.
This fixes testing with MinGW, if built without
__USE_MINGW_ANSI_STDIO=1.
On x86 MinGW, such a configuration fails printf tests with long doubles
due to mismatches between 80 and 64 bit long doubles - but on ARM,
there's no such issue, so building without __USE_MINGW_ANSI_STDIO=1 is
perfectly valid there.
Add another similar XFAIL to a libcxxabi test; this test isn't executed
in MSVC environments, so no XFAIL has been needed so far.
clang_modules_include.gen.py works now, and I added some background to
classic_table.pass.cpp.
Opened https://github.com/picolibc/picolibc/issues/778 to see if that
one is possible to fix.
This patch contains a number of small portability improvements for the
test suite, making it easier to run the test suite with other standard
library implementations.
- Guard checks for _LIBCPP_HARDENING_MODE to avoid -Wundef
- Avoid defining _LIBCPP_HARDENING_MODE even when no hardening mode is
specified -- we should use the default mode of the library in that case.
- Add missing includes and qualify a few function calls.
- Avoid opening namespace std to forward declare stdlib containers. The
test suite should represent user code, and user code isn't allowed to do
that.
This patch removes many annotations that are not relevant anymore since
we don't support or test back-deploying to macOS < 10.13. It also cleans
up raw usage of target triples to identify versions of dylibs shipped on
prior versions of macOS, and uses the target-agnostic Lit features
instead. Finally, it reorders both the Lit backdeployment features and
the corresponding availability macros in the library in a way that makes
more sense, and reformulates the Lit backdeployment features in terms of
when a version of LLVM was introduced instead of encoding the system
versions on which it hasn't been introduced yet. Although one can be
derived from the other, encoding the negative form is extremely
error-prone.
Fixes#80901
We were not making any distinction between e.g. the "Apple-flavored"
libc++ built from trunk and the system-provided standard library on
Apple platforms. For example, any test that would be XFAILed on a
back-deployment target would unexpectedly pass when run on that
deployment target against the tip of trunk Apple-flavored libc++. In
reality, that test would be expected to pass because we're running
against the latest libc++, even if it is Apple-flavored.
To solve this issue, we introduce a new feature that describes whether
the Standard Library in use is the one provided by the system by
default, and that notion is different from the underlying standard
library flavor. We also refactor the existing Lit features to make a
distinction between availability markup and the library we're running
against at runtime, which otherwise limit the flexibility of what we can
express in the test suite. Finally, we refactor some of the
back-deployment versions that were incorrect (such as thinking that LLVM
10 was introduced in macOS 11, when in reality macOS 11 was synced with
LLVM 11).
Fixes#82107
This is a follow on to https://github.com/llvm/llvm-project/pull/92312,
where we address some more locale platform differences. These are:
- for locale fr_FR AIX libc expects `U202F` as `LC_MONETARY`
`thousands_sep`
- for locale zh_CN AIX libc `LC_MONETARY` has `n_sign_posn == 1`,
indicating the `negative_sign` should come before the `currency_symbol`
string
Similar to some other platforms, AIX uses ' ' for non-wide characters
and U202F for wide characters, so this change opts into those paths for
AIX as well.
This PR implements [LWG2381](https://cplusplus.github.io/LWG/issue2381)
by rejecting `'i'`, `'I'`, `'n'`, `'N'` in FP parsing, as inf and NaN
are intendedly rejected by that LWG issue.
The source character array used for parsing is
`"0123456789abcdefABCDEFxX+-pPiInN"`, whose first 26 or 28 characters
are used for parsing integers or floating-point values respectively.
Previously, libc++ used 32 characters, including `'i'`, `'I'`, `'n'`,
`'N'`, for FP parsing, which was inconsistent with LWG2381. This PR also
replaces magic numbers 26 and 28 (formerly 32) with named constants.
Drive-by change: when the first character (possibly after the leading
`'+'` or `'-'`) is not a decimal digit but an acceptable character
(e.g., `'p'` or `'e'`), the character is not accumulated now (per Stage
2 in [facet.num.get.virtuals]/3).
#65168 may be rendered invalid, see
https://github.com/llvm/llvm-project/pull/65168#issuecomment-1868533342.
Apple back-deployment targets remain broken, likely due to dylib. XFAIL
is marked in related tests.
---------
Co-authored-by: Mark de Wever <koraq@xs4all.nl>
The `grouping` string for locale `en_US.UTF-8` and `fr_FR.UTF-8` on AIX
is `3`. This is different from Linux's `3;3` but is the same as Windows.
This patch removes `XFAIL: LIBCXX-AIX-FIXME` and changes to use the
`WIN32` code path.
The C locale on AIX uses `ISO-8859-1`, where `0xFB` is a valid
character. Widening char(-5) succeeds and produces L'\u00fb' the same as
on macOS, FreeBSD, and Windows. This patch removes `XFAIL:
LIBCXX-AIX-FIXME` and uses the macOS, FreeBSD, and WIN32 code path for
AIX.
One or two of the tests need slight tweaks to make them pass when
building with musl.
This patch is a re-application of b61fb18 which was reverted in 0847c90
because it broke the build.
rdar://118885724
Co-authored-by: Alastair Houghton <ahoughton@apple.com>
The specialization was non-conforming because it was missing a bunch of
member functions. Those were missing probably just as an oversight
coupled with a bit of laziness -- the rule that user-defined
specializations need to match the base template is usually OK to take
with a grain of salt, but not when the code is supposed to be portable,
which our test suite aims to be.
Fixes#74214
This patch actually runs the tests for picolibc behind an emulator,
removing a few workarounds and increasing coverage.
Differential Revision: https://reviews.llvm.org/D155521
This patch fixes one case where the decoding member function `in()` was
returning `partial` instead of `error`. Additionally, it adds large
testsuite that tests all `codecvt` facets that were added in C++11 and
in C++20. The testsuite covers this bug.
Fixes#60177.
The creation of the global and the classic locales was pretty twisty.
This patch refactors how this is done to reduce the amount of
indirections and prepare the terrain for a future where GCC implements
the no_destroy attribute.
Mark tests as necessary to accommodate Android L (5.0 / API 21) and up.
Add three Android lit features:
- android
- android-device-api=(21,22,23,...)
- LIBCXX-ANDROID-FIXME (for failures that need follow-up work)
Enable an AIX workaround in filesystem_test_helper.h for the broken
chmod on older Android devices.
Mark failing test with XFAIL or UNSUPPORTED:
- Mark modules tests as UNSUPPORTED, matching other configurations.
- Mark a gdb test as UNSUPPORTED.
- XFAIL tests for old devices that lack an API (fmemopen).
- XFAIL various FS tests (because SELinux blocks FIFO and hard linking,
because fchmodat is broken on old devices).
- XFAIL various locale tests (because Bionic has limited locale
support). (Also XFAIL an re.traits test.)
- XFAIL some print.fun tests because the error exception has no system
error string.
- Mark std::{cin,wcin} tests UNSUPPORTED because they hang with
adb_run.py on old devices.
- Mark a few tests UNSUPPORTED because they allocate too much memory.
- notify_one.pass.cpp is flaky on Android.
- XFAIL libc++abi demangler test because of Android's special long
double on x86[-64].
N.B. The `__ANDROID_API__` macro specifies a minimum required API level
at build-time, whereas the android-device-api lit feature is the
detected API level of the device at run-time. The android-device-api
value will be >= `__ANDROID_API__`.
This commit was split out from https://reviews.llvm.org/D139147.
Fixes: https://github.com/llvm/llvm-project/issues/69270
This is to fix an error that occurs when the char type is a class type.
Thanks to Yichen Yan for the patch.
Differential Revision: https://reviews.llvm.org/D100005
On GLibc, FreeBSD and macOS systems nl_catd is a pointer type, and
round-tripping this in a variable of ptrdiff_t is not portable.
In fact such a round-trip yields a non-dereferenceable pointer on
CHERI-enabled architectures such as Arm Morello. There pointers (and
therefore intptr_t) are twice the size of ptrdiff_t, which means casting
to ptrdiff_t strips the high (metadata) bits (as well as a hidden pointer
validity bit).
Since catalog is now guaranteed to be the same size or larger than nl_catd,
we can store all return values safely and the shifting workaround from
commit 0c68ed006d4f38c3cdcab6a565aa3e208015895f should not be needed
anymore (this is also not portable to CHERI systems on since shifting a
valid pointer right will create a massively out-of-bounds pointer that
may not be representable).
This can be fixed by using intptr_t which should be the same type as
ptrdiff_t on all currently supported architectures.
See also: https://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2028
Differential Revision: https://reviews.llvm.org/D134420
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
When using the following constructors:
```
locale(const locale& other, const char* std_name, category cat);
locale(const locale& other, const string& std_name, category cat);
locale(const locale& other, const locale& one, category cats);
```
The new locale name is always "*". Locale names formed from parts of two named locales (that is, C++ locales having names) are supposed to have names in turn (see C++20 subclause 28.3.1.1 [locale.general] paragraph 8). This patch fixes the name construction for cases when either of locales are unnamed, when the category is locale::none, and when the two locale names are the same.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D119441
Those were found while trying to enable configurations like no-threads
and no-localization with Clang modules enabled.
Differential Revision: https://reviews.llvm.org/D153977
LIBCXX_ENABLE_FILESYSTEM should represent whether the platform has
support for a filesystem, not just whether we support <filesystem>.
This patch slightly generalizes the setting to also encompass whether
we provide <fstream>, since that only makes sense when a filesystem is
supported.
Differential Revision: https://reviews.llvm.org/D152168
This is an ongoing series of commits that are reformatting our
Python code.
Reformatting is done with `black`.
If you end up having problems merging this commit because you
have made changes to a python file, the best way to handle that
is to run git checkout --ours <yourfile> and then reformat it
with black.
If you run into any problems, post to discourse about it and
we will try to help.
RFC Thread below:
https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style
Reviewed By: #libc, kwk, Mordante
Differential Revision: https://reviews.llvm.org/D150763
This omission seems to be there for a long time, it's in the initial
libc++ import. This was discovered while working on the std modules.
Reviewed By: #libc, philnik
Differential Revision: https://reviews.llvm.org/D147850
The use_system_cxx_lib Lit feature was only used for back-deployment
testing. However, one immense hole in that setup was that we didn't
have a proper way to test Apple's own libc++ outside of back-deployment,
which was embodied by the fact that we needed to define _LIBCPP_DISABLE_AVAILABILITY
when testing (see change in libcxx/utils/libcxx/test/params.py).
This led to the apple-system testing configuration not checking for
availability markup, which is obviously quite bad since the library
we ship actually has availability markup.
Using stdlib=<VENDOR>-libc++ instead to encode back-deployment restrictions
on tests is simpler and it makes it possible to naturally support tests
such as availability markup checking even in the tip-of-trunk Apple-libc++
configuration.
Differential Revision: https://reviews.llvm.org/D146366
Instead of writing something like `XFAIL: use_system_cxx_lib && target=...`
to XFAIL back-deployment tests, introduce named Lit features like
`availability-shared_mutex-missing` to represent those. This makes the
XFAIL annotations leaner, and solves the problem of XFAIL comments
potentially getting out of sync. This would also make it easier for
another vendor to add their own annotations to the test suite by simply
changing how the feature is defined for their OS releases, instead
of having to modify hundreds of tests to add repetitive annotations.
This doesn't touch *all* annotations -- only annotations that were widely
duplicated are given named features (e.g. when filesystem or shared_mutex
were introduced). I still think it probably doesn't make sense to have a
named feature for every single fix we make to the dylib.
This is in essence a revert of 2659663, but since then the test suite
has changed significantly. Back when I did 2659663, the configuration
files we have for the test suite right now were being bootstrapped and
it wasn't clear how to provide these features for back-deployment in
that context. Since then, we have a streamlined way of defining these
features in `features.py` and that doesn't impact the ability for a
configuration file to stay minimal.
The original motivation for this change was that I am about to propose
a change that would touch essentially all XFAIL annotations for back-deployment
in the test suite, and this greatly reduces the number of lines changed
by that upcoming change, in addition to making the test suite generally
better.
Differential Revision: https://reviews.llvm.org/D146359
