[PATCH] PR libstdc++/80762 avoid ambiguous __constructible_from<void, void>

[Christophe Lyon]

On Thu, 13 Dec 2018 at 12:00, Jonathan Wakely <jwakely@redhat.com> wrote:
>
> On 13/12/18 08:56 +0100, Christophe Lyon wrote:
> >On Wed, 12 Dec 2018 at 17:13, Jonathan Wakely <jwakely@redhat.com> wrote:
> >>
> >> Ensure we don't try to instantiate __is_constructible_from<void, void>,
> >> because there are two partial specializations that are equally good
> >> matches.
> >>
> >>         PR libstdc++/80762
> >>         * include/bits/fs_path.h (path::_Path): Use remove_cv_t and is_void.
> >>         * include/experimental/bits/fs_path.h (path::_Path): Likewise.
> >>         * testsuite/27_io/filesystem/path/construct/80762.cc: New test.
> >>         * testsuite/experimental/filesystem/path/construct/80762.cc: New test.
> >>
> >
> >Hi Jonathan,
> >
> >One of the new tests fails on bare-metal/newlib targets (aarch64-elf/arm-eabi):
> >FAIL: experimental/filesystem/path/construct/80762.cc (test for excess errors)
> >/libstdc++-v3/testsuite/experimental/filesystem/path/construct/80762.cc:20:
> >fatal error: experimental/filesystem: No such file or directory
> >
> >I think there was a similar issue recently, but I don't remember how
> >you fixed it?
>
> Like this. Sorry for forgetting it. Committed to trunk.
OK thanks.
Note that only the one in "experimental" failed, the 27_io one did pass.

>
> Aside:
> There's actually no reason the filesystem::path type can't be enabled
> unconditionally for all targets, as it only relies on portable
> features like std::string, but currently the definitions of its member
> functions are in the libstdc++fs.a library which is only enabled
> conditionally. Later today I plan to move the std::filesystem::path
> type into the main libstdc++.so library, so only the tests for
> std::experimental::filesystem::path will depend on libstdc++fs.a being
> available. Until then, this patch is needed.
>
Great!