Closed yurivict closed 11 months ago
Was this not fixed by https://github.com/ned14/outcome/commit/0bedf671c04467d66219454bd9a61d0bfbb99242?
/…/outcome/policy/../detail/value_storage.hpp:1385:31: error: cannot initialize a member subobject of type 'outcome_v2::detail::value_storage_nontrivial<udt5, std::error_code>::_value_type_ *' (aka 'udt5 *') with an rvalue of type 'void'
} _{_status, o._status, OUTCOME_ADDRESS_OF(_value), OUTCOME_ADDRESS_OF(o._value), OUTCOME_ADDRESS_OF(_error), OUTCOME_ADDRESS_OF(o._error)};
^~~~~~~~~~~~~~~~~~~~~~~~~~
/…/outcome/detail/../config.hpp:178:33: note: expanded from macro 'OUTCOME_ADDRESS_OF'
#define OUTCOME_ADDRESS_OF(...) (&__VA_ARGS__)
^~~~~~~~~~~~~~
smells like some weird preprocessor interaction/bug in clang. Maybe this can be fixed by adding an additional pair of parentheses
#define OUTCOME_ADDRESS_OF(...) (&(__VA_ARGS__))
It compiles fine on clang both here locally and on all the clangs Boost.Outcome is CIed upon.
Could be the FreeBSD clang is weird of course.
Why is there no --std=C++xx
argument? Compilers might be using different C++ standards.
We tell cmake the targets are C++ 14 or later. Up to cmake what it does with that.
I confirm that Outcome develop branch is compiling just fine on FreeBSD 13, so I'm going to close this. Feel free to reopen if it is untrue.
rev. 0bedf67 clang-15 FreeBSD 13.2