Re: Add dg-require-wchars to libstdc++ testsuite

[Alexandre Oliva <oliva@adacore.com>]

On Jan 14, 2021, Jonathan Wakely <jwakely@redhat.com> wrote:

> The problem is that <bits/locale_conv.h> uses wchar_t in default
> template arguments:

> I think we should fix the header, not disable tests that don't use
> that default template argument. The attached patch should allow you to
> use wstring_convert and wbuffer_convert without wchar_t support. The
> tests which instantiate it with char16_t or char32_t instead of
> wchar_t should work with this patch, right?

Thanks, I'll give it a spin.  That said, ...

> <aside>
> Is it the case that the wchar_t type is defined on this target, it's
> just that libc doesn't have support for wcslen etc?

... it is definitely the case that the target currently defines wchar_t,
and it even offers wchar.h and a lot of (maybe all?) wcs* functions.
This was likely not the case when the patch was first written.

I'll double check whether any of the patch is still needed for current
versions.

I figured it would a waste to just discard Corentin's identification of
testcases that failed when glibc wchar_t support was not enabled.

This also means that the test results I'm going to get are likely to not
reflect the conditions for which these patches were originally written.


FWIW, I like very much the notion of offering a fallback wchar_t
implementation within libstdc++-v3, so that users get the expected C++
functionality even when libc doesn't offer it.  Even a (conditional?)
typedef to introduce wchar_t could be there.

Perhaps the test that sets or clears _GLIBCXX_USE_WCHAR_T should be used
to decide whether or not to offer a wchar.h header in libstdc++, and
then (pipe dream?) all other uses of this macro would be just gone?


> As François said, this could use the new proc. I'd also prefer if it
> was defined as an effective-target keyword so we can use:

> // { dg-require-effective-target wchars }

*nod*


> But we might not even need this new proc if the codecvt tests can be
> made to work using the attached patch.

Thanks,

-- 
Alexandre Oliva, happy hacker  https://FSFLA.org/blogs/lxo/
   Free Software Activist         GNU Toolchain Engineer
        Vim, Vi, Voltei pro Emacs -- GNUlius Caesar