Apple Clang 14.0.0 (current latest) does not support std::make_unique_for_overwrite

[emmenlau]

I have a problem building current latest ITK on MacOS with current latest XCode with C++20. The error I get is:

FAILED: Modules/Core/Common/src/CMakeFiles/ITKCommon.dir/itkNumericTraitsTensorPixel.cxx.o 
/System/Volumes/Data/data/user/Tools/lib/ccache/c++ -DTBB_DEPRECATED=0 -DTBB_USE_CAPTURED_EXCEPTION=0 -DTBB_USE_DEBUG -I/System/Volumes/Data/data/user/ci-dst-m1015Iv64c1400/Extras/oneapi/mkl/2022.0.0/include/fftw -I/System/Volumes/Data/data/user/ci-tmp-m1015Iv64c1400/Debug/ITK/Modules/ThirdParty/Eigen3/src -I/System/Volumes/Data/data/user/ci-tmp-m1015Iv64c1400/Debug/ITK/Modules/ThirdParty/KWSys/src -I/Users/user/builds/nK4EB_yB/0/ITK/Modules/ThirdParty/VNL/src/vxl/v3p/netlib -I/Users/user/builds/nK4EB_yB/0/ITK/Modules/ThirdParty/VNL/src/vxl/vcl -I/Users/user/builds/nK4EB_yB/0/ITK/Modules/ThirdParty/VNL/src/vxl/core -I/System/Volumes/Data/data/user/ci-tmp-m1015Iv64c1400/Debug/ITK/Modules/ThirdParty/VNL/src/vxl/v3p/netlib -I/System/Volumes/Data/data/user/ci-tmp-m1015Iv64c1400/Debug/ITK/Modules/ThirdParty/VNL/src/vxl/vcl -I/System/Volumes/Data/data/user/ci-tmp-m1015Iv64c1400/Debug/ITK/Modules/ThirdParty/VNL/src/vxl/core -I/System/Volumes/Data/data/user/ci-tmp-m1015Iv64c1400/Debug/ITK/Modules/Core/Common -I/Users/user/builds/nK4EB_yB/0/ITK/Modules/Core/Common/include -I/Users/user/builds/nK4EB_yB/0/ITK/Modules/ThirdParty/VNL/src/vxl/core/vnl/algo -I/Users/user/builds/nK4EB_yB/0/ITK/Modules/ThirdParty/VNL/src/vxl/core/vnl -I/System/Volumes/Data/data/user/ci-tmp-m1015Iv64c1400/Debug/ITK/Modules/ThirdParty/VNL/src/vxl/core/vnl -isystem /System/Volumes/Data/data/user/ci-dst-m1015Iv64c1400/Debug/include -isystem /System/Volumes/Data/data/user/ci-dst-m1015Iv64c1400/Debug/include/eigen3 -DQT_DISABLE_DEPRECATED_BEFORE=0x050F00 -Wall -pedantic -Wextra -Werror=return-type -Werror=uninitialized -Werror=unknown-pragmas -Werror=shadow -Werror=undef -Werror=pointer-arith -Werror=shift-count-overflow -Werror=string-plus-int -Werror=nonportable-include-path -Werror=inconsistent-missing-override -Werror=self-assign -Werror=self-assign-field -Werror=self-move -Werror=braced-scalar-init -Werror=many-braces-around-scalar-init -Werror=deprecated-enum-enum-conversion -Werror=infinite-recursion -Werror=exceptions -Werror=excess-initializers -Werror=return-stack-address -Werror=delete-non-abstract-non-virtual-dtor  -Werror=unguarded-availability -Wno-error=undef -Wno-undef -Wno-error=shadow -Wno-shadow -Wno-extra-semi -march=sandybridge -mtune=skylake -mmacosx-version-min=10.15 -std=c++20 -glldb -fno-omit-frame-pointer -O0 -Werror=pessimizing-move -Werror=redundant-move -Werror=range-loop-construct -mtune=generic -march=corei7 -Wcast-align -Wdisabled-optimization -Wformat=2 -Winvalid-pch -Wno-format-nonliteral -Wpointer-arith -Wshadow -Wunused -Wwrite-strings -funit-at-a-time -Wno-strict-overflow -Wno-deprecated -Wno-invalid-offsetof -Wno-undefined-var-template -Woverloaded-virtual  -g -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.1.sdk -mmacosx-version-min=12.6 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -std=c++20 -MD -MT Modules/Core/Common/src/CMakeFiles/ITKCommon.dir/itkNumericTraitsTensorPixel.cxx.o -MF Modules/Core/Common/src/CMakeFiles/ITKCommon.dir/itkNumericTraitsTensorPixel.cxx.o.d -o Modules/Core/Common/src/CMakeFiles/ITKCommon.dir/itkNumericTraitsTensorPixel.cxx.o -c /Users/user/builds/nK4EB_yB/0/ITK/Modules/Core/Common/src/itkNumericTraitsTensorPixel.cxx
In file included from /Users/user/builds/nK4EB_yB/0/ITK/Modules/Core/Common/src/itkNumericTraitsTensorPixel.cxx:18:
In file included from /Users/user/builds/nK4EB_yB/0/ITK/Modules/Core/Common/include/itkNumericTraitsTensorPixel.h:22:
In file included from /Users/user/builds/nK4EB_yB/0/ITK/Modules/Core/Common/include/itkSymmetricSecondRankTensor.h:29:
In file included from /Users/user/builds/nK4EB_yB/0/ITK/Modules/Core/Common/include/itkSymmetricEigenAnalysis.h:1104:
In file included from /Users/user/builds/nK4EB_yB/0/ITK/Modules/Core/Common/include/itkSymmetricEigenAnalysis.hxx:22:
/Users/user/builds/nK4EB_yB/0/ITK/Modules/Core/Common/include/itkMakeUniqueForOverwrite.h:76:14: error: no member named 'make_unique_for_overwrite' in namespace 'std'
using ::std::make_unique_for_overwrite;
      ~~~~~~~^

