Open slymz opened 2 years ago
I've seen this in the work code base as well, and I too would like it to go away. I'll hopefully create some time to do it soon. Thanks for the report.
Possibly related, I've started to observe clang-analyzer-core.uninitialized.Assign
diagnostics being triggered by OUTCOME_TRY
:
D:\devel\source\deeplex\deeplog\build\x64-windows-clang\vcpkg_installed\x64-windows-static\include\status-code/status_code.hpp:378:18: warning: Assigned value is garbage or undefined [clang-analyzer-core.uninitialized.Assign]
, _value(static_cast<status_code_storage &&>(o)._value)
[...]
D:\devel\source\deeplex\deeplog\build\x64-windows-clang\vcpkg_installed\x64-windows-static\include\outcome/try.hpp:197:21: note: expanded from macro 'OUTCOME_TRYV2_SUCCESS_LIKELY'
auto unique##_f(::OUTCOME_V2_NAMESPACE::try_operation_return_as(static_cast<decltype(unique) &&>(unique))); \
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
D:\devel\source\deeplex\deeplog\build\x64-windows-clang\vcpkg_installed\x64-windows-static\include\outcome/try.hpp:95:10: note: Calling 'basic_result::as_failure'
return static_cast<T &&>(v).as_failure();
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
D:\devel\source\deeplex\deeplog\build\x64-windows-clang\vcpkg_installed\x64-windows-static\include\outcome/experimental/../basic_result.hpp:707:12: note: Calling 'failure<system_error2::errored_status_code<system_error2::erased<long long>>>'
return failure(static_cast<basic_result &&>(*this).assume_error(), hooks::spare_storage(this));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
D:\devel\source\deeplex\deeplog\build\x64-windows-clang\vcpkg_installed\x64-windows-static\include\outcome/experimental/../success_failure.hpp:245:10: note: Calling constructor for 'failure_type<system_error2::errored_status_code<system_error2::erased<long long>>, void>'
return failure_type<std::decay_t<EC>>{static_cast<EC &&>(v), spare_storage};
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It looks like clang-tidy cannot deduce that .has_failure()
⊢ assume_error() is initialized
holds.
Repro and detailed description here:
https://godbolt.org/z/YG6e8q3Y5
Excerpt:
Very likely that this is a GCC issue (in fact, can't be reproduced in trunk). Yet, it is a curious phenomenon and causing production hassle with our boost upgrade. I am wondering if this is an expected change with later Outcome versions, or worse and crucially if the usage in the reproduction code is somewhat making incorrect assumptions.
Or, if there is confirmation this is just a silly GCC bug, it'd be a good enough resolution.
thanks