Sol2: Container detection assumptions

[karenzshea]

Hi!

I've written a small example to show I'm trying to implement, https://github.com/karenzshea/sunless. I'm using sol to run lua functions on object types defined by libosmium. In the main.cc you can see I've written a handler that calls a registered lua function, passing it an osmium::Node object that has been registered as a lua usertype.

Building this results in an error

In file included from main.cc:3:0:
third_party/sol/sol.hpp: In instantiation of ‘struct sol::container_usertype_metatable<osmium::Node, void>’:
third_party/sol/sol.hpp:11376:19:   required from ‘auto sol::stack::stack_detail::container_metatable() [with T = osmium::Node*]’
third_party/sol/sol.hpp:11408:52:   required from ‘void sol::stack::stack_detail::metatable_setup<T>::operator()() [with T = osmium::Node*]’
third_party/sol/sol.hpp:5902:6:   required from ‘static int sol::stack::pusher<sol::detail::as_pointer_tag<T> >::push_fx(lua_State*, F&&, T*) [with F = sol::stack::stack_detail::metatable_setup<osmium::Node*>&; T = const osmium::Node; lua_State = lua_State]’
third_party/sol/sol.hpp:11445:67:   required from ‘static int sol::stack::pusher<T*, typename std::enable_if<sol::meta::all<sol::is_container<T>, std::integral_constant<bool, (! sol::meta::any<std::is_base_of<sol::reference, typename std::remove_cv<typename std::remove_reference<_From>::type>::type>, std::is_base_of<sol::stack_reference, typename std::remove_cv<typename std::remove_reference<_From>::type>::type> >::value)> >::value, void>::type>::push(lua_State*, T*) [with T = const osmium::Node; lua_State = lua_State]’
third_party/sol/sol.hpp:4250:99:   required from ‘int sol::stack::push(lua_State*, T&&, Args&& ...) [with T = const osmium::Node*; Args = {}; lua_State = lua_State]’
third_party/sol/sol.hpp:5923:23:   required from ‘static int sol::stack::pusher<sol::detail::as_reference_tag>::push(lua_State*, T&&) [with T = const osmium::Node&; lua_State = lua_State]’
third_party/sol/sol.hpp:4267:171:   required from ‘int sol::stack::push_reference(lua_State*, T&&, Args&& ...) [with T = const osmium::Node&; Args = {}; lua_State = lua_State]’
third_party/sol/sol.hpp:4289:34:   required from ‘int sol::stack::multi_push_reference(lua_State*, T&&, Args&& ...) [with T = const osmium::Node&; Args = {}; lua_State = lua_State]’
third_party/sol/sol.hpp:8939:47:   required from ‘decltype(auto) sol::basic_function<T>::call(Args&& ...) const [with Ret = {}; Args = {const osmium::Node&}; base_t = sol::reference]’
third_party/sol/sol.hpp:8928:17:   required from ‘sol::function_result sol::basic_function<T>::operator()(Args&& ...) const [with Args = {const osmium::Node&}; base_t = sol::reference]’
main.cc:37:24:   required from here
third_party/sol/sol.hpp:11053:125: error: no type named ‘value_type’ in ‘std::remove_cv<osmium::Node>::type {aka class osmium::Node}’
   typedef std::conditional_t<is_associative::value, typename T::value_type, std::pair<std::size_t, typename T::value_type>> KV;

(can be replicated by checking out that repository and running ./build.sh)

I hit these errors after trying to use the type trait features added to fix container detection as you can see from the is_container type trait. Looking at the specific place in code this is erroring on, it seems like there are still some assumptions about the type I'm registering, i.e., that it has a value_type member.

cc @daniel-j-h

[ThePhD]

This seems like it's just erroring improperly in general: it doesn't ask for value_type in the non-container metatable code, so it's taking the wrong path for some reason...

[ThePhD]

Alright! You're all set now:

It builds without a problem. Sorry about that, I forgot to strip the constness away from a pointer, so it was failing to properly detect your is_container override (because it would come as const osmium::Node, and not just osmium::Node).

Get the latest, it's been re-published: https://github.com/ThePhD/sol2/releases/tag/v2.15.3

Thanks for using sol2 for your project. I hope it works out well for you.

[daniel-j-h]

Again, I'm amazed by how you run this project.

For the record, the original issues is in https://github.com/Project-OSRM/osrm-backend a routing engine for OpenStreetMap data where Lua-based profiles let you customize the routing graph, speeds and similar. Fortunately @karenzshea could reproduce it down to a smaller self-contained test case.

We're running on Luabind and it's a constant pain not only for us but also for users. As soon as we manage to port our code we will switch over to sol2 and never look back.

[ThePhD]

Oh, man. Luabind....

That stuff is rough. It has a lot of features that inspired sol2 but hell, that code doesn't have a good underlying implementation and isn't ancient. People still use it to this day, though, because it's so fully featured. I hope sol2 can replace it _entirely_, as well as every other Lua library in the world.