net: declare io_context in the namespace Asio actually uses

[jcelerier]

backends/net/config.hpp forward-declares boost::asio::io_context so the configuration structs can hold a pointer to it without pulling in io_context.hpp. Since Boost 1.91 that declaration can name a different type than the real one.

The problem

Asio gained an inline version namespace in 1.91. With BOOST_ASIO_ENABLE_VERSION_NAMESPACE, its types live in boost::asio::v<version>_<tags>, tagged with the configuration they were built with, so two differently-configured Asios cannot silently share a mangled name. A declaration in plain boost::asio is then a second, distinct io_context, and every use is ambiguous:

boost/asio/io_context.hpp: error C2872: 'io_context': ambiguous symbol
  libremidi/backends/net/config.hpp(9): could be 'boost::asio::io_context'
  boost/asio/io_context.hpp(193):      or  'boost::asio::v103801_bdemo::io_context'

Every translation unit including this header fails to compile.

The fix

Declare it inside whichever namespace Asio itself would use:

#include <boost/version.hpp>
#if BOOST_VERSION >= 109100
#include <boost/asio/detail/config.hpp>
namespace boost::asio {
BOOST_ASIO_INLINE_NAMESPACE_BEGIN
class io_context;
BOOST_ASIO_INLINE_NAMESPACE_END
}
#else
namespace boost::asio { class io_context; }
#endif

The macros are empty when the feature is off, so this is the same plain declaration as before in that case — it does not impose the version namespace on anyone. They only exist from 1.91 on, hence the version check rather than an unconditional include. boost/version.hpp is cheap, and detail/config.hpp is far cheaper than the io_context.hpp this declaration exists to avoid.

Also declares it as class rather than struct, matching Asio (io_context.hpp:193) — the mismatch is what -Wmismatched-tags warns about.

Why it matters downstream

ossia/libossia#917 needs BOOST_ASIO_ENABLE_VERSION_NAMESPACE on Windows: with Boost 1.91, Boost.Asio's global symbols lose their boost_ prefix and collide with the standalone Asio that score's LSL addon bundles (duplicate symbol: asio_signal_handler). This header was the only thing blocking it.

Verified

Building libossia with MSVC / VS2026 against Boost 1.91, with the version namespace enabled:

• before: libremidi.cpp, observer.cpp, midi_in.cpp, midi_out.cpp all fail with C2872
• after: 593/593 targets, zero errors, and the symbol is emitted as asio_v103801_bdemo_signal_handler rather than the bare asio_signal_handler

🤖 Generated with Claude Code

https://claude.ai/code/session_01XGta2LPAedDP3Txvyq8kTW