ned14 / outcome

Provides very lightweight outcome<T> and result<T> (non-Boost edition)
https://ned14.github.io/outcome
Other
676 stars 62 forks source link

Outcome failing to compile on gcc10 / c++20 boost 1.73 #225

Closed Samuel-Tyler closed 4 years ago

Samuel-Tyler commented 4 years ago

Tested against boost 1.73. Sorry if this has already been fixed somewhere.

The following is failing to compile with gcc10

#include <filesystem>
#include <optional>
#include <boost/outcome/result.hpp>

std::optional<boost::outcome_v2::std_result<std::filesystem::path>> path;

Error message:

boost/outcome/basic_result.hpp:83:19: error: the value of 'boost::outcome_v2::detail::is_implicitly_constructible<std::filesystem::__cxx11::path, const boost::outcome_v2::basic_result<std::filesystem::__cxx11::path, std::error_code, boost::outcome_v2::policy::error_code_throw_as_system_error<std::filesystem::__cxx11::path, std::error_code, void> >&>' is not usable in a constant expression
   83 |     && ((!detail::is_implicitly_constructible<value_type, T> && detail::is_implicitly_constructible<error_type, T>)  // is unambiguously for error type

note: 'boost::outcome_v2::detail::is_implicitly_constructible<std::filesystem::__cxx11::path, const boost::outcome_v2::basic_result<std::filesystem::__cxx11::path, std::error_code, boost::outcome_v2::policy::error_code_throw_as_system_error<std::filesystem::__cxx11::path, std::error_code, void> >&>' used in its own initializer
  285 |   template <class T, class U> static constexpr bool is_implicitly_constructible = _is_implicitly_constructible<T, U>::value;

This works fine with -std=c++17 but fails with -std=c++20

g++ --version
g++ (GCC) 10.1.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Samuel-Tyler commented 4 years ago

Interestingly, clang10 with -std=c++20 accepts the code.

ned14 commented 4 years ago

It's yet another bug in GCC 10. I have reported it to:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95233

I can give my personal experience with GCC 10.1: We tried compiling our work project with it, and it dies due to multiple causes if C++ 20 is enabled. The same code is fine in MSVC, or clang, in C++ 20. And it is fine in GCC 9.3 in C++ 20.

My advice is wait until GCC 10.2, if you want to use C++ 20. Or use any other compiler.

Thanks for reporting the bug however, it's nice to see others have been having the same problem as I.

Samuel-Tyler commented 4 years ago

Ok, thanks for following up!

jwakely commented 4 years ago

It's yet another bug in GCC 10.

It's actually a bug in the C++20 draft. GCC was implementing exactly what the draft requires.

I can give my personal experience with GCC 10.1: We tried compiling our work project with it, and it dies due to multiple causes if C++ 20 is enabled. The same code is fine in MSVC, or clang, in C++ 20. And it is fine in GCC 9.3 in C++ 20.

MSVC, Clang and GCC 9.3 do not support <concepts> and <ranges> so aren't affected by teething problems in the C++20 spec.

jwakely commented 4 years ago

MSVC, Clang and GCC 9.3 do not support <concepts> and <ranges> so aren't affected by teething problems in the C++20 spec.

They will, however benefit from GCC's implementation experience, and the problems found by people using GCC. If everybody followed your advice and used a different compiler, problems wouldn't be found, and would be rediscovered by other compilers later. Nobody benefits from that.