I think this is due to the following check being too liberal: https://github.com/InsightSoftwareConsortium/ITK/blob/15d09d6c756b46b4d1c296d8bb13b85f82654ef9/Modules/Core/Common/include/itkMakeUniqueForOverwrite.h#L24

As far as I can see, not many compilers currently support std::make_unique_for_overwrite: https://en.cppreference.com/w/cpp/compiler_support

[thewtex]

CC @N-Dekker

[N-Dekker]

@emmenlau Thanks Mario, I did not know about this issue.

Apparently we should add a feature test on __cpp_lib_smart_ptr_for_overwrite. Right?

https://en.cppreference.com/w/cpp/feature_test#Library_features

[emmenlau]

Hey @N-Dekker no worries I could hack my way around it on Apple. But yes, the feature test seems the correct thing, and maybe with the feature check, there may not even be a need for the C++20 check anymore...

[N-Dekker]

Thanks. I thought about it again, maybe it's better to just remove the #if entirely, and use the ITK implementation unconditionally. Because otherwise I'm afraid there is a risk of violating the C++ One Definition Rule (ODR), when ITK library and the user code do not have exactly the same compiler settings. Specifically, the ITK library could be compiled in C++14 mode, while the user code could use C++20. Things may then become dodgy when ITK library functions that are defined in "itk.hxx" or "itk.h" files call make_unique_for_overwrite.

[thewtex]

Because otherwise I'm afraid there is a risk of violating the C++ One Definition Rule (ODR), when ITK library and the user code do not have exactly the same compiler settings. Specifically, the ITK library could be compiled in C++14 mode, while the user code could use C++20.

@N-Dekker good idea :-). I ran into this issue myself recently in itk-wasm.

[thewtex]

Closed via #3856 , thanks @N-Dekker