log/example/async_log/main.cpp calls make_attr_ordering incorrectly

[StephanTLavavej]

Microsoft's Visual C++ team regularly builds Boost as part of our "Real World Code" test suite, using the MSVC toolchain that's under development. This allows us to find and fix compiler/Standard Library regressions before they can affect you, and it also allows us to provide advance notice of source breaking changes.

Recently, our test coverage with /std:c++latest has found code in Boost.Log that doesn't compile. This appears to be a Boost source issue. (The Boost build was blocked by a compiler bug that was fixed recently, which probably explains why we're seeing this now and not earlier.)

Here's the error message (our test team prepared a preprocessed file):

cl /TP /std:c++latest /EHsc main.i
main.i
libs\log\example\async_log\main.cpp(89): error C2672: 'boost::log::v2_mt_nt6::make_attr_ordering': no matching overloaded function found
libs\log\example\async_log\main.cpp(89): error C2783: 'boost::log::v2_mt_nt6::attribute_value_ordering<ValueT,FunT> boost::log::v2_mt_nt6::make_attr_ordering(const boost::log::v2_mt_nt6::attribute_name &,const FunT &)': could not deduce template argument for 'ValueT'
.\boost/log/utility/record_ordering.hpp(186): note: see declaration of 'boost::log::v2_mt_nt6::make_attr_ordering'

Here's the call to make_attr_ordering:

log/example/async_log/main.cpp

Lines 86 to 89 in a7b4a14

	shared_ptr< sink_t > sink(new sink_t(
	boost::make_shared< backend_t >(),
	// We'll apply record ordering to ensure that records from different threads go sequentially in the file
	keywords::order = logging::make_attr_ordering("RecordID", std::less< unsigned int >())));

Note that there are no explicit template arguments. Then, here's the declaration:

log/include/boost/log/utility/record_ordering.hpp

Lines 185 to 186 in a7b4a14

	template< typename ValueT, typename FunT >
	inline attribute_value_ordering< ValueT, FunT > make_attr_ordering(attribute_name const& name, FunT const& fun)

Here, ValueT is the first template parameter, but it doesn't appear in the function arguments, so it must be explicitly provided. The compiler is correctly complaining that ValueT hasn't been explicitly provided, and cannot be deduced.

If I'm missing something and this is actually a compiler/Standard Library issue, please let me know so we can fix MSVC. Thanks!

[Lastique]

There's another overload that doesn't require the explicit ValueT template parameter here:

log/include/boost/log/utility/record_ordering.hpp

Lines 214 to 215 in a7b4a14

	template< typename FunT >
	inline typename aux::make_attr_ordering_type< FunT >::type make_attr_ordering(attribute_name const& name, FunT const& fun)

That overload can be disabled by SFINAE, but in this case it should be enabled. I suspect, something in MSVC (either the compiler, or std::less) might be causing SFINAE failure and subsequent compilation error. Since this is your internal MSVC build, I cannot investigate.

For the record, gcc 9 and clang 9 on Linux are able to compile this example.

[StephanTLavavej]

Aha, thanks! It appears to be looking for first_argument_type etc. which explains what happened - we implemented C++20’s removal of the deprecated adaptor typedefs (with an escape hatch).

This unblocks our testing; I’ll tell our test team to activate the escape hatch to restore the typedefs. For the long-term, I recommend refactoring Boost.Log to remove its dependency on the deprecated/removed typedefs.

[Lastique]

The other overload is for the case when deducing the function object argument type is not possible. Without the typedefs users will have to explicitly specify ValueT.

[Lastique]

BTW, it might be helpful if the compiler also listed discarded overloads, with reasons why they were discarded, like gcc does in cases like these. This is very helpful in debugging SFINAE-related issues.