sol::property does not support sol::yielding #1487
Comments
|
Following up, I tried the potential change and everything compiled, but it seemed to cause issues with execution. For now I am working around this by using a table with index and new_index set to the functions I had been passing into sol::property. |
|
It seems that meta_functions on usertypes may not respect sol::yielding either. I created a quick test on godbolt showing the behavior. The functions get called, but processing continues in sol rather than yielding at the end of each call. |
|
I have something working for my current uses and wanted to leave some breadcrumbs for anyone needing to do the same thing (assuming yielding support does not get expanded). I ended up creating raw functions to override As for yielding support in sol, I ultimately gave up modifying it because the code path I initially identified only controls part of the behavior and, while the code would compile, during runtime the wrong property function would get called. I expect this is because the pusher path also does not support nested yielding_t. However, I did not look into that aspect of the codebase. For the call path, more than my initial potential change is required. The main issue is that the decision on whether to yield or return directly is made in the top level call function and is currently based solely on whether the function passed in is wrapped with sol::yielding_t. One potential fix that covers namespace detail {
template <typename T, bool is_index, typename = void>
struct is_yielding : meta::is_specialization_of<T, yielding_t> { };
template <typename R, typename W>
struct is_yielding<property_wrapper<R, W>, true> : is_yielding<R, true> { };
template <typename R, typename W>
struct is_yielding<property_wrapper<R, W>, false> : is_yielding<W, true> { };
} // namespace detail
template <typename T, bool is_index>
using is_yielding = detail::is_yielding<std::remove_cv_t<T>, is_index>;
template <typename T, bool is_index>
inline constexpr bool is_yielding_v = is_yielding<std::remove_cv_t<T>, is_index>::value;If that approach doesn't work with some wrapper types, you could instead change the return type of I do not know what to do about the push path, but it may have to do with the |
Lua: 5,4
Sol: trunk
I am trying to implement an interface that requires at least one of the
sol::propertyfunctions to yield. I've run into the issue thatsol::propertydoes not seem to acceptsol::yieldingwrapped functions. I've created the test code below showing essentially what I am trying to do and it fails to compile on either gcc or clang. Based on the errors (reproduced below), I cannot see a specialization forsol::yielding_tin the relevant call path forsol::usertype_proxy<Table, Key>&& sol::usertype_proxy<Table, Key>::operator=when the type is aproperty_wrapper.Is there another way I should be going about this that I am missing? Otherwise, my initial thoughts on a potential fix are below.
TIA.
godbolt
My initial guess is that the specialization of lua_call_wrapper for
property_wrapperneeds to add a check formeta::is_specialization_of<U, yielding_tto theis_specializedbool. It looks like that call path already constructs and utilizes thelua_call_wrapperfor the value, similar to what is done elsewhere to use theyielding_tspecialization oflua_call_wrapper, e.g., in a different specialization below.Error:
The text was updated successfully, but these errors were encountered: