This is the mail archive of the
mailing list for the libstdc++ project.
Re: [PATCH] PR libstdc++/80762 avoid ambiguous __constructible_from<void, void>
On Thu, 13 Dec 2018 at 12:00, Jonathan Wakely <email@example.com> wrote:
> On 13/12/18 08:56 +0100, Christophe Lyon wrote:
> >On Wed, 12 Dec 2018 at 17:13, Jonathan Wakely <firstname.lastname@example.org> 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)
> >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.
Note that only the one in "experimental" failed, the 27_io one did pass.
> 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.