Can we please add something like <asan>on (similar to <valgrind>on) which informs AddressSanitizer of the stack changes? It is described here:
google/sanitizers#189 (comment)
https://github.com/llvm-mirror/compiler-rt/blob/master/include/sanitizer/common_interface_defs.h#L166

In http://www.boost.org/doc/libs/1_62_0/libs/coroutine/doc/html/coroutine/overview.html the link to Boost.Coroutine2 is incorrect: http://www.boost.org/doc/libs/1_62_0/libs/coroutine2/index.htmlBoo.Coroutine2

The documentation alludes to a bjam property <valgrind>on to enable BOOST_USE_VALGRIND. However, I have searched through tools/build and libs/coroutine and I cannot find any jam code or other code that implements this property. Is this a supported feature? If so, where is the code to support this feature? If not, could we perhaps update the documentation?

Complete list of warnings when Boost 1.72 is built with GCC 7.5 with -Wsuggest-override added to cxxflags:

libs/coroutine/src/exceptions.cpp:15:25: warning: ‘virtual const char* boost::coroutines::coroutine_error_category::name() const’ can be marked override [-Wsuggest-override]
libs/coroutine/src/exceptions.cpp:18:25: warning: ‘virtual std::__cxx11::string boost::coroutines::coroutine_error_category::message(int) const’ can be marked override [-Wsuggest-override]

BOOST_OVERRIDE was introduced in boostorg/config@ffe4e0f.

Can we please add something like <asan>on (similar to <valgrind>on) which informs AddressSanitizer of the stack changes? It is described here:
google/sanitizers#189 (comment)
https://github.com/llvm-mirror/compiler-rt/blob/master/include/sanitizer/common_interface_defs.h#L166

From the test matrix:
http://www.boost.org/development/tests/develop/output/teeks99-09-n-win2012R2-64on64-beast-msvc-14-1-warnings.html#accept

We are in the process of making B2 build changes to all of the B2 build files
to support "modular" consumption of the Boost Libraries by users. See this list
post for some details: https://lists.boost.org/Archives/boost/2024/01/255704.php

The process requires making a variety of changes to make each Boost library
independent of the super-project structure. But the changes do not remove the
super-project structure or the comprehensive Boost release. The changes make
solely make it possible, optionally, for users, like package manages, to easily
consume libraries individually.

Generally the changes include:

• Adding a libroot/build.jam.
• Porting any functionality from libroot/jamfile to libroot/build.jam.
• Moving boost-install declaration from libroot/build/jamfile is applicable.
• Adjusting other B2 build files in the library, like test/jamfile, as needed.
• Possible changes to C++ source files to remove includes relative to the
  super-project boostroot location.

Some examples of such changes:

• boostorg/interval#38
• boostorg/ublas#189
• boostorg/local_function#10
• boostorg/preprocessor#57
• boostorg/callable_traits#194
• boostorg/compatibility#4
• boostorg/hof#228
• boostorg/preprocessor#56

We are asking how you would like us to handle the changes. We would prefer if
you allow the owners of the Boost.org GitHub project to make changes to B2
build files, as needed, to accomplish the changes. But understand
that you may want to manage the proposed changes yourself.

We previously sent emails to all known maintainers to fill out a form with their
preference. We are contacting you in this issue as we have not gotten a response
to that email. You can see the ongoing responses for that form and the responses
to these issues here https://github.com/users/grafikrobot/projects/1/views/6

We are now asking if you can reply directly to this issue to indicate your
preference of handling the changes. Please supply a response to this question
and close the issue (so that we can verify you are a maintainer).

How would you like the build changes to be processed?

1. Pull request, reviewed and merged by a BOOSTORG OWNER.
2. Pull request, reviewed and merged by YOU.
3. Other. (please specify details in the reply)

Also please indicate any special instructions you want us to consider. Or other
information you want us to be aware of.

Thanks you, René

tl;dr: Would it make sense to make a PR with all 0 < ptr occurrences replaces by 0 != ptr?

I use gcc and boost for some little project, and want to use -Wextra for my code in order to prevent mistakes on my side.

I see the following warning within the boost headers:

$(BOOST_ROOT)/coroutine/asymmetric_coroutine.hpp:1812:23: \
warning: ordered comparison of pointer with integer zero [-Wextra]
     BOOST_ASSERT( 0 < sp);
                       ^

It seems that the whole of Boost.Coroutine is written in this style, so I guess there is some benefit to it. However, since pointers shouldn't be negative (but that's just my naive intuition speaking), the only violation would be 0 == sp.

If my assumptions is correct, then the proposed 0 != sp would have these advantages:

• same semantics
• more expressiveness (should probably compare against NULL or nullptr instead of using literal zero, but that's not so important)
• no/less warnings in gcc

... and no disadvantages.
So, what do you think?

On macOS:

In file included from /Users/howardhinnant/Development/boost_1_72_0/boost/coroutine/coroutine.hpp:10:
/Users/howardhinnant/Development/boost_1_72_0/boost/coroutine/asymmetric_coroutine.hpp:2364:10: error: no member named 'begin' in namespace
      'boost'; did you mean simply 'begin'?
{ return boost::begin( c); }
         ^~~~~~~

Ditto for end.

Iterators of pull coroutines don't work in the way iterators are expected to work. This test works for vector, and fails for the coroutine (check *it1 == *it2 failed [2 != 3]).

void test_pull_coroutine_iterator_copy()
{
    {
        auto range = std::vector<int>{1, 2, 3};

        auto it1 = std::begin(range);
        auto it2 = it1;
        ++it1;
        ++it2;
        BOOST_CHECK_EQUAL( *it1, *it2 );
    }

    {
        auto range = coro::coroutine<int>::pull_type
        {[](coro::coroutine<int>::push_type& yield){
            yield(1); yield(2); yield(3);
        }};

        auto it1 = std::begin(range);
        auto it2 = it1;
        ++it1;
        ++it2;
        BOOST_CHECK_EQUAL( *it1, *it2 );
    }
}

I think that the correct way to fix it would be to make iterators move-only - as it's impossible to correctly support copying iterators because the coroutine is not copyable.

But there is one problem - BOOST_FOREACH currently requires copyable iterators. Which I fixed - boostorg/foreach#1

Any ideas on this error?

../boost/coroutine/detail/push_coroutine_object.hpp:247:9: warning: destructor called on
non-final 'boost::coroutines::detail::push_coroutine_object<boost::coroutines::pull_coroutine<void>,
void, boost::asio::detail::coro_entry_point<boost::asio::detail::wrapped_handler<
boost::asio::io_service::strand, void (*)(), boost::asio::detail::is_continuation_if_running>,(lambda
at ../libs/beast/test/extras/include/boost/beast/test/yield_to.hpp:123:9)> &,
boost::coroutines::basic_standard_stack_allocator<boost::coroutines::stack_traits> >' that
has virtual functions but non-virtual destructor [-Wdelete-non-virtual-dtor]

Coming from:
http://www.boost.org/development/tests/develop/output/teeks99-02-dc3-9-14-Docker-64on64-beast-clang-linux-3-9~c++14-warnings.html#buffered_read_stream

Thanks

Can we please add something like <asan>on (similar to <valgrind>on) which informs AddressSanitizer of the stack changes? It is described here:
google/sanitizers#189 (comment)
https://github.com/llvm-mirror/compiler-rt/blob/master/include/sanitizer/common_interface_defs.h#L166

The file <boost/detail/scoped_enum_emulation.hpp> is being included here:

The problem is that this file is deprecated and causes warnings for any Beast or Asio users who use Asio's coroutines. Could we perhaps fix this for the release?

Still getting these:

C:\projects\boost-root\boost/coroutine/detail/coroutine_context.hpp(43): warning C4251: 'boost::coroutines::detail::coroutine_context::palloc_': struct 'boost::coroutines::detail::preallocated' needs to have dll-interface to be used by clients of class 'boost::coroutines::detail::coroutine_context'
C:\projects\boost-root\boost/coroutine/detail/preallocated.hpp(25): note: see declaration of 'boost::coroutines::detail::preallocated'

Dale Schumacher in "Same Fringe" Revisited says that the fringe of a tree "... is simply the sequence of leaves reading from left to right."

The coroutine example, same_fringe.cpp, includes non-leaf values amongst its comparisons. Perhaps the example could be renamed, or reworked to behave as expected.

There are fixes in develop which never made it into master.

/usr/local/include/boost/coroutine/detail/push_coroutine_impl.hpp:249: undefined reference to `boost::coroutines::detail::coroutine_context::jump(boost::coroutines::detail::coroutine_context&, void*)'

1. boost version 1.72
2. Linux ubuntu 4.15.0-91-generic #92~16.04.1-Ubuntu SMP Fri Feb 28 14:57:22 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
3. gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.12)
   -lpthread -lboost_system -lboost_filesystem -lboost_program_options -lboost_coroutine -lboost_thread -lboost_context

I keep getting undefined refence errors from the linker while the symbols do exist in .asm files.
For example _make_fcontext is defined in libs/context/src/asm/make_i386_ms_pe_gas.asm and libs/context/src/asm/make_x86_64_ms_pe_gas.asm.
However I have a suspicion the linker is looking for make_fcontext (without leading underscore).

Boost version: 1.73.0, but also have this problem with older versions
OS: Windows 10
Shell: MSYS2
Compiler toolset: MinGW-w64 GCC for Windows from http://winlibs.com/ (different versions, e.g. GCC 9.3.0)
Build command (+ the same with address-model=32):

BOOST_ROOT=$(pwd) MINGW=/ tools/build/src/engine/bjam.exe -q --prefix=/usr/local --build-dir=build_win --build-type=complete --layout=tagged --enable-icu --disable-filesystem2 toolset=gcc target-os=windows abi=ms link=static,shared runtime-link=static,shared variant=release threading=single,multi threadapi=win32 context-impl=winfib address-model=64 --without-python --without-mpi release stage cxxflags="-fpermissive -DBOOST_LOG_WITHOUT_SYSLOG"

gcc.link.dll build_win\boost\bin.v2\libs\coroutine\build\gcc-10.1.0\release\context-impl-winfib\threadapi-win32\visibility-hidden\libboost_coroutine-x64.dll.a
d:/prog/winlibs64-10.1.0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: build_win\boost\bin.v2\libs\coroutine\build\gcc-10.1.0\release\context-impl-winfib\threadapi-win32\visibility-hidden\detail\coroutine_context.o:coroutine_context.cpp:(.text+0x4f): undefined reference to
`__imp_make_fcontext'
d:/prog/winlibs64-10.1.0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: build_win\boost\bin.v2\libs\coroutine\build\gcc-10.1.0\release\context-impl-winfib\threadapi-win32\visibility-hidden\detail\coroutine_context.o:coroutine_context.cpp:(.text+0xd7): undefined reference to
`__imp_jump_fcontext'

include\boost\coroutine\asymmetric_coroutine.hpp(2364): error C2039: 'begin': is not a member of 'boost'

with MSVC 19.25.28610.4 enabling /permissive-
When turning off /permissive-, there will be no more error.

Hi,
I am trying to port Boost on AIX.

OS: AIX 7.1
Compiler: GCC 8.4

I have reported an issue about -fsplit-stack on context library. Fiber library is also concerned. I create this issue to inform you, but it will be easier if the discussion will be centralized at boostorg/context#143.

TL;DR: the -fsplit-stack flag seems to be available only on Linux, and it is used for all OS by Boost.

Environment:
VS 2019 + Windows Server 2016 + MongoDB master branch latest revision

MongoDB failed to run buildscripts/scons.py all -j4 with MSVC on windows . It can be first reproduced on master revision 46af3f0. Could you help have a look about this issue? Thanks in advance!

Steps to reproduce the behavior:

1. git clone -c core.autocrlf=true https://github.com/mongodb/mongo D:\MongoDB\src
2. Open a VS 2019 x64 command prompt and browse to D:\MongoDB\src
   3.Apply the three patches in the attachment in order： mongodb_addoption_bug943976.patch mongodb_bug668740.patch mongodb_c2039,c3646.patch
3. set VSCMD_SKIP_SENDTELEMETRY=1 & "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\Tools\VsDevCmd.bat" -host_arch=amd64 -arch=amd64
4. pip3 install -r etc/pip/compile-requirements.txt
5. set VSCMD_SKIP_SENDTELEMETRY=1 & "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\Tools\VsDevCmd.bat" -host_arch=amd64 -arch=amd64
6. python buildscripts/scons.py all -j4

build.log
patch.zip

Actual result:
scons: Building targets ...
scons: *** Do not know how to make File target all' (F:\gitP\mongodb\mongo\all). Stop. scons: building terminated because of errors. all failed: Do not know how to make File target all' (F:\gitP\mongodb\mongo\all)

Environment:
VS 2017 + Windows Server 2016

Issue description:
One test fails to compile after boostorg/coroutine submodule updated from d698d1 to d5e610 boost/coroutine@49c1730. Could you please take a look?

log_x64_test_124.log

Reproduce steps:

1. git clone -c core.autocrlf=true --recursive ​https://github.com/boostorg/boost.git D:\Boost\src
2. open a VS 2017 x64 command prompt and browse to D:\Boost\src
3. .\bootstrap
4. .\b2 headers variant=release --build-dir=..\out\x64rel address-model=64
5. .\b2 variant=release --build-dir=..\out\x64rel address-model=64
6. .\b2 -j4 variant=release --build-dir=..\out\x64rel libs\beast\test

ErrorMessage:
compile-c-c++ ..\out\x64rel\boost\bin.v2\libs\beast\test\beast\core\basic_stream.test\msvc-14.1\release\threadapi-win32\threading-multi\basic_stream.obj
basic_stream.cpp
.\boost/coroutine/asymmetric_coroutine.hpp(2364): error C2039: 'begin': is not a member of 'boost'
.\boost/coroutine/asymmetric_coroutine.hpp(38): note: see declaration of 'boost'
.\boost/coroutine/asymmetric_coroutine.hpp(2369): error C2039: 'begin': is not a member of 'boost'
.\boost/coroutine/asymmetric_coroutine.hpp(38): note: see declaration of 'boost'
.\boost/coroutine/asymmetric_coroutine.hpp(2374): error C2039: 'end': is not a member of 'boost'
.\boost/coroutine/asymmetric_coroutine.hpp(38): note: see declaration of 'boost'
.\boost/coroutine/asymmetric_coroutine.hpp(2379): error C2039: 'end': is not a member of 'boost'
.\boost/coroutine/asymmetric_coroutine.hpp(38): note: see declaration of 'boost'
.\boost/coroutine/asymmetric_coroutine.hpp(2384): error C2039: 'begin': is not a member of 'boost'
.\boost/coroutine/asymmetric_coroutine.hpp(38): note: see declaration of 'boost'
.\boost/coroutine/asymmetric_coroutine.hpp(2389): error C2039: 'end': is not a member of 'boost'
.\boost/coroutine/asymmetric_coroutine.hpp(38): note: see declaration of 'boost'

call "..\out\x64rel\boost\bin.v2\standalone\msvc\msvc-14.1\msvc-setup.bat"  >nul

cl /Zm800 -nologo @"..\out\x64rel\boost\bin.v2\libs\beast\test\beast\core\basic_stream.test\msvc-14.1\release\threadapi-win32\threading-multi\basic_stream.obj.rsp"

I checked out the 1.80 release branch of boost and ran the following commands:
./bootstrap.sh
./b2 architecture="arm+x86" cxxflags="-arch x86_64 -arch arm64"

everything seems to have compiled correctly apart from an error at the end:
...updating 4 targets...
clang-darwin.link.dll bin.v2/libs/coroutine/build/clang-darwin-13/release/architecture-arm+x86/threading-multi/visibility-hidden/libboost_coroutine.dylib
Undefined symbols for architecture arm64:
"_jump_fcontext", referenced from:
boost::coroutines::detail::coroutine_context::jump(boost::coroutines::detail::coroutine_context&, void*) in coroutine_context.o
"_make_fcontext", referenced from:
boost::coroutines::detail::coroutine_context::coroutine_context(void ()(boost::context::detail::transfer_t), boost::coroutines::detail::preallocated const&) in coroutine_context.o
boost::coroutines::detail::coroutine_context::coroutine_context(void ()(boost::context::detail::transfer_t), boost::coroutines::detail::preallocated const&) in coroutine_context.o
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

"clang++"   -o "bin.v2/libs/coroutine/build/clang-darwin-13/release/architecture-arm+x86/threading-multi/visibility-hidden/libboost_coroutine.dylib" -single_module -dynamiclib -install_name "@rpath/libboost_coroutine.dylib" "bin.v2/libs/coroutine/build/clang-darwin-13/release/architecture-arm+x86/threading-multi/visibility-hidden/detail/coroutine_context.o" "bin.v2/libs/coroutine/build/clang-darwin-13/release/architecture-arm+x86/threading-multi/visibility-hidden/exceptions.o" "bin.v2/libs/coroutine/build/clang-darwin-13/release/architecture-arm+x86/threading-multi/visibility-hidden/posix/stack_traits.o" "bin.v2/libs/context/build/clang-darwin-13/release/architecture-arm+x86/threading-multi/visibility-hidden/libboost_context.dylib"         -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -arch arm64 -arch x86_64

...failed clang-darwin.link.dll bin.v2/libs/coroutine/build/clang-darwin-13/release/architecture-arm+x86/threading-multi/visibility-hidden/libboost_coroutine.dylib...
...skipped <p/opt/UnitySrc/git/com.unity.recorder/Native/External/boost/stage/lib>libboost_coroutine.dylib for lack of <pbin.v2/libs/coroutine/build/clang-darwin-13/release/architecture-arm+x86/threading-multi/visibility-hidden>libboost_coroutine.dylib...
...skipped <pbin.v2/libs/coroutine/build/clang-darwin-13/release/architecture-arm+x86/threading-multi/visibility-hidden>libboost_coroutine-variant-shared.cmake for lack of <pbin.v2/libs/coroutine/build/clang-darwin-13/release/architecture-arm+x86/threading-multi/visibility-hidden>libboost_coroutine.dylib...
...skipped <p/opt/UnitySrc/git/com.unity.recorder/Native/External/boost/stage/lib/cmake/boost_coroutine-1.80.0>libboost_coroutine-variant-shared.cmake for lack of <pbin.v2/libs/coroutine/build/clang-darwin-13/release/architecture-arm+x86/threading-multi/visibility-hidden>libboost_coroutine-variant-shared.cmake...
...failed updating 1 target...
...skipped 3 targets...

Hi, could we fallback to std::call_once1 in case it exists? That would eliminate the boost_thread requirement when compiling with C++11 (or above) and reduce complexity.

Hello,

I am not sure whether this is a boost::asio or boost::coroutine bug but I thought I'd start here as it doesn't really seem related to any asio code. Happy to report it to boost::asio though!

the following code:

#include <iostream>
#include <chrono>

#include <boost/asio/io_context.hpp>
#include <boost/asio/spawn.hpp>
#include <boost/asio/steady_timer.hpp>

int main(int argc, char* argv[]) {
    boost::asio::io_context io_context;

    boost::asio::spawn(io_context, [&] (boost::asio::yield_context yield) {
        boost::asio::steady_timer timer(io_context);
        
        while (true) {
            try {
                std::cout << "before" << std::endl;
                timer.expires_after(std::chrono::seconds(1));
                timer.async_wait(yield);
                std::cout << "after" << std::endl;
            }
            catch (...) {
                std::cout << "excep handler" << std::endl;
            }
        }
    });

    for (int i = 0; i < 1; ++i) {
        io_context.run_one();
    }

    std::cout << "done" << std::endl;

    return 0;
}

gives the following output:

before
done
excep handler
before
bastelbox: /usr/include/boost/coroutine/detail/push_coroutine_impl.hpp:252: void boost::coroutines::detail::push_coroutine_impl::unwind_stack(): Assertion `is_complete()' failed.
Aborted (core dumped)

It seems like when the coroutine handler gets destroyed (once the io_context gets destroyed) execution is resumed in the catch all exception handler. Using a non-catch all handler like only catching std::exception results in normal behaviour (only before and done is printed).

I am testing this with g++ 8 and boost 1.69. I can reproduce it in both -O0 and -O2. Enabling ASAN also results in a stack-buffer-underflow warning: https://gist.github.com/StephanDollberg/a1ab914d806d3aa4406c5cf840dd2e00

Thanks,
Stephan