summaryrefslogtreecommitdiffstatshomepage
path: root/3rdparty/sol2/docs/source
diff options
context:
space:
mode:
Diffstat (limited to '3rdparty/sol2/docs/source')
-rw-r--r--3rdparty/sol2/docs/source/api/api-top.rst48
-rw-r--r--3rdparty/sol2/docs/source/api/as_args.rst50
-rw-r--r--3rdparty/sol2/docs/source/api/as_function.rst67
-rw-r--r--3rdparty/sol2/docs/source/api/as_table.rst28
-rw-r--r--3rdparty/sol2/docs/source/api/c_call.rst71
-rw-r--r--3rdparty/sol2/docs/source/api/compatibility.rst16
-rw-r--r--3rdparty/sol2/docs/source/api/containers.rst103
-rw-r--r--3rdparty/sol2/docs/source/api/coroutine.rst109
-rw-r--r--3rdparty/sol2/docs/source/api/error.rst15
-rw-r--r--3rdparty/sol2/docs/source/api/function.rst108
-rw-r--r--3rdparty/sol2/docs/source/api/make_reference.rst26
-rw-r--r--3rdparty/sol2/docs/source/api/metatable_key.rst154
-rw-r--r--3rdparty/sol2/docs/source/api/object.rst70
-rw-r--r--3rdparty/sol2/docs/source/api/optional.rst6
-rw-r--r--3rdparty/sol2/docs/source/api/overload.rst89
-rw-r--r--3rdparty/sol2/docs/source/api/property.rst64
-rw-r--r--3rdparty/sol2/docs/source/api/protect.rst33
-rw-r--r--3rdparty/sol2/docs/source/api/protected_function.rst187
-rw-r--r--3rdparty/sol2/docs/source/api/proxy.rst201
-rw-r--r--3rdparty/sol2/docs/source/api/readonly.rst68
-rw-r--r--3rdparty/sol2/docs/source/api/reference.rst78
-rw-r--r--3rdparty/sol2/docs/source/api/resolve.rst65
-rw-r--r--3rdparty/sol2/docs/source/api/simple_usertype.rst33
-rw-r--r--3rdparty/sol2/docs/source/api/stack.rst199
-rw-r--r--3rdparty/sol2/docs/source/api/stack_reference.rst8
-rw-r--r--3rdparty/sol2/docs/source/api/state.rst150
-rw-r--r--3rdparty/sol2/docs/source/api/table.rst216
-rw-r--r--3rdparty/sol2/docs/source/api/this_state.rst31
-rw-r--r--3rdparty/sol2/docs/source/api/thread.rst80
-rw-r--r--3rdparty/sol2/docs/source/api/tie.rst26
-rw-r--r--3rdparty/sol2/docs/source/api/types.rst207
-rw-r--r--3rdparty/sol2/docs/source/api/unique_usertype_traits.rst44
-rw-r--r--3rdparty/sol2/docs/source/api/user.rst19
-rw-r--r--3rdparty/sol2/docs/source/api/userdata.rst13
-rw-r--r--3rdparty/sol2/docs/source/api/usertype.rst330
-rw-r--r--3rdparty/sol2/docs/source/api/usertype_memory.rst47
-rw-r--r--3rdparty/sol2/docs/source/api/var.rst49
-rw-r--r--3rdparty/sol2/docs/source/api/variadic_args.rst49
-rw-r--r--3rdparty/sol2/docs/source/benchmarks.rst94
-rw-r--r--3rdparty/sol2/docs/source/cmake.rst54
-rw-r--r--3rdparty/sol2/docs/source/codecvt.rst8
-rw-r--r--3rdparty/sol2/docs/source/compilation.rst25
-rw-r--r--3rdparty/sol2/docs/source/conf.py291
-rw-r--r--3rdparty/sol2/docs/source/eevee_code_after.jpgbin9593 -> 0 bytes
-rw-r--r--3rdparty/sol2/docs/source/eevee_code_before.jpgbin59507 -> 0 bytes
-rw-r--r--3rdparty/sol2/docs/source/errors.rst56
-rw-r--r--3rdparty/sol2/docs/source/exceptions.rst65
-rw-r--r--3rdparty/sol2/docs/source/features.rst259
-rw-r--r--3rdparty/sol2/docs/source/index.rst132
-rw-r--r--3rdparty/sol2/docs/source/licenses.rst47
-rw-r--r--3rdparty/sol2/docs/source/mentions.rst62
-rw-r--r--3rdparty/sol2/docs/source/origin.rst28
-rw-r--r--3rdparty/sol2/docs/source/performance.rst17
-rw-r--r--3rdparty/sol2/docs/source/rtti.rst14
-rw-r--r--3rdparty/sol2/docs/source/safety.rst22
-rw-r--r--3rdparty/sol2/docs/source/sol.pngbin14482 -> 0 bytes
-rw-r--r--3rdparty/sol2/docs/source/sol.psdbin121930 -> 0 bytes
-rw-r--r--3rdparty/sol2/docs/source/traits.rst15
-rw-r--r--3rdparty/sol2/docs/source/tutorial/all-the-things.rst628
-rw-r--r--3rdparty/sol2/docs/source/tutorial/customization.rst117
-rw-r--r--3rdparty/sol2/docs/source/tutorial/cxx-in-lua.rst138
-rw-r--r--3rdparty/sol2/docs/source/tutorial/existing.rst27
-rw-r--r--3rdparty/sol2/docs/source/tutorial/functions.rst341
-rw-r--r--3rdparty/sol2/docs/source/tutorial/getting-started.rst79
-rw-r--r--3rdparty/sol2/docs/source/tutorial/ownership.rst94
-rw-r--r--3rdparty/sol2/docs/source/tutorial/tutorial-top.rst21
-rw-r--r--3rdparty/sol2/docs/source/tutorial/variables.rst202
-rw-r--r--3rdparty/sol2/docs/source/usertypes.rst29
68 files changed, 0 insertions, 6022 deletions
diff --git a/3rdparty/sol2/docs/source/api/api-top.rst b/3rdparty/sol2/docs/source/api/api-top.rst
deleted file mode 100644
index ebeabf3ee3b..00000000000
--- a/3rdparty/sol2/docs/source/api/api-top.rst
+++ /dev/null
@@ -1,48 +0,0 @@
-api reference manual
-====================
-
-Browse the various function and classes :doc:`Sol<../index>` utilizes to make your life easier when working with Lua.
-
-
-.. toctree::
- :caption: Sol API
- :name: apitoc
- :maxdepth: 2
-
- state
- table
- proxy
- containers
- as_table
- usertype
- simple_usertype
- usertype_memory
- unique_usertype_traits
- tie
- function
- protected_function
- coroutine
- error
- object
- userdata
- reference
- thread
- stack_reference
- make_reference
- optional
- this_state
- variadic_args
- as_args
- overload
- property
- var
- protect
- readonly
- as_function
- c_call
- resolve
- stack
- user
- compatibility
- types
- metatable_key
diff --git a/3rdparty/sol2/docs/source/api/as_args.rst b/3rdparty/sol2/docs/source/api/as_args.rst
deleted file mode 100644
index 8e323fdfaba..00000000000
--- a/3rdparty/sol2/docs/source/api/as_args.rst
+++ /dev/null
@@ -1,50 +0,0 @@
-as_args
-=======
-turn an iterable argument into multiple arguments
--------------------------------------------------
-
-.. code-block:: cpp
-
- template <typename T>
- as_args_t { ... };
-
- template <typename T>
- as_args_t<T> as_args( T&& );
-
-
-``sol::as_args`` is a function that that takes an iterable and turns it into multiple arguments to a function call. It forwards its arguments, and is meant to be used as shown below:
-
-.. code-block:: cpp
- :caption: as_args.c++
-
- #define SOL_CHECK_ARGUMENTS
- #include <sol.hpp>
-
- #include <vector>
- #include <set>
-
- int main(int argc, const char* argv[]) {
-
- sol::state lua;
- lua.open_libraries();
-
- lua.script("function f (a, b, c, d) print(a, b, c, d) end");
-
- sol::function f = lua["f"];
-
- std::vector<int> v2{ 3, 4 };
- f(1, 2, sol::as_args(v2));
-
- std::set<int> v4{ 3, 1, 2, 4 };
- f(sol::as_args(v4));
-
- int v3[] = { 2, 3, 4 };
- f(1, sol::as_args(v3));
-
- return 0;
- }
-
-
-It is basically implemented as a `one-way customization point`_. For more information about customization points, see the :doc:`tutorial on how to customize Sol to work with your types<../tutorial/customization>`.
-
-.. _one-way customization point: https://github.com/ThePhD/sol2/blob/develop/sol/as_args.hpp
diff --git a/3rdparty/sol2/docs/source/api/as_function.rst b/3rdparty/sol2/docs/source/api/as_function.rst
deleted file mode 100644
index bb058ba52c7..00000000000
--- a/3rdparty/sol2/docs/source/api/as_function.rst
+++ /dev/null
@@ -1,67 +0,0 @@
-as_function
-===========
-make sure an object is pushed as a function
--------------------------------------------
-
-.. code-block:: cpp
-
- template <typename Sig = sol::function_sig<>, typename... Args>
- function_argumants<Sig, Args...> as_function ( Args&& ... );
-
-This function serves the purpose of ensuring that a callable struct (like a lambda) can be passed to the ``set( key, value )`` calls on :ref:`sol::table<set-value>` and be treated like a function binding instead of a userdata. It is recommended that one uses the :ref:`sol::table::set_function<set-function>` call instead, but if for some reason one must use ``set``, then ``as_function`` can help ensure a callable struct is handled like a lambda / callable, and not as just a userdata structure.
-
-This class can also make it so usertypes bind variable types as functions to for usertype bindings.
-
-.. code-block:: cpp
-
- #include <sol.hpp>
-
- int main () {
- struct callable {
- int operator()( int a, bool b ) {
- return a + b ? 10 : 20;
- }
- };
-
-
- sol::state lua;
- // Binds struct as userdata
- lua.set( "not_func", callable() );
- // Binds struct as function
- lua.set( "func", sol::as_function( callable() ) );
- // equivalent: lua.set_function( "func", callable() );
- // equivalent: lua["func"] = callable();
- }
-
-Note that if you actually want a userdata, but you want it to be callable, you simply need to create a :ref:`sol::table::new_usertype<new-usertype>` and then bind the ``"__call"`` metamethod (or just use ``sol::meta_function::call`` :ref:`enumeration<meta_function_enum>`).
-
-Here's an example of binding a variable as a function to a usertype:
-
-.. code-block:: cpp
-
- #include <sol.hpp>
-
- int main () {
- class B {
- public:
- int bvar = 24;
- };
-
- sol::state lua;
- lua.open_libraries();
- lua.new_usertype<B>("B",
- // bind as variable
- "b", &B::bvar,
- // bind as function
- "f", sol::as_function(&B::bvar)
- );
-
- B b;
- lua.set("b", &b);
- lua.script("x = b:f()");
- lua.script("y = b.b");
- int x = lua["x"];
- int y = lua["y"];
- assert(x == 24);
- assert(y == 24);
- }
diff --git a/3rdparty/sol2/docs/source/api/as_table.rst b/3rdparty/sol2/docs/source/api/as_table.rst
deleted file mode 100644
index e5b58b49fa4..00000000000
--- a/3rdparty/sol2/docs/source/api/as_table.rst
+++ /dev/null
@@ -1,28 +0,0 @@
-as_table
-===========
-make sure an object is pushed as a table
-----------------------------------------
-
-.. code-block:: cpp
-
- template <typename T>
- as_table_t { ... };
-
- template <typename T>
- as_table_t<T> as_function ( T&& container );
-
-This function serves the purpose of ensuring that an object is pushed -- if possible -- like a table into Lua. The container passed here can be a pointer, a reference, a ``std::reference_wrapper`` around a container, or just a plain container value. It must have a begin/end function, and if it has a ``std::pair<Key, Value>`` as its ``value_type``, it will be pushed as a dictionary. Otherwise, it's pushed as a sequence.
-
-.. code-block:: cpp
-
- sol::state lua;
- lua.open_libraries();
- lua.set("my_table", sol::as_table(std::vector<int>{ 1, 2, 3, 4, 5 }));
- lua.script("for k, v in ipairs(my_table) do print(k, v) assert(k == v) end");
-
-
-Note that any caveats with Lua tables apply the moment it is serialized, and the data cannot be gotten out back out in C++ as a C++ type without explicitly using the ``as_table_t`` marker for your get and conversion operations using Sol.
-
-If you need this functionality with a member variable, use a :doc:`property on a getter function<property>` that returns the result of ``sol::as_table``.
-
-This marker does NOT apply to :doc:`usertypes<usertype>`. \ No newline at end of file
diff --git a/3rdparty/sol2/docs/source/api/c_call.rst b/3rdparty/sol2/docs/source/api/c_call.rst
deleted file mode 100644
index 36395eea549..00000000000
--- a/3rdparty/sol2/docs/source/api/c_call.rst
+++ /dev/null
@@ -1,71 +0,0 @@
-c_call
-======
-Templated type to transport functions through templates
--------------------------------------------------------
-
-.. code-block:: cpp
-
- template <typename Function, Function f>
- int c_call (lua_State* L);
-
- template <typename... Functions>
- int c_call (lua_State* L);
-
-The goal of ``sol::c_call<...>`` is to provide a way to wrap a function and transport it through a compile-time context. This enables faster speed at the cost of a much harder to read / poorer interface. ``sol::c_call`` expects a type for its first template argument, and a value of the previously provided type for the second template argument. To make a compile-time transported overloaded function, specify multiple functions in the same ``type, value`` pairing, but put it inside of a ``sol::wrap``. Note that is can also be placed into the argument list for a :doc:`usertype<usertype>` as well.
-
-It is advisable for the user to consider making a macro to do the necessary ``decltype( &function_name, ), function_name``. Sol does not provide one because many codebases already have `one similar to this`_.
-
-Here's an example below of various ways to use ``sol::c_call``:
-
-.. code-block:: cpp
- :linenos:
- :caption: Compile-time transported function calls
-
- #include "sol.hpp"
-
- int f1(int) { return 32; }
- int f2(int, int) { return 1; }
- struct fer {
- double f3(int, int) {
- return 2.5;
- }
- };
-
-
- int main() {
-
- sol::state lua;
- // overloaded function f
- lua.set("f", sol::c_call<sol::wrap<decltype(&f1), &f1>, sol::wrap<decltype(&f2), &f2>, sol::wrap<decltype(&fer::f3), &fer::f3>>);
- // singly-wrapped function
- lua.set("g", sol::c_call<sol::wrap<decltype(&f1), &f1>>);
- // without the 'sol::wrap' boilerplate
- lua.set("h", sol::c_call<decltype(&f2), &f2>);
- // object used for the 'fer' member function call
- lua.set("obj", fer());
-
- // call them like any other bound function
- lua.script("r1 = f(1)");
- lua.script("r2 = f(1, 2)");
- lua.script("r3 = f(obj, 1, 2)");
- lua.script("r4 = g(1)");
- lua.script("r5 = h(1, 2)");
-
- // get the results and see
- // if it worked out
- int r1 = lua["r1"];
- // r1 == 32
- int r2 = lua["r2"];
- // r2 == 1
- double r3 = lua["r3"];
- // r3 == 2.5
- int r4 = lua["r4"];
- // r4 == 32
- int r5 = lua["r5"];
- // r5 == 1
-
- return 0;
- }
-
-
-.. _one similar to this: http://stackoverflow.com/a/5628222/5280922
diff --git a/3rdparty/sol2/docs/source/api/compatibility.rst b/3rdparty/sol2/docs/source/api/compatibility.rst
deleted file mode 100644
index 3299bff931b..00000000000
--- a/3rdparty/sol2/docs/source/api/compatibility.rst
+++ /dev/null
@@ -1,16 +0,0 @@
-compatibility.hpp
-=================
-Lua 5.3/5.2 compatibility for Lua 5.1/LuaJIT
---------------------------------------------
-
-This is a detail header used to maintain compatability with the 5.2 and 5.3 APIs. It contains code from the MIT-Licensed `Lua code`_ in some places and also from the `lua-compat`_ repository by KeplerProject.
-
-It is not fully documented as this header's only purpose is for internal use to make sure Sol compiles across all platforms / distributions with no errors or missing Lua functionality. If you think there's some compatibility features we are missing or if you are running into redefinition errors, please make an `issue in the issue tracker`_.
-
-If you have this already in your project or you have your own compatibility layer, then please ``#define SOL_NO_COMPAT 1`` before including ``sol.hpp`` or pass this flag on the command line to turn off the compatibility wrapper.
-
-For the licenses, see :doc:`here<../licenses>`
-
-.. _issue in the issue tracker: https://github.com/ThePhD/sol2/issues/
-.. _Lua code: http://www.Lua.org/
-.. _lua-compat: https://github.com/keplerproject/lua-compat-5.3 \ No newline at end of file
diff --git a/3rdparty/sol2/docs/source/api/containers.rst b/3rdparty/sol2/docs/source/api/containers.rst
deleted file mode 100644
index 8e084a908fd..00000000000
--- a/3rdparty/sol2/docs/source/api/containers.rst
+++ /dev/null
@@ -1,103 +0,0 @@
-containers
-==========
-for handling ``std::vector/map/set`` and others
------------------------------------------------
-
-Sol2 automatically converts containers (detected using the ``sol::is_container<T>`` type trait, which simply looks for begin / end) to be a special kind of userdata with metatable on it. For Lua 5.2 and 5.3, this is extremely helpful as you can make typical containers behave like Lua tables without losing the actual container that they came from, as well as a small amount of indexing and other operations that behave properly given the table type.
-
-
-a complete example
-------------------
-
-Here's a complete working example of it working for Lua 5.3 and Lua 5.2, and how you can retrieve out the container in all versions:
-
-.. code-block:: cpp
- :caption: containers.cpp
-
- #define SOL_CHECK_ARGUMENTS
- #include <sol.hpp>
-
- int main() {
- sol::state lua;
- lua.open_libraries();
-
- lua.script(R"(
- function f (x)
- print('--- Calling f ---')
- for k, v in pairs(x) do
- print(k, v)
- end
- end
- )");
-
- // Have the function we
- // just defined in Lua
- sol::function f = lua["f"];
-
- // Set a global variable called
- // "arr" to be a vector of 5 lements
- lua["arr"] = std::vector<int>{ 2, 4, 6, 8, 10 };
-
- // Call it, see 5 elements
- // printed out
- f(lua["arr"]);
-
- // Mess with it in C++
- std::vector<int>& reference_to_arr = lua["arr"];
- reference_to_arr.push_back(12);
-
- // Call it, see *6* elements
- // printed out
- f(lua["arr"]);
-
- return 0;
- }
-
-
-Note that this will not work well in Lua 5.1, as it has explicit table checks and does not check metamethods, even when ``pairs`` or ``ipairs`` is passed a table. In that case, you will need to use a more manual iteration scheme or you will have to convert it to a table. In C++, you can use :doc:`sol::as_table<as_table>` when passing something to the library to get a table out of it: ``lua["arr"] = as_table( std::vector<int>{ ... });``. For manual iteration in Lua code without using ``as_table`` for something with indices, try:
-
-.. code-block:: lua
- :caption: iteration.lua
-
- for i = 1, #vec do
- print(i, vec[i])
- end
-
-There are also other ways to iterate over key/values, but they can be difficult due to not having proper support in Lua 5.1. We recommend that you upgrade to Lua 5.2 or 5.3.
-
-
-additional functions
---------------------
-
-Based on the type pushed, a few additional functions are added as "member functions" (``self`` functions called with ``obj:func()`` or ``obj.func(obj)`` syntax) within a Lua script:
-
-* ``my_container:clear()``: This will call the underlying containers ``clear`` function.
-* ``my_container:add( key, value )`` or ``my_container:add( value )``: this will add to the end of the container, or if it is an associative or ordered container, simply put in an expected key-value pair into it.
-* ``my_contaner:insert( where, value )`` or ``my_contaner:insert( key, value )``: similar to add, but it only takes two arguments. In the case of ``std::vector`` and the like, the first argument is a ``where`` integer index. The second argument is the value. For associative containers, a key and value argument are expected.
-
-
-.. _container-detection:
-
-too-eager container detection?
-------------------------------
-
-
-If you have a type that has ``begin`` or ``end`` member functions but don't provide iterators, you can specialize ``sol::is_container<T>`` to be ``std::false_type``, and that will treat the type as a regular usertype and push it as a regular userdata:
-
-.. code-block:: cpp
- :caption: specialization.hpp
-
- struct not_container {
- void begin() {
-
- }
-
- void end() {
-
- }
- };
-
- namespace sol {
- template <>
- struct is_container<not_container> : std::false_type {};
- } \ No newline at end of file
diff --git a/3rdparty/sol2/docs/source/api/coroutine.rst b/3rdparty/sol2/docs/source/api/coroutine.rst
deleted file mode 100644
index 3d03da31f5c..00000000000
--- a/3rdparty/sol2/docs/source/api/coroutine.rst
+++ /dev/null
@@ -1,109 +0,0 @@
-coroutine
-=========
-resumable/yielding functions from Lua
--------------------------------------
-
-A ``coroutine`` is a :doc:`reference<reference>` to a function in Lua that can be called multiple times to yield a specific result. It is run on the :doc:`lua_State<state>` that was used to create it (see :doc:`thread<thread>` for an example on how to get a coroutine that runs on a thread separate from your usual "main" :doc:`lua_State<state>`).
-
-The ``coroutine`` object is entirely similar to the :doc:`protected_function<protected_function>` object, with additional member functions to check if a coroutine has yielded (:doc:`call_status::yielded<types>`) and is thus runnable again, whether it has completed (:ref:`call_status::ok<call-status>`) and thus cannot yield anymore values, or whether it has suffered an error (see :ref:`status()<status>` and :ref:`call_status<call-status>`'s error codes).
-
-For example, you can work with a coroutine like this:
-
-.. code-block:: lua
- :caption: co.lua
-
- function loop()
- while counter ~= 30
- do
- coroutine.yield(counter);
- counter = counter + 1;
- end
- return counter
- end
-
-This is a function that yields:
-
-.. code-block:: cpp
- :caption: main.cpp
-
- sol::state lua;
- lua.open_libraries(sol::lib::base, sol::lib::coroutine);
- lua.script_file("co.lua");
- sol::coroutine cr = lua["loop"];
-
- for (int counter = 0; // start from 0
- counter < 10 && cr; // we want 10 values, and we only want to run if the coroutine "cr" is valid
- // Alternative: counter < 10 && cr.valid()
- ++counter) {
- // Call the coroutine, does the computation and then suspends
- int value = cr();
- }
-
-Note that this code doesn't check for errors: to do so, you can call the function and assign it as ``auto result = cr();``, then check ``result.valid()`` as is the case with :doc:`protected_function<protected_function>`. Finally, you can run this coroutine on another thread by doing the following:
-
-.. code-block:: cpp
- :caption: main_with_thread.cpp
-
- sol::state lua;
- lua.open_libraries(sol::lib::base, sol::lib::coroutine);
- lua.script_file("co.lua");
- sol::thread runner = sol::thread::create(lua.lua_state());
- sol::state_view runnerstate = runner.state();
- sol::coroutine cr = runnerstate["loop"];
-
- for (int counter = 0; counter < 10 && cr; ++counter) {
- // Call the coroutine, does the computation and then suspends
- int value = cr();
- }
-
-The following are the members of ``sol::coroutine``:
-
-members
--------
-
-.. code-block:: cpp
- :caption: function: constructor
-
- coroutine(lua_State* L, int index = -1);
-
-Grabs the coroutine at the specified index given a ``lua_State*``.
-
-.. code-block:: cpp
- :caption: returning the coroutine's status
- :name: status
-
- call_status status() const noexcept;
-
-Returns the status of a coroutine.
-
-
-.. code-block:: cpp
- :caption: checks for an error
-
- bool error() const noexcept;
-
-Checks if an error occured when the coroutine was run.
-
-.. _runnable:
-
-.. code-block:: cpp
- :caption: runnable and explicit operator bool
-
- bool runnable () const noexcept;
- explicit operator bool() const noexcept;
-
-These functions allow you to check if a coroutine can still be called (has more values to yield and has not errored). If you have a coroutine object ``coroutine my_co = /*...*/``, you can either check ``runnable()`` or do ``if ( my_co ) { /* use coroutine */ }``.
-
-.. code-block:: cpp
- :caption: calling a coroutine
-
- template<typename... Args>
- protected_function_result operator()( Args&&... args );
-
- template<typename... Ret, typename... Args>
- decltype(auto) call( Args&&... args );
-
- template<typename... Ret, typename... Args>
- decltype(auto) operator()( types<Ret...>, Args&&... args );
-
-Calls the coroutine. The second ``operator()`` lets you specify the templated return types using the ``my_co(sol::types<int, std::string>, ...)`` syntax. Check ``status()`` afterwards for more information about the success of the run or just check the coroutine object in an ifs tatement, as shown :ref:`above<runnable>`. \ No newline at end of file
diff --git a/3rdparty/sol2/docs/source/api/error.rst b/3rdparty/sol2/docs/source/api/error.rst
deleted file mode 100644
index 4bfe21e91a4..00000000000
--- a/3rdparty/sol2/docs/source/api/error.rst
+++ /dev/null
@@ -1,15 +0,0 @@
-error
-=====
-the single error/exception type
--------------------------------
-
-.. code-block:: cpp
-
- class error : public std::runtime_error {
- public:
- error(const std::string& str): std::runtime_error("Lua: error: " + str) {}
- };
-
-If an eror is thrown by Sol, it is going to be of this type. We use this in a single place: the default ``at_panic`` function we bind on construction of a :ref:`sol::state<set-panic>`. If you turn :doc:`off exceptions<../exceptions>`, the chances of you seeing this error are nil unless you specifically use it to pull errors out of things such as :doc:`sol::protected_function<protected_function>`.
-
-As it derives from ``std::runtime_error``, which derives from ``std::exception``, you can catch it with a ``catch (const std::exception& )`` clause in your try/catch blocks. You can retrieve a string error from Lua (Lua pushes all its errors as string returns) by using this type with any of the get or lookup functions in Sol. \ No newline at end of file
diff --git a/3rdparty/sol2/docs/source/api/function.rst b/3rdparty/sol2/docs/source/api/function.rst
deleted file mode 100644
index 1056bd2fe95..00000000000
--- a/3rdparty/sol2/docs/source/api/function.rst
+++ /dev/null
@@ -1,108 +0,0 @@
-function
-========
-calling functions bound to Lua
-------------------------------
-
-.. note::
-
- This abstraction assumes the function runs safely. If you expect your code to have errors (e.g., you don't always have explicit control over it or are trying to debug errors), please use :doc:`sol::protected_function<protected_function>`.
-
-.. code-block:: cpp
-
- class function : public reference;
-
-Function is a correct-assuming version of :doc:`protected_function<protected_function>`, omitting the need for typechecks and error handling. It is the default function type of Sol. Grab a function directly off the stack using the constructor:
-
-.. code-block:: cpp
- :caption: constructor: function
-
- function(lua_State* L, int index = -1);
-
-
-When called without the return types being specified by either a ``sol::types<...>`` list or a ``call<Ret...>( ... )`` template type list, it generates a :ref:`function_result<function-result>` class that gets implicitly converted to the requested return type. For example:
-
-.. code-block:: lua
- :caption: func_barks.lua
- :linenos:
-
- bark_power = 11;
-
- function woof ( bark_energy )
- return (bark_energy * (bark_power / 4))
- end
-
-The following C++ code will call this function from this file and retrieve the return value:
-
-.. code-block:: cpp
- :linenos:
-
- sol::state lua;
-
- lua.script_file( "func_barks.lua" );
-
- sol::function woof = lua["woof"];
- double numwoof = woof(20);
-
-The call ``woof(20)`` generates a :ref:`function_result<function-result>`, which is then implicitly converted to an ``double`` after being called. The intermediate temporary ``function_result`` is then destructed, popping the Lua function call results off the Lua stack.
-
-You can also return multiple values by using ``std::tuple``, or if you need to bind them to pre-existing variables use ``sol::tie``:
-
-.. code-block:: cpp
- :linenos:
-
- sol::state lua;
-
- lua.script( "function f () return 10, 11, 12 end" );
-
- sol::function f = lua["f"];
- std::tuple<int, int, int> abc = f(); // 10, 11, 12 from Lua
- // or
- int a, b, c;
- sol::tie(a, b, c) = f(); // a = 10, b = 11, c = 12 from Lua
-
-This makes it much easier to work with multiple return values. Using ``std::tie`` from the C++ standard will result in dangling references or bad behavior because of the very poor way in which C++ tuples/``std::tie`` were specified and implemented: please use ``sol::tie( ... )`` instead to satisfy any multi-return needs.
-
-.. _function-result-warning:
-
-.. warning::
-
- Do NOT save the return type of a :ref:`function_result<function-result>` with ``auto``, as in ``auto numwoof = woof(20);``, and do NOT store it anywhere. Unlike its counterpart :ref:`protected_function_result<protected-function-result>`, ``function_result`` is NOT safe to store as it assumes that its return types are still at the top of the stack and when its destructor is called will pop the number of results the function was supposed to return off the top of the stack. If you mess with the Lua stack between saving ``function_result`` and it being destructed, you will be subject to an incredible number of surprising and hard-to-track bugs. Don't do it.
-
-.. code-block:: cpp
- :caption: function: call operator / function call
-
- template<typename... Args>
- protected_function_result operator()( Args&&... args );
-
- template<typename... Ret, typename... Args>
- decltype(auto) call( Args&&... args );
-
- template<typename... Ret, typename... Args>
- decltype(auto) operator()( types<Ret...>, Args&&... args );
-
-Calls the function. The second ``operator()`` lets you specify the templated return types using the ``my_func(sol::types<int, std::string>, ...)`` syntax. Function assumes there are no runtime errors, and thusly will call the ``atpanic`` function if an error does occur.
-
-
-.. _function-argument-handling:
-
-functions and argument passing
-------------------------------
-
-.. note::
-
- All arguments are forwarded. Unlike :doc:`get/set/operator[] on sol::state<state>` or :doc:`sol::table<table>`, value semantics are not used here. It is forwarding reference semantics, which do not copy/move unless it is specifically done by the receiving functions / specifically done by the user.
-
-
-.. note::
-
- This also means that you should pass and receive arguments in certain ways to maximize efficiency. For example, ``sol::table``, ``sol::object``, ``sol::userdata`` and friends are fairly cheap to copy, and should simply by taken as values. This includes primitive types like ``int`` and ``double``. However, C++ types -- if you do not want copies -- should be taken as ``const type&`` or ``type&``, to save on copies if it's important. Note that taking references from Lua also means you can modify the data inside of Lua directly, so be careful. Lua by default deals with things mostly by reference (save for primitive types).
-
- You can get even more speed out of ``sol::object`` style of types by taking a ``sol::stack_object`` (or ``sol::stack_...``, where ``...`` is ``userdata``, ``reference``, ``table``, etc.). These reference a stack position directly rather than cheaply/safely the internal Lua reference to make sure it can't be swept out from under you. Note that if you manipulate the stack out from under these objects, they may misbehave, so please do not blow up your Lua stack when working with these types.
-
- ``std::string`` (and ``std::wstring``) are special. Lua stores strings as ``const char*`` null-terminated strings. ``std::string`` will copy, so taking a ``std::string`` by value or by const reference still invokes a copy operation. You can take a ``const char*``, but that will mean you're exposed to what happens on the Lua stack (if you change it and start chopping off function arguments from it in your function calls and such, as warned about previously).
-
-
-function call safety
---------------------
-
-You can have functions here and on usertypes check to definitely make sure that the types passed to C++ functions are what they're supposed to be by adding a ``#define SOL_CHECK_ARGUMENTS`` before including Sol, or passing it on the command line. Otherwise, for speed reasons, these checks are only used where absolutely necessary (like discriminating between :doc:`overloads<overload>`). See :doc:`safety<../safety>` for more information. \ No newline at end of file
diff --git a/3rdparty/sol2/docs/source/api/make_reference.rst b/3rdparty/sol2/docs/source/api/make_reference.rst
deleted file mode 100644
index cd39b5a31d9..00000000000
--- a/3rdparty/sol2/docs/source/api/make_reference.rst
+++ /dev/null
@@ -1,26 +0,0 @@
-make_object/make_reference
-==========================
-Create a value on the Lua stack and return it
----------------------------------------------
-
-.. code-block:: cpp
- :caption: function: make_reference
- :name: make-reference
-
- template <typename R = reference, bool should_pop = (R is not base of sol::stack_index), typename T>
- R make_reference(lua_State* L, T&& value);
- template <typename T, typename R = reference, bool should_pop = (R is base of sol::stack_index), typename... Args>
- R make_reference(lua_State* L, Args&&... args);
-
-Makes an ``R`` out of the value. The first overload deduces the type from the passed in argument, the second allows you to specify a template parameter and forward any relevant arguments to ``sol::stack::push``. The type figured out for ``R`` is what is referenced from the stack. This allows you to request arbitrary pop-able types from Sol and have it constructed from ``R(lua_State* L, int stack_index)``. If the template boolean ``should_pop`` is ``true``, the value that was pushed will be popped off the stack. It defaults to popping, but if it encounters a type such as :doc:`sol::stack_reference<stack_reference>` (or any of its typically derived types in Sol), it will leave the pushed values on the stack.
-
-.. code-block:: cpp
- :caption: function: make_object
- :name: make-object
-
- template <typename T>
- object make_object(lua_State* L, T&& value);
- template <typename T, typename... Args>
- object make_object(lua_State* L, Args&&... args);
-
-Makes an object out of the value. It pushes it onto the stack, then pops it into the returned ``sol::object``. The first overload deduces the type from the passed in argument, the second allows you to specify a template parameter and forward any relevant arguments to ``sol::stack::push``. The implementation essentially defers to :ref:`sol::make_reference<make-reference>` with the specified arguments, ``R == object`` and ``should_pop == true``. It is preferred that one uses the :ref:`in_place object constructor instead<overloaded-object-constructor>`, since it's probably easier to deal with, but both versions will be supported for forever, since there's really no reason not to and people already have dependencies on ``sol::make_object``.
diff --git a/3rdparty/sol2/docs/source/api/metatable_key.rst b/3rdparty/sol2/docs/source/api/metatable_key.rst
deleted file mode 100644
index 718eb2b2ffc..00000000000
--- a/3rdparty/sol2/docs/source/api/metatable_key.rst
+++ /dev/null
@@ -1,154 +0,0 @@
-metatable_key
-=============
-A key for setting and getting an object's metatable
----------------------------------------------------
-
-.. code-block:: cpp
-
- struct metatable_key_t {};
- const metatable_key_t metatable_key;
-
-You can use this in conjunction with :doc:`sol::table<table>` to set/get a metatable. Lua metatables are powerful ways to override default behavior of objects for various kinds of operators, among other things. Here is an entirely complete example, showing getting and working with a :doc:`usertype<usertype>`'s metatable defined by Sol:
-
-.. code-block:: cpp
- :caption: messing with metatables
- :linenos:
-
- #include <sol.hpp>
-
- int main () {
-
- struct bark {
- int operator()(int x) {
- return x;
- }
- };
-
- sol::state lua;
- lua.open_libraries(sol::lib::base);
-
- lua.new_usertype<bark>("bark",
- sol::meta_function::call_function, &bark::operator()
- );
-
- bark b;
- lua.set("b", &b);
-
- sol::table b_as_table = lua["b"];
- sol::table b_metatable = b_as_table[sol::metatable_key];
- sol::function b_call = b_metatable["__call"];
- sol::function b_as_function = lua["b"];
-
- int result1 = b_as_function(1);
- int result2 = b_call(b, 1);
- // result1 == result2 == 1
- }
-
-It's further possible to have a "Dynamic Getter" (`thanks to billw2012 and Nava2 for this example`_!):
-
-.. code-block:: cpp
- :caption: One way to make dynamic properties (there are others!)
- :linenos:
-
- #include <sol.hpp>
- #include <unordered_map>
-
- struct PropertySet {
- sol::object get_property_lua(const char* name, sol::this_state s)
- {
- auto& var = props[name];
- return sol::make_object(s, var);
- }
-
- void set_property_lua(const char* name, sol::stack_object object)
- {
- props[name] = object.as<std::string>();
- }
-
- std::unordered_map<std::string, std::string> props;
- };
-
- struct DynamicObject {
- PropertySet& get_dynamic_props() {
- return dynamic_props;
- }
-
- PropertySet dynamic_props;
- };
-
-
- int main () {
- sol::state lua;
- lua.open_libraries(sol::lib::base);
-
- lua.new_usertype<PropertySet>("PropertySet",
- sol::meta_function::new_index, &PropertySet::set_property_lua,
- sol::meta_function::index, &PropertySet::get_property_lua
- );
-
- lua.new_usertype<DynamicObject>("DynamicObject",
- "props", sol::property(&DynamicObject::get_dynamic_props)
- );
-
- lua.script(R"(
- obj = DynamicObject:new()
- obj.props.name = 'test name'
- print('name = ' .. obj.props.name)
- )");
-
- std::string name = lua["obj"]["props"]["name"];
- // name == "test name";
- }
-
-
-You can even manipulate the ability to set and get items using metatable objects on a usertype or similar:
-
-.. code-block:: cpp
- :caption: messing with metatables - vector type
- :linenos:
-
- #include <sol.hpp>
-
- class vector {
- public:
- double data[3];
-
- vector() : data{ 0,0,0 } {}
-
- double& operator[](int i)
- {
- return data[i];
- }
-
-
- static double my_index(vector& v, int i)
- {
- return v[i];
- }
-
- static void my_new_index(vector& v, int i, double x)
- {
- v[i] = x;
- }
- };
-
- int main () {
- sol::state lua;
- lua.open_libraries(sol::lib::base);
- lua.new_usertype<vector>("vector", sol::constructors<sol::types<>>(),
- sol::meta_function::index, &vector::my_index,
- sol::meta_function::new_index, &vector::my_new_index);
- lua.script("v = vector.new()\n"
- "print(v[1])\n"
- "v[2] = 3\n"
- "print(v[2])\n"
- );
-
- vector& v = lua["v"];
- // v[0] == 0.0;
- // v[1] == 0.0;
- // v[2] == 3.0;
- }
-
-
-.. _thanks to billw2012 and Nava2 for this example: https://github.com/ThePhD/sol2/issues/71#issuecomment-225402055 \ No newline at end of file
diff --git a/3rdparty/sol2/docs/source/api/object.rst b/3rdparty/sol2/docs/source/api/object.rst
deleted file mode 100644
index f38f089cc4d..00000000000
--- a/3rdparty/sol2/docs/source/api/object.rst
+++ /dev/null
@@ -1,70 +0,0 @@
-object
-======
-general-purpose safety reference to an existing object
-------------------------------------------------------
-
-.. code-block:: cpp
-
- class object : reference;
-
-
-``object``'s goal is to allow someone to pass around the most generic form of a reference to something in Lua (or propogate a ``nil``). It is the logical extension of :doc:`sol::reference<reference>`, and is used in :ref:`sol::table's iterators<table-iterators>`.
-
-
-members
--------
-
-.. code-block:: cpp
- :caption: overloaded constructor: object
- :name: overloaded-object-constructor
-
- template <typename T>
- object(T&&);
- object(lua_State* L, int index = -1);
- template <typename T, typename... Args>
- object(lua_State* L, in_place_t, T&& arg, Args&&... args);
- template <typename T, typename... Args>
- object(lua_State* L, in_place_type_t<T>, Args&&... args);
-
-There are 4 kinds of constructors here. One allows construction of an object from other reference types such as :doc:`sol::table<table>` and :doc:`sol::stack_reference<stack_reference>`. The second creates an object which references the specific element at the given index in the specified ``lua_State*``. The more advanced ``in_place...`` constructors create a single object by pushing the specified type ``T`` onto the stack and then setting it as the object. It gets popped from the stack afterwards (unless this is an instance of ``sol::stack_object``, in which case it is left on the stack). An example of using this and :doc:`sol::make_object<make_reference>` can be found in the `any_return example`_.
-
-.. code-block:: cpp
- :caption: function: type conversion
-
- template<typename T>
- decltype(auto) as() const;
-
-Performs a cast of the item this reference refers to into the type ``T`` and returns it. It obeys the same rules as :ref:`sol::stack::get\<T><getter>`.
-
-.. code-block:: cpp
- :caption: function: type check
-
- template<typename T>
- bool is() const;
-
-Performs a type check using the :ref:`sol::stack::check<checker>` api, after checking if the reference is valid.
-
-
-non-members
------------
-
-.. code-block:: cpp
- :caption: functions: nil comparators
-
- bool operator==(const object& lhs, const nil_t&);
- bool operator==(const nil_t&, const object& rhs);
- bool operator!=(const object& lhs, const nil_t&);
- bool operator!=(const nil_t&, const object& rhs);
-
-These allow a person to compare an ``sol::object`` against :ref:`nil<nil>`, which essentially checks if an object references a non-nil value, like so:
-
-.. code-block:: cpp
-
- if (myobj == sol::nil) {
- // doesn't have anything...
- }
-
-Use this to check objects.
-
-
-.. _any_return example: https://github.com/ThePhD/sol2/blob/develop/examples/any_return.cpp \ No newline at end of file
diff --git a/3rdparty/sol2/docs/source/api/optional.rst b/3rdparty/sol2/docs/source/api/optional.rst
deleted file mode 100644
index f999849bcd9..00000000000
--- a/3rdparty/sol2/docs/source/api/optional.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-optional<T>
-===========
-
-This is an implemention of `optional from the standard library`_. If it detects that a proper optional exists, it will attempt to use it. This is mostly an implementation detail, used in the :ref:`sol::stack::check_get<stack-check-get>` and :ref:`sol::stack::get\<optional\<T>><stack-get>` and ``optional<T> maybe_value = table["arf"];`` implementations for additional safety reasons.
-
-.. _optional from the standard library: http://en.cppreference.com/w/cpp/utility/optional \ No newline at end of file
diff --git a/3rdparty/sol2/docs/source/api/overload.rst b/3rdparty/sol2/docs/source/api/overload.rst
deleted file mode 100644
index 399b409d1af..00000000000
--- a/3rdparty/sol2/docs/source/api/overload.rst
+++ /dev/null
@@ -1,89 +0,0 @@
-overload
-========
-calling different functions based on argument number/type
----------------------------------------------------------
-
-this function helps users make overloaded functions that can be called from Lua using 1 name but multiple arguments. It is meant to replace the spaghetti of code whre users mock this up by doing strange if statemetns and switches on what version of a function to call based on `luaL_check{number/udata/string}`_. Its use is simple: whereever you can pass a function type to Lua, whether its on a :doc:`usertype<usertype>` or if you are just setting any kind of function with ``set`` or ``set_function`` (for :doc:`table<table>` or :doc:`state(_view)<state>`), simply wrap up the functions you wish to be considered for overload resolution on one function like so:
-
-.. code-block:: cpp
-
- sol::overload( func1, func2, ... funcN );
-
-
-The functions can be any kind of function / function object (lambda). Given these functions and struct:
-
-.. code-block:: cpp
- :linenos:
-
- struct pup {
- int barks = 0;
-
- void bark () {
- ++barks; // bark!
- }
-
- bool is_cute () const {
- return true;
- }
- };
-
- void ultra_bark( pup& p, int barks) {
- for (; barks --> 0;) p.bark();
- }
-
- void picky_bark( pup& p, std::string s) {
- if ( s == "bark" )
- p.bark();
- }
-
-You then use it just like you would for any other part of the api:
-
-.. code-block:: cpp
- :linenos:
-
- sol::state lua;
-
- lua.set_function( "bark", sol::overload(
- ultra_bark,
- []() { return "the bark from nowhere"; }
- ) );
-
- lua.new_usertype<pup>( "pup",
- // regular function
- "is_cute", &pup::is_cute,
- // overloaded function
- "bark", sol::overload( &pup::bark, &picky_bark )
- );
-
-Thusly, doing the following in Lua:
-
-.. code-block:: Lua
- :caption: pup.lua
- :linenos:
-
- local barker = pup.new()
- pup:bark() -- calls member function pup::bark
- pup:bark(20) -- calls ultra_bark
- pup:bark("meow") -- picky_bark, no bark
- pup:bark("bark") -- picky_bark, bark
-
- bark(pup, 20) -- calls ultra_bark
- local nowherebark = bark() -- calls lambda which returns that string
-
-The actual class produced by ``sol::overload`` is essentially a type-wrapper around ``std::tuple`` that signals to the library that an overload is being created:
-
-.. code-block:: cpp
- :caption: function: create overloaded set
- :linenos:
-
- template <typename... Args>
- struct overloaded_set : std::tuple<Args...> { /* ... */ };
-
- template <typename... Args>
- overloaded_set<Args...> overload( Args&&... args );
-
-.. note::
-
- Please keep in mind that doing this bears a runtime cost to find the proper overload. The cost scales directly not exactly with the number of overloads, but the number of functions that have the same argument count as each other (Sol will early-eliminate any functions that do not match the argument count).
-
-.. _luaL_check{number/udata/string}: http://www.Lua.org/manual/5.3/manual.html#luaL_checkinteger
diff --git a/3rdparty/sol2/docs/source/api/property.rst b/3rdparty/sol2/docs/source/api/property.rst
deleted file mode 100644
index e3ee02e2353..00000000000
--- a/3rdparty/sol2/docs/source/api/property.rst
+++ /dev/null
@@ -1,64 +0,0 @@
-property
-========
-
-.. code-block:: cpp
-
- template <typename Read, typename Write>
- decltype(auto) property ( Read&& read_function, Write&& write_function );
- template <typename Read>
- decltype(auto) property ( Read&& read_function );
- template <typename Write>
- decltype(auto) property ( Write&& write_function );
-
-These set of functions create a type which allows a setter and getter pair (or a single getter, or a single setter) to be used to create a variable that is either read-write, read-only, or write-only. When used during :doc:`usertype<usertype>` construction, it will create a variable that uses the setter/getter member function specified.
-
-.. code-block:: cpp
- :caption: player.hpp
- :linenos:
-
- class Player {
- public:
- int get_hp() const {
- return hp;
- }
-
- void set_hp( int value ) {
- hp = value;
- }
-
- int get_max_hp() const {
- return hp;
- }
-
- void set_max_hp( int value ) {
- maxhp = value;
- }
-
- private:
- int hp = 50;
- int maxHp = 50;
- }
-
-.. code-block:: cpp
- :caption: game.cpp
- :linenos:
-
- sol::state lua;
- lua.open_libraries(sol::lib::base);
-
- lua.set("theplayer", Player());
-
- // Yes, you can register after you set a value and it will
- // connect up the usertype automatically
- lua.new_usertype<Player>( "Player",
- "hp", sol::property(&Player::get_hp, &Player::set_hp),
- "maxHp", sol::property(&Player::get_max_hp, &Player::set_max_hp)
- );
-
-
-.. code-block:: lua
- :caption: game-snippet.lua
-
- -- variable syntax, calls functions
- theplayer.hp = 20
- print(theplayer.hp) \ No newline at end of file
diff --git a/3rdparty/sol2/docs/source/api/protect.rst b/3rdparty/sol2/docs/source/api/protect.rst
deleted file mode 100644
index 4f14cb0db2a..00000000000
--- a/3rdparty/sol2/docs/source/api/protect.rst
+++ /dev/null
@@ -1,33 +0,0 @@
-protect
-=======
-Routine to mark a function / variable as requiring safety
----------------------------------------------------------
-
-.. code-block:: cpp
-
- template <typename T>
- auto protect( T&& value );
-
-``sol::protect( my_func )`` allows you to protect a function call or member variable call when it is being set to Lua. It can be used with usertypes or when just setting a function into Sol. Below is an example that demonstrates that a call that would normally not error without :doc:`Safety features turned on<../safety>` that instead errors and makes the Lua safety-call wrapper ``pcall`` fail:
-
-.. code-block:: cpp
-
- struct protect_me {
- int gen(int x) {
- return x;
- }
- };
-
- sol::state lua;
- lua.open_libraries(sol::lib::base);
- lua.new_usertype<protect_me>("protect_me",
- "gen", sol::protect( &protect_me::gen )
- );
-
- lua.script(R"__(
- pm = protect_me.new()
- value = pcall(pm.gen,pm)
- )__");
- );
- bool value = lua["value"];
- // value == false
diff --git a/3rdparty/sol2/docs/source/api/protected_function.rst b/3rdparty/sol2/docs/source/api/protected_function.rst
deleted file mode 100644
index c9fb9b4f425..00000000000
--- a/3rdparty/sol2/docs/source/api/protected_function.rst
+++ /dev/null
@@ -1,187 +0,0 @@
-protected_function
-==================
-Lua function calls that trap errors and provide error handling
---------------------------------------------------------------
-
-.. code-block:: cpp
-
- class protected_function : public reference;
-
-Inspired by a request from `starwing<https://github.com/starwing>` in the old repository, this class provides the same interface as :doc:`function<function>` but with heavy protection and a potential error handler for any Lua errors and C++ exceptions. You can grab a function directly off the stack using the constructor, or pass to it 2 valid functions, which we'll demonstrate a little later.
-
-When called without the return types being specified by either a ``sol::types<...>`` list or a ``call<Ret...>( ... )`` template type list, it generates a :doc:`protected_function_result<proxy>` class that gets implicitly converted to the requested return type. For example:
-
-.. code-block:: lua
- :caption: pfunc_barks.lua
- :linenos:
-
- bark_power = 11;
-
- function got_problems( error_msg )
- return "got_problems handler: " .. error_msg
- end
-
- function woof ( bark_energy )
- if bark_energy < 20
- error("*whine*")
- end
- return (bark_energy * (bark_power / 4))
- end
-
- function woofers ( bark_energy )
- if bark_energy < 10
- error("*whine*")
- end
- return (bark_energy * (bark_power / 4))
- end
-
-The following C++ code will call this function from this file and retrieve the return value, unless an error occurs, in which case you can bind an error handling function like so:
-
-.. code-block:: cpp
- :linenos:
-
- sol::state lua;
-
- lua.open_file( "pfunc_barks.lua" );
-
- sol::protected_function problematicwoof = lua["woof"];
- problematicwoof.error_handler = lua["got_problems"];
-
- auto firstwoof = problematic_woof(20);
- if ( firstwoof.valid() ) {
- // Can work with contents
- double numwoof = first_woof;
- }
- else{
- // An error has occured
- sol::error err = first_woof;
- }
-
- // errors, calls handler and then returns a string error from Lua at the top of the stack
- auto secondwoof = problematic_woof(19);
- if (secondwoof.valid()) {
- // Call succeeded
- double numwoof = secondwoof;
- }
- else {
- // Call failed
- // Note that if the handler was successfully called, this will include
- // the additional appended error message information of
- // "got_problems handler: " ...
- sol::error err = secondwoof;
- std::string what = err.what();
- }
-
-This code is much more long-winded than its :doc:`function<function>` counterpart but allows a person to check for errors. The type here for ``auto`` are ``sol::protected_function_result``. They are implicitly convertible to result types, like all :doc:`proxy-style<proxy>` types are.
-
-Alternatively, with a bad or good function call, you can use ``sol::optional`` to check if the call succeeded or failed:
-
-.. code-block:: cpp
- :linenos:
-
- sol::state lua;
-
- lua.open_file( "pfunc_barks.lua" );
-
- sol::protected_function problematicwoof = lua["woof"];
- problematicwoof.error_handler = lua["got_problems"];
-
- sol::optional<double> maybevalue = problematicwoof(19);
- if (maybevalue) {
- // Have a value, use it
- double numwoof = maybevalue.value();
- }
- else {
- // No value!
- }
-
-That makes the code a bit more concise and easy to reason about if you don't want to bother with reading the error. Thankfully, unlike ``sol::function_result``, you can save ``sol::protected_function_result`` in a variable and push/pop things above it on the stack where its returned values are. This makes it a bit more flexible than the rigid, performant ``sol::function_result`` type that comes from calling :doc:`sol::function<function>`.
-
-If you're confident the result succeeded, you can also just put the type you want (like ``double`` or ``std::string`` right there and it will get it. But, if it doesn't work out, sol can throw and/or panic if you have the :doc:`safety<../safety>` features turned on:
-
-.. code-block:: cpp
- :linenos:
-
- sol::state lua;
-
- lua.open_file( "pfunc_barks.lua" );
-
- // construct with function + error handler
- // shorter than old syntax
- sol::protected_function problematicwoof(lua["woof"], lua["got_problems"]);
-
- // dangerous if things go wrong!
- double value = problematicwoof(19);
-
-
-Finally, it is *important* to note you can set a default handler. The function is described below: please use it to avoid having to constantly set error handlers:
-
-.. code-block:: cpp
- :linenos:
-
- sol::state lua;
-
- lua.open_file( "pfunc_barks.lua" );
- // sets got_problems as the default
- // handler for all protected_function errors
- sol::protected_function::set_default_handler(lua["got_problems"]);
-
- sol::protected_function problematicwoof = lua["woof"];
- sol::protected_function problematicwoofers = lua["woofers"];
-
- double value = problematicwoof(19);
- double value2 = problematicwoof(9);
-
-
-members
--------
-
-.. code-block:: cpp
- :caption: constructor: protected_function
-
- template <typename T>
- protected_function( T&& func, reference handler = sol::protected_function::get_default_handler() );
- protected_function( lua_State* L, int index = -1, reference handler = sol::protected_function::get_default_handler() );
-
-Constructs a ``protected_function``. Use the 2-argument version to pass a custom error handling function more easily. You can also set the :ref:`member variable error_handler<protected-function-error-handler>` after construction later. ``protected_function`` will always use the latest error handler set on the variable, which is either what you passed to it or the default *at the time of construction*.
-
-.. code-block:: cpp
- :caption: function: call operator / protected function call
-
- template<typename... Args>
- protected_function_result operator()( Args&&... args );
-
- template<typename... Ret, typename... Args>
- decltype(auto) call( Args&&... args );
-
- template<typename... Ret, typename... Args>
- decltype(auto) operator()( types<Ret...>, Args&&... args );
-
-Calls the function. The second ``operator()`` lets you specify the templated return types using the ``my_func(sol::types<int, std::string>, ...)`` syntax. If you specify no return type in any way, it produces s ``protected_function_result``.
-
-.. note::
-
- All arguments are forwarded. Unlike :doc:`get/set/operator[] on sol::state<state>` or :doc:`sol::table<table>`, value semantics are not used here. It is forwarding reference semantics, which do not copy/move unless it is specifically done by the receiving functions / specifically done by the user.
-
-
-.. code-block:: cpp
- :caption: default handlers
-
- static const reference& get_default_handler ();
- static void set_default_handler( reference& ref );
-
-Get and set the Lua entity that is used as the default error handler. The default is a no-ref error handler. You can change that by calling ``protected_function::set_default_handler( lua["my_handler"] );`` or similar: anything that produces a reference should be fine.
-
-.. code-block:: cpp
- :caption: variable: handler
- :name: protected-function-error-handler
-
- reference error_handler;
-
-The error-handler that is called should a runtime error that Lua can detect occurs. The error handler function needs to take a single string argument (use type std::string if you want to use a C++ function bound to lua as the error handler) and return a single string argument (again, return a std::string or string-alike argument from the C++ function if you're using one as the error handler). If :doc:`exceptions<../exceptions>` are enabled, Sol will attempt to convert the ``.what()`` argument of the exception into a string and then call the error handling function. It is a :doc:`reference<reference>`, as it must refer to something that exists in the lua registry or on the Lua stack. This is automatically set to the default error handler when ``protected_function`` is constructed.
-
-.. note::
-
- ``protected_function_result`` safely pops its values off the stack when its destructor is called, keeping track of the index and number of arguments that were supposed to be returned. If you remove items below it using ``lua_remove``, for example, it will not behave as expected. Please do not perform fundamentally stack-rearranging operations until the destructor is called (pushing/popping above it is just fine).
-
-To know more about how function arguments are handled, see :ref:`this note<function-argument-handling>`.
diff --git a/3rdparty/sol2/docs/source/api/proxy.rst b/3rdparty/sol2/docs/source/api/proxy.rst
deleted file mode 100644
index 897dbbaf7dd..00000000000
--- a/3rdparty/sol2/docs/source/api/proxy.rst
+++ /dev/null
@@ -1,201 +0,0 @@
-proxy, (protected\_)function_result - proxy_base derivatives
-============================================================
-``table[x]`` and ``function(...)`` conversion struct
-----------------------------------------------------
-
-.. code-block:: c++
-
- template <typename Recurring>
- struct proxy_base;
-
- template <typename Table, typename Key>
- struct proxy : proxy_base<...>;
-
- struct stack_proxy: proxy_base<...>;
-
- struct function_result : proxy_base<...>;
-
- struct protected_function_result: proxy_base<...>;
-
-
-These classes provide implicit assignment operator ``operator=`` (for ``set``) and an implicit conversion operator ``operator T`` (for ``get``) to support items retrieved from the underlying Lua implementation, specifically :doc:`sol::table<table>` and the results of function calls on :doc:`sol::function<function>` and :doc:`sol::protected_function<protected_function>`.
-
-.. _proxy:
-
-proxy
------
-
-``proxy`` is returned by lookups into :doc:`sol::table<table>` and table-like entities. Because it is templated on key and table type, it would be hard to spell: you can capture it using the word ``auto`` if you feel like you need to carry it around for some reason before using it. ``proxy`` evaluates its arguments lazily, when you finally call ``get`` or ``set`` on it. Here are some examples given the following lua script.
-
-.. code-block:: lua
- :linenos:
- :caption: lua nested table script
-
- bark = {
- woof = {
- [2] = "arf!"
- }
- }
-
-
-After loading that file in or putting it in a string and reading the string directly in lua (see :doc:`state`), you can start kicking around with it in C++ like so:
-
-.. code-block:: c++
- :linenos:
-
- sol::state lua;
-
- // produces proxy, implicitly converts to std::string, quietly destroys proxy
- std::string x = lua["bark"]["woof"][2];
-
-
-``proxy`` lazy evaluation:
-
-.. code-block:: c++
- :linenos:
- :caption: multi-get
-
- auto x = lua["bark"];
- auto y = x["woof"];
- auto z = x[2];
- // retrivies value inside of lua table above
- std::string value = z; // "arf!"
- // Can change the value later...
- z = 20;
- // Yay, lazy-evaluation!
- int changed_value = z; // now it's 20!
-
-
-We don't recommend the above to be used across classes or between function: it's more of something you can do to save a reference to a value you like, call a script or run a lua function, and then get it afterwards. You can also set functions (and function objects :ref:`*<note 1>`) this way, and retrieve them as well.
-
-.. code-block:: c++
- :linenos:
-
- lua["bark_value"] = 24;
- lua["chase_tail"] = floof::chase_tail; // chase_tail is a free function
-
-
-members
--------
-
-.. code-block:: c++
- :caption: functions: [overloaded] implicit conversion get
- :name: implicit-get
-
- requires( sol::is_primitive_type<T>::value == true )
- template <typename T>
- operator T() const;
-
- requires( sol::is_primitive_type<T>::value == false )
- template <typename T>
- operator T&() const;
-
-Gets the value associated with the keys the proxy was generated and convers it to the type ``T``. Note that this function will always return ``T&``, a non-const reference, to types which are not based on :doc:`sol::reference<reference>` and not a :doc:`primitive lua type<types>`
-
-.. code-block:: c++
- :caption: function: get a value
- :name: regular-get
-
- template <typename T>
- decltype(auto) get( ) const;
-
-Gets the value associated with the keys and converts it to the type ``T``.
-
-.. code-block:: c++
- :caption: function: optionally get a value
- :name: regular-get-or
-
- template <typename T, typename Otherwise>
- optional<T> get_or( Otherwise&& otherise ) const;
-
-Gets the value associated with the keys and converts it to the type ``T``. If it is not of the proper type, it will return a ``sol::nullopt`` instead.
-
-``operator[]`` proxy-only members
----------------------------------
-
-.. code-block:: c++
- :caption: function: valid
- :name: proxy-valid
-
- bool valid () const;
-
-Returns whether this proxy actually refers to a valid object. It uses :ref:`sol::stack::probe_get_field<stack-probe-get-field>` to determine whether or not its valid.
-
-.. code-block:: c++
- :caption: functions: [overloaded] implicit set
- :name: implicit-set
-
- requires( sol::detail::Function<Fx> == false )
- template <typename T>
- proxy& operator=( T&& value );
-
- requires( sol::detail::Function<Fx> == true )
- template <typename Fx>
- proxy& operator=( Fx&& function );
-
-Sets the value associated with the keys the proxy was generated with to ``value``. If this is a function, calls ``set_function``. If it is not, just calls ``set``. Does not exist on :ref:`function_result<function-result>` or :ref:`protected_function_result<protected-function-result>`. See :ref:`note<note 1>` for caveats.
-
-.. code-block:: c++
- :caption: function: set a callable
- :name: regular-set-function
-
- template <typename Fx>
- proxy& set_function( Fx&& fx );
-
-Sets the value associated with the keys the proxy was generated with to a function ``fx``. Does not exist on :ref:`function_result<function-result>` or :ref:`protected_function_result<protected-function-result>`.
-
-
-.. code-block:: c++
- :caption: function: set a value
- :name: regular-set
-
- template <typename T>
- proxy& set( T&& value );
-
-Sets the value associated with the keys the proxy was generated with to ``value``. Does not exist on :ref:`function_result<function-result>` or :ref:`protected_function_result<protected-function-result>`.
-
-stack_proxy
------------
-
-``sol::stack_proxy`` is what gets returned by :doc:`sol::variadic_args<variadic_args>` and other parts of the framework. It is similar to proxy, but is meant to alias a stack index and not a named variable.
-
-.. _function-result:
-
-function_result
----------------
-
-``function_result`` is a temporary-only, intermediate-only implicit conversion worker for when :doc:`function<function>` is called. It is *NOT* meant to be stored or captured with ``auto``. It provides fast access to the desired underlying value. It does not implement ``set`` / ``set_function`` / templated ``operator=``, as is present on :ref:`proxy<proxy>`.
-
-
-.. _protected-function-result:
-
-protected_function_result
--------------------------
-
-``protected_function_result`` is a nicer version of ``function_result`` that can be used to detect errors. Its gives safe access to the desired underlying value. It does not implement ``set`` / ``set_function`` / templated ``operator=`` as is present on :ref:`proxy<proxy>`.
-
-
-.. _note 1:
-
-on function objects and proxies
--------------------------------
-
-Consider the following:
-
-.. code-block:: cpp
- :linenos:
- :caption: Note 1 Case
-
- struct doge {
- int bark;
-
- void operator()() {
- bark += 1;
- }
- };
-
- sol::state lua;
- lua["object"] = doge{}; // bind constructed doge to "object"
- // but it binds as a function
-
-When you use the ``lua["object"] = doge{};`` from above, keep in mind that Sol detects if this is a function *callable with any kind of arguments*. Since ``doge`` has overriden ``return_type operator()( argument_types... )`` on itself, it results in satisfying the ``requires`` constraint from above. This means that if you have a user-defined type you want to bind as a :doc:`userdata with usertype semantics<usertype>` with this syntax, it might get bound as a function and not as a user-defined type (d'oh!). use ``lua["object"].set(doge)`` directly to avoid this, or ``lua["object"].set_function(doge{})`` to perform this explicitly. \ No newline at end of file
diff --git a/3rdparty/sol2/docs/source/api/readonly.rst b/3rdparty/sol2/docs/source/api/readonly.rst
deleted file mode 100644
index e36db3358ff..00000000000
--- a/3rdparty/sol2/docs/source/api/readonly.rst
+++ /dev/null
@@ -1,68 +0,0 @@
-readonly
-========
-routine to mark a member variable as read-only
-----------------------------------------------
-
-.. code-block:: cpp
-
- template <typename T>
- auto readonly( T&& value );
-
-The goal of read-only is to protect a variable set on a usertype or a function. Simply wrap it around a member variable, e.g. ``sol::readonly( &my_class::my_member_variable )`` in the appropriate place to use it. If someone tries to set it, it will throw an error. This can ONLY work on :doc:`usertypes<usertype>` and when you specifically set a member variable as a function and wrap it with this. It will NOT work anywhere else: doing so will invoke compiler errors.
-
-If you are looking to make a read-only table, you need to go through a bit of a complicated song and dance by overriding the ``__index`` metamethod. Here's a complete example on the way to do that using ``sol``:
-
-
-.. code-block:: cpp
- :caption: read-only.cpp
-
- #define SOL_CHECK_ARGUMENTS
- #include <sol.hpp>
-
- #include <iostream>
-
- struct object {
- void my_func() {
- std::cout << "hello\n";
- }
- };
-
- int deny(lua_State* L) {
- return luaL_error(L, "HAH! Deniiiiied!");
- }
-
- int main() {
- sol::state lua;
- lua.open_libraries(sol::lib::base);
-
- object my_obj;
-
- sol::table obj_table = lua.create_named_table("object");
-
- sol::table obj_metatable = lua.create_table_with();
- obj_metatable.set_function("my_func", &object::my_func, &my_obj);
- // Set whatever else you need to
- // on the obj_metatable,
- // not on the obj_table itself!
-
- // Properly self-index metatable to block things
- obj_metatable[sol::meta_function::new_index] = deny;
- obj_metatable[sol::meta_function::index] = obj_metatable;
-
- // Set it on the actual table
- obj_table[sol::metatable_key] = obj_metatable;
-
- try {
- lua.script(R"(
- print(object.my_func)
- object["my_func"] = 24
- print(object.my_func)
- )");
- }
- catch (const std::exception& e) {
- std::cout << e.what() << std::endl;
- }
- return 0;
- }
-
-It is a verbose example, but it explains everything. Because the process is a bit involved and can have unexpected consequences for users that make their own tables, making read-only tables is something that we ask the users to do themselves with the above code, as getting the semantics right for the dozens of use cases would be tremendously difficult.
diff --git a/3rdparty/sol2/docs/source/api/reference.rst b/3rdparty/sol2/docs/source/api/reference.rst
deleted file mode 100644
index 57869de7db0..00000000000
--- a/3rdparty/sol2/docs/source/api/reference.rst
+++ /dev/null
@@ -1,78 +0,0 @@
-reference
-=========
-general purpose reference to Lua object in registry
----------------------------------------------------
-
-.. code-block:: cpp
- :caption: reference
-
- class reference;
-
-This type keeps around a reference to something that was on the stack and places it in the Lua registry. It is the backbone for all things that reference items on the stack and needs to keep them around beyond their appearance and lifetime on said Lua stack. Its progeny include :doc:`sol::coroutine<coroutine>`, :doc:`sol::function<function>`, :doc:`sol::protected_function<protected_function>`, :doc:`sol::object<object>`, :doc:`sol::table<table>`/:doc:`sol::global_table<table>`, :doc:`sol::thread<thread>`, and :doc:`sol::userdata<userdata>`.
-
-For all of these types, there's also a ``stack_{x}`` version of them, such as ``stack_table``
-
-
-members
--------
-
-.. code-block:: cpp
- :caption: constructor: reference
-
- reference(lua_State* L, int index = -1);
- reference(lua_State* L, ref_index index);
- template <typename Object>
- reference(Object&& o);
-
-The first constructor creates a reference from the Lua stack at the specified index, saving it into the metatable registry. The second attemtps to register something that already exists in the registry. The third attempts to reference a pre-existing object and create a reference to it. These constructors are exposed on all types that derive from ``sol::reference``, meaning that you can grab tables, functions, and coroutines from the registry, stack, or from other objects easily.
-
-.. code-block:: cpp
- :caption: function: push referred-to element from the stack
-
- int push() const noexcept;
-
-This function pushes the referred-to data onto the stack and returns how many things were pushed. Typically, it returns 1.
-
-.. code-block:: cpp
- :caption: function: reference value
-
- int registry_index() const noexcept;
-
-The value of the reference in the registry.
-
-.. code-block:: cpp
- :caption: functions: non-nil, non-null check
-
- bool valid () const noexcept;
- explicit operator bool () const noexcept;
-
-These functions check if the reference at ``T`` is valid: that is, if it is not :ref:`nil<nil>` and if it is not non-existing (doesn't refer to anything, including nil) reference. The explicit operator bool allows you to use it in the context of an ``if ( my_obj )`` context.
-
-.. code-block:: cpp
- :caption: function: retrieves the type
-
- type get_type() const noexcept;
-
-Gets the :doc:`sol::type<types>` of the reference; that is, the Lua reference.
-
-.. code-block:: cpp
- :caption: function: lua_State* of the reference
-
- lua_State* lua_state() const noexcept;
-
-Gets the ``lua_State*`` this reference exists in.
-
-
-non-members
------------
-
-.. code-block:: cpp
- :caption: functions: reference comparators
-
- bool operator==(const reference&, const reference&);
- bool operator!=(const reference&, const reference&);
-
-Compares two references using the Lua API's `lua_compare`_ for equality.
-
-
-.. _lua_compare: https://www.lua.org/manual/5.3/manual.html#lua_compare
diff --git a/3rdparty/sol2/docs/source/api/resolve.rst b/3rdparty/sol2/docs/source/api/resolve.rst
deleted file mode 100644
index b1ceffd0134..00000000000
--- a/3rdparty/sol2/docs/source/api/resolve.rst
+++ /dev/null
@@ -1,65 +0,0 @@
-resolve
-=======
-utility to pick overloaded C++ function calls
----------------------------------------------
-
-.. code-block:: cpp
- :caption: function: resolve C++ overload
-
- template <typename... Args, typename F>
- constexpr auto resolve( F f );
-
-``resolve`` is a function that is meant to help users pick a single function out of a group of overloaded functions in C++. It works for *both member and free functions* You can use it to pick overloads by specifying the signature as the first template argument. Given a collection of overloaded functions:
-
-.. code-block:: cpp
- :linenos:
-
- int overloaded(int x);
- int overloaded(int x, int y);
- int overloaded(int x, int y, int z);
-
- struct thing {
- int overloaded() const;
- int overloaded(int x);
- int overloaded(int x, int y);
- int overloaded(int x, int y, int z);
- };
-
-You can disambiguate them using ``resolve``:
-
-.. code-block:: cpp
- :linenos:
-
- auto one_argument_func = resolve<int(int)>( overloaded );
- auto two_argument_func = resolve<int(int, int)>( overloaded );
- auto three_argument_func = resolve<int(int, int, int)>( overloaded );
- auto member_three_argument_func = resolve<int(int, int, int)>( &thing::overloaded );
- auto member_zero_argument_const_func = resolve<int() const>( &thing::overloaded );
-
-It is *important* to note that ``const`` is placed at the end for when you desire const overloads. You will get compiler errors if you are not specific and do not properly disambiguate for const member functions. This resolution also becomes useful when setting functions on a :doc:`table<table>` or :doc:`state_view<state>`:
-
-.. code-block:: cpp
- :linenos:
-
- sol::state lua;
-
- lua.set_function("a", resolve<int(int)>( overloaded ) );
- lua.set_function("b", resolve<int(int, int)>( overloaded ));
- lua.set_function("c", resolve<int(int, int, int)>( overloaded ));
-
-
-It can also be used with :doc:`sol::c_call<c_call>`:
-
-.. code-block:: cpp
- :linenos:
-
- sol::state lua;
-
- auto f = sol::c_call<
- decltype(sol::resolve<int(int, int)>(&overloaded)),
- sol::resolve<int(int, int)>(&overloaded)
- >;
- lua.set_function("f", f);
-
- lua.script("f(1, 2)");
-
diff --git a/3rdparty/sol2/docs/source/api/simple_usertype.rst b/3rdparty/sol2/docs/source/api/simple_usertype.rst
deleted file mode 100644
index 0502e6b24ed..00000000000
--- a/3rdparty/sol2/docs/source/api/simple_usertype.rst
+++ /dev/null
@@ -1,33 +0,0 @@
-simple_usertype<T>
-==================
-structures and classes from C++ made available to Lua code (simpler)
---------------------------------------------------------------------
-
-
-This type is no different from :doc:`regular usertype<usertype>`, but allows much of its work to be done at runtime instead of compile-time. You can reduce compilation times from a plain `usertype` when you have an exceedingly bulky registration listing.
-
-You can set functions incrementally to reduce compile-time burden with ``simple_usertype`` as well, as shown in `this example`_. This means both adding incrementally during registration, and afterwards by adding items to the metatable at runtime.
-
-Some developers used ``simple_usertype`` in older versions to have variables automatically be functions. To achieve this behavior, wrap the desired variable into :doc:`sol::as_function<as_function>`.
-
-The performance `seems to be good enough`_ (see below graphs as well) to not warn about any implications of having to serialize things at runtime. You do run the risk of using (slightly?) more memory, since variables and functions need to be stored differently and separately from the metatable data itself like with a regular ``usertype``. The goal here was to avoid compiler complaints about too-large usertypes (some individuals needed to register 190+ functions, and the compiler choked from the templated implementation of ``usertype``). As of Sol 2.14, this implementation has been heavily refactored to allow for all the same syntax and uses of usertype to apply here, with no caveats/exceptions.
-
-
-.. image:: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua%20bench%20graph%20-%20member%20function%20calls%20(simple).png
- :target: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua%20bench%20graph%20-%20member%20function%20calls%20(simple).png
- :alt: bind several member functions to an object and call them in Lua code
-
-
-.. image:: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua%20bench%20graph%20-%20userdata%20variable%20access%20(simple).png
- :target: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua%20bench%20graph%20-%20userdata%20variable%20access%20(simple).png
- :alt: bind a member variable to an object and modify it with Lua code
-
-
-.. image:: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua%20bench%20graph%20-%20many%20userdata%20variables%20access%2C%20last%20registered%20(simple).png
- :target: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua%20bench%20graph%20-%20many%20userdata%20variables%20access%2C%20last%20registered%20(simple).png
- :alt: bind MANY member variables to an object and modify it with Lua code
-
-
-
-.. _seems to be good enough: https://github.com/ThePhD/sol2/issues/202#issuecomment-246767629
-.. _this example: https://github.com/ThePhD/sol2/blob/develop/examples/usertype_simple.cpp \ No newline at end of file
diff --git a/3rdparty/sol2/docs/source/api/stack.rst b/3rdparty/sol2/docs/source/api/stack.rst
deleted file mode 100644
index 0ebb2d2e40b..00000000000
--- a/3rdparty/sol2/docs/source/api/stack.rst
+++ /dev/null
@@ -1,199 +0,0 @@
-stack namespace
-===============
-the nitty-gritty core abstraction layer over Lua
-------------------------------------------------
-
-.. code-block:: cpp
-
- namespace stack
-
-If you find that the higher level abstractions are not meeting your needs, you may want to delve into the ``stack`` namespace to try and get more out of Sol. ``stack.hpp`` and the ``stack`` namespace define several utilities to work with Lua, including pushing / popping utilities, getters, type checkers, Lua call helpers and more. This namespace is not thoroughly documented as the majority of its interface is mercurial and subject to change between releases to either heavily boost performance or improve the Sol :doc:`api<api-top>`.
-
-There are, however, a few :ref:`template customization points<extension_points>` that you may use for your purposes and a handful of potentially handy functions. These may help if you're trying to slim down the code you have to write, or if you want to make your types behave differently throughout the Sol stack. Note that overriding the defaults **can** throw out many of the safety guarantees Sol provides: therefore, modify the :ref:`extension points<extension_points>` at your own discretion.
-
-structures
-----------
-
-.. code-block:: cpp
- :caption: struct: record
- :name: stack-record
-
- struct record {
- int last;
- int used;
-
- void use(int count);
- };
-
-This structure is for advanced usage with :ref:`stack::get<stack-get>` and :ref:`stack::check_get<stack-get>`. When overriding the customization points, it is important to call the ``use`` member function on this class with the amount of things you are pulling from the stack. ``used`` contains the total accumulation of items produced. ``last`` is the number of items gotten from the stack with the last operation (not necessarily popped from the stack). In all trivial cases for types, ``last == 1`` and ``used == 1`` after an operation; structures such as ``std::pair`` and ``std::tuple`` may pull more depending on the classes it contains.
-
-When overriding the :doc:`customization points<../tutorial/customization>`, please note that this structure should enable you to push multiple return values and get multiple return values to the stack, and thus be able to seamlessly pack/unpack return values from Lua into a single C++ struct, and vice-versa. This functionality is only recommended for people who need to customize the library further than the basics. It is also a good way to add support for the type and propose it back to the original library so that others may benefit from your work.
-
-Note that customizations can also be put up on a separate page here, if individuals decide to make in-depth custom ones for their framework or other places.
-
-members
--------
-
-.. code-block:: cpp
- :caption: function: get
- :name: stack-get
-
- template <typename T>
- auto get( lua_State* L, int index = -1 )
- template <typename T>
- auto get( lua_State* L, int index, record& tracking )
-
-Retrieves the value of the object at ``index`` in the stack. The return type varies based on ``T``: with primitive types, it is usually ``T``: for all unrecognized ``T``, it is generally a ``T&`` or whatever the extension point :ref:`stack::getter\<T><getter>` implementation returns. The type ``T`` has top-level ``const`` qualifiers and reference modifiers removed before being forwarded to the extension point :ref:`stack::getter\<T><getter>` struct. ``stack::get`` will default to forwarding all arguments to the :ref:`stack::check_get<stack-check-get>` function with a handler of ``type_panic`` to strongly alert for errors, if you ask for the :doc:`safety<../safety>`.
-
-`record`
-
-You may also retrieve an :doc:`sol::optional\<T><optional>` from this as well, to have it attempt to not throw errors when performing the get and the type is not correct.
-
-.. code-block:: cpp
- :caption: function: check
- :name: stack-check
-
- template <typename T>
- bool check( lua_State* L, int index = -1 )
-
- template <typename T, typename Handler>
- bool check( lua_State* L, int index, Handler&& handler )
-
-Checks if the object at ``index`` is of type ``T``. If it is not, it will call the ``handler`` function with ``lua_State*``, ``int index``, ``type`` expected, and ``type`` actual as arguments.
-
-.. code-block:: cpp
- :caption: function: check_get
- :name: stack-check-get
-
- template <typename T>
- auto check_get( lua_State* L, int index = -1 )
- template <typename T, typename Handler>
- auto check_get( lua_State* L, int index, Handler&& handler, record& tracking )
-
-Retrieves the value of the object at ``index`` in the stack, but does so safely. It returns an ``optional<U>``, where ``U`` in this case is the return type deduced from ``stack::get<T>``. This allows a person to properly check if the type they're getting is what they actually want, and gracefully handle errors when working with the stack if they so choose to. You can define ``SOL_CHECK_ARGUMENTS`` to turn on additional :doc:`safety<../safety>`, in which ``stack::get`` will default to calling this version of the function with a handler of ``type_panic`` to strongly alert for errors and help you track bugs if you suspect something might be going wrong in your system.
-
-.. code-block:: cpp
- :caption: function: push
- :name: stack-push
-
- // push T inferred from call site, pass args... through to extension point
- template <typename T, typename... Args>
- int push( lua_State* L, T&& item, Args&&... args )
-
- // push T that is explicitly specified, pass args... through to extension point
- template <typename T, typename Arg, typename... Args>
- int push( lua_State* L, Arg&& arg, Args&&... args )
-
- // recursively call the the above "push" with T inferred, one for each argument
- template <typename... Args>
- int multi_push( lua_State* L, Args&&... args )
-
-Based on how it is called, pushes a variable amount of objects onto the stack. in 99% of cases, returns for 1 object pushed onto the stack. For the case of a ``std::tuple<...>``, it recursively pushes each object contained inside the tuple, from left to right, resulting in a variable number of things pushed onto the stack (this enables multi-valued returns when binding a C++ function to a Lua). Can be called with ``sol::stack::push<T>( L, args... )`` to have arguments different from the type that wants to be pushed, or ``sol::stack::push( L, arg, args... )`` where ``T`` will be inferred from ``arg``. The final form of this function is ``sol::stack::multi_push``, which will call one ``sol::stack::push`` for each argument. The ``T`` that describes what to push is first sanitized by removing top-level ``const`` qualifiers and reference qualifiers before being forwarded to the extension point :ref:`stack::pusher\<T><pusher>` struct.
-
-.. code-block:: cpp
- :caption: function: set_field
-
- template <bool global = false, typename Key, typename Value>
- void set_field( lua_State* L, Key&& k, Value&& v );
-
- template <bool global = false, typename Key, typename Value>
- void set_field( lua_State* L, Key&& k, Value&& v, int objectindex);
-
-Sets the field referenced by the key ``k`` to the given value ``v``, by pushing the key onto the stack, pushing the value onto the stack, and then doing the equivalent of ``lua_setfield`` for the object at the given ``objectindex``. Performs optimizations and calls faster verions of the function if the type of ``Key`` is considered a c-style string and/or if its also marked by the templated ``global`` argument to be a global.
-
-.. code-block:: cpp
- :caption: function: get_field
-
- template <bool global = false, typename Key>
- void get_field( lua_State* L, Key&& k [, int objectindex] );
-
-Gets the field referenced by the key ``k``, by pushing the key onto the stack, and then doing the equivalent of ``lua_getfield``. Performs optimizations and calls faster verions of the function if the type of ``Key`` is considered a c-style string and/or if its also marked by the templated ``global`` argument to be a global.
-
-This function leaves the retrieved value on the stack.
-
-.. code-block:: cpp
- :caption: function: probe_get_field
- :name: stack-probe-get-field
-
- template <bool global = false, typename Key>
- probe probe_get_field( lua_State* L, Key&& k [, int objectindex] );
-
-Gets the field referenced by the key ``k``, by pushing the key onto the stack, and then doing the equivalent of ``lua_getfield``. Performs optimizations and calls faster verions of the function if the type of ``Key`` is considered a c-style string and/or if its also marked by the templated ``global`` argument to be a global. Furthermore, it does this safely by only going in as many levels deep as is possible: if the returned value is not something that can be indexed into, then traversal queries with ``std::tuple``/``std::pair`` will stop early and return probing information with the :ref:`probe struct<stack-probe-struct>`.
-
-This function leaves the retrieved value on the stack.
-
-.. code-block:: cpp
- :caption: struct: probe
- :name: stack-probe-struct
-
- struct probe {
- bool success;
- int levels;
-
- probe(bool s, int l);
- operator bool() const;
- };
-
-This struct is used for showing whether or not a :ref:`probing get_field<stack-probe-get-field>` was successful or not.
-
-.. _extension_points:
-
-objects (extension points)
---------------------------
-
-You can customize the way Sol handles different structures and classes by following the information provided in the :doc:`adding your own types<../tutorial/customization>`.
-
-Below is more extensive information for the curious.
-
-The structs below are already overriden for a handful of types. If you try to mess with them for the types ``sol`` has already overriden them for, you're in for a world of thick template error traces and headaches. Overriding them for your own user defined types should be just fine, however.
-
-.. code-block:: cpp
- :caption: struct: getter
- :name: getter
-
- template <typename T, typename = void>
- struct getter {
- static T get (lua_State* L, int index, record& tracking) {
- // ...
- return // T, or something related to T.
- }
- };
-
-This is an SFINAE-friendly struct that is meant to expose static function ``get`` that returns a ``T``, or something convertible to it. The default implementation assumes ``T`` is a usertype and pulls out a userdata from Lua before attempting to cast it to the desired ``T``. There are implementations for getting numbers (``std::is_floating``, ``std::is_integral``-matching types), getting ``std::string`` and ``const char*``, getting raw userdata with :doc:`userdata_value<types>` and anything as upvalues with :doc:`upvalue_index<types>`, getting raw `lua_CFunction`_ s, and finally pulling out Lua functions into ``std::function<R(Args...)>``. It is also defined for anything that derives from :doc:`sol::reference<reference>`. It also has a special implementation for the 2 standard library smart pointers (see :doc:`usertype memory<usertype_memory>`).
-
-.. code-block:: cpp
- :caption: struct: pusher
- :name: pusher
-
- template <typename X, typename = void>
- struct pusher {
- template <typename T>
- static int push ( lua_State* L, T&&, ... ) {
- // can optionally take more than just 1 argument
- // ...
- return // number of things pushed onto the stack
- }
- };
-
-This is an SFINAE-friendly struct that is meant to expose static function ``push`` that returns the number of things pushed onto the stack. The default implementation assumes ``T`` is a usertype and pushes a userdata into Lua with a :ref:`usertype_traits\<T><usertype-traits>` metatable associated with it. There are implementations for pushing numbers (``std::is_floating``, ``std::is_integral``-matching types), getting ``std::string`` and ``const char*``, getting raw userdata with :doc:`userdata<types>` and raw upvalues with :doc:`upvalue<types>`, getting raw `lua_CFunction`_ s, and finally pulling out Lua functions into ``sol::function``. It is also defined for anything that derives from :doc:`sol::reference<reference>`. It also has a special implementation for the 2 standard library smart pointers (see :doc:`usertype memory<usertype_memory>`).
-
-.. code-block:: cpp
- :caption: struct: checker
- :name: checker
-
- template <typename T, type expected = lua_type_of<T>, typename = void>
- struct checker {
- template <typename Handler>
- static bool check ( lua_State* L, int index, Handler&& handler, record& tracking ) {
- // if the object in the Lua stack at index is a T, return true
- if ( ... ) return true;
- // otherwise, call the handler function,
- // with the required 4 arguments, then return false
- handler(L, index, expected, indextype);
- return false;
- }
- };
-
-This is an SFINAE-friendly struct that is meant to expose static function ``check`` that returns the number of things pushed onto the stack. The default implementation simply checks whether the expected type passed in through the template is equal to the type of the object at the specified index in the Lua stack. The default implementation for types which are considered ``userdata`` go through a myriad of checks to support checking if a type is *actually* of type ``T`` or if its the base class of what it actually stored as a userdata in that index. Down-casting from a base class to a more derived type is, unfortunately, impossible to do.
-
-.. _lua_CFunction: http://www.Lua.org/manual/5.3/manual.html#lua_CFunction \ No newline at end of file
diff --git a/3rdparty/sol2/docs/source/api/stack_reference.rst b/3rdparty/sol2/docs/source/api/stack_reference.rst
deleted file mode 100644
index db5359d11aa..00000000000
--- a/3rdparty/sol2/docs/source/api/stack_reference.rst
+++ /dev/null
@@ -1,8 +0,0 @@
-stack_reference
-===============
-zero-overhead object on the stack
----------------------------------
-
-When you work with a :doc:`sol::reference<reference>`, the object gotten from the stack has a reference to it made in the registry, keeping it alive. If you want to work with the Lua stack directly without having any additional references made, ``sol::stack_reference`` is for you. Its API is identical to ``sol::reference`` in every way, except it contains a ``int stack_index()`` member function that allows you to retrieve the stack index.
-
-All of the base types have ``stack`` versions of themselves, and the APIs are identical to their non-stack forms. This includes :doc:`sol::stack_table<table>`, :doc:`sol::stack_function<function>`, :doc:`sol::stack_protected_function<protected_function>`, :doc:`sol::stack_(light\_)userdata<userdata>` and :doc:`sol::stack_object<object>`. \ No newline at end of file
diff --git a/3rdparty/sol2/docs/source/api/state.rst b/3rdparty/sol2/docs/source/api/state.rst
deleted file mode 100644
index b1b17a3cc67..00000000000
--- a/3rdparty/sol2/docs/source/api/state.rst
+++ /dev/null
@@ -1,150 +0,0 @@
-state
-=====
-owning and non-owning state holders for registry and globals
-------------------------------------------------------------
-
-.. code-block:: cpp
-
- class state_view;
-
- class state : state_view, std::unique_ptr<lua_State*, deleter>;
-
-The most important class here is ``state_view``. This structure takes a ``lua_State*`` that was already created and gives you simple, easy access to Lua's interfaces without taking ownership. ``state`` derives from ``state_view``, inheriting all of this functionality, but has the additional purpose of creating a fresh ``lua_State*`` and managing its lifetime for you in the default constructor.
-
-The majority of the members between ``state_view`` and :doc:`sol::table<table>` are identical, with added for this higher-level type. Therefore, all of the examples and notes in :doc:`sol::table<table>` apply here as well.
-
-enumerations
-------------
-
-.. code-block:: cpp
- :caption: in-lua libraries
- :name: lib-enum
-
- enum class lib : char {
- base,
- package,
- coroutine,
- string,
- os,
- math,
- table,
- debug,
- bit32,
- io,
- ffi,
- jit,
- count // do not use
- };
-
-This enumeration details the various base libraries that come with Lua. See the `standard lua libraries`_ for details about the various standard libraries.
-
-
-members
--------
-
-.. code-block:: cpp
- :caption: function: open standard libraries/modules
- :name: open-libraries
-
- template<typename... Args>
- void open_libraries(Args&&... args);
-
-This function takes a number of :ref:`sol::lib<lib-enum>` as arguments and opens up the associated Lua core libraries.
-
-.. code-block:: cpp
- :caption: function: script / script_file
- :name: state-script-function
-
- sol::function_result script(const std::string& code);
- sol::function_result script_file(const std::string& filename);
-
-These functions run the desired blob of either code that is in a string, or code that comes from a filename, on the ``lua_State*``. It will not run isolated: any scripts or code run will affect code in the ``lua_State*`` the object uses as well (unless ``local`` is applied to a variable declaration, as specified by the Lua language). Code ran in this fashion is not isolated. If you need isolation, consider creating a new state or traditional Lua sandboxing techniques.
-
-If your script returns a value, you can capture it from the returned :ref:`function_result<function-result>`.
-
-.. code-block:: cpp
- :caption: function: require / require_file
- :name: state-require-function
-
- sol::object require(const std::string& key, lua_CFunction open_function, bool create_global = true);
- sol::object require_script(const std::string& key, const std::string& code, bool create_global = true);
- sol::object require_file(const std::string& key, const std::string& file, bool create_global = true);
-
-These functions play a role similar to `luaL_requiref`_ except that they make this functionality available for loading a one-time script or a single file. The code here checks if a module has already been loaded, and if it has not, will either load / execute the file or execute the string of code passed in. If ``create_global`` is set to true, it will also link the name ``key`` to the result returned from the open function, the code or the file. Regardless or whether a fresh load happens or not, the returned module is given as a single :doc:`sol::object<object>` for you to use as you see fit.
-
-Thanks to `Eric (EToreo) for the suggestion on this one`_!
-
-.. code-block:: cpp
- :caption: function: load / load_file
- :name: state-load-code
-
- sol::load_result load(const std::string& code);
- sol::load_result load_file(const std::string& filename);
-
-These functions *load* the desired blob of either code that is in a string, or code that comes from a filename, on the ``lua_State*``. It will not run: it returns a ``load_result`` proxy that can be called to actually run the code, turned into a ``sol::function``, a ``sol::protected_function``, or some other abstraction. If it is called, it will run on the object's current ``lua_State*``: it is not isolated. If you need isolation, consider creating a new state or traditional Lua sandboxing techniques.
-
-.. code-block:: cpp
- :caption: function: do_string / do_file
- :name: state-do-code
-
- sol::protected_function_result do_string(const std::string& code);
- sol::protected_function_result do_file(const std::string& filename);
-
-These functions *loads and performs* the desired blob of either code that is in a string, or code that comes from a filename, on the ``lua_State*``. It *will* run, and then return a ``protected_function_result`` proxy that can be examined for either an error or the return value.
-
-.. code-block:: cpp
- :caption: function: global table / registry table
-
- sol::global_table globals() const;
- sol::table registry() const;
-
-Get either the global table or the Lua registry as a :doc:`sol::table<table>`, which allows you to modify either of them directly. Note that getting the global table from a ``state``/``state_view`` is usually unnecessary as it has all the exact same functions as a :doc:`sol::table<table>` anyhow.
-
-
-.. code-block:: cpp
- :caption: function: set_panic
- :name: set-panic
-
- void set_panic(lua_CFunction panic);
-
-Overrides the panic function Lua calls when something unrecoverable or unexpected happens in the Lua VM. Must be a function of the that matches the ``int(lua_State*)`` function signature.
-
-
-.. code-block:: cpp
- :caption: function: memory_used
- :name: memory-used
-
- std::size_t memory_used() const;
-
-Returns the amount of memory used *in bytes* by the Lua State.
-
-
-.. code-block:: cpp
- :caption: function: collect_garbage
- :name: collect-garbage
-
- void collect_garbage();
-
-Attempts to run the garbage collector. Note that this is subject to the same rules as the Lua API's collect_garbage function: memory may or may not be freed, depending on dangling references or other things, so make sure you don't have tables or other stack-referencing items currently alive or referenced that you want to be collected.
-
-
-.. code-block:: cpp
- :caption: function: make a table
-
- sol::table create_table(int narr = 0, int nrec = 0);
- template <typename Key, typename Value, typename... Args>
- sol::table create_table(int narr, int nrec, Key&& key, Value&& value, Args&&... args);
-
-
- template <typename... Args>
- sol::table create_table_with(Args&&... args);
-
- static sol::table create_table(lua_State* L, int narr = 0, int nrec = 0);
- template <typename Key, typename Value, typename... Args>
- static sol::table create_table(lua_State* L, int narr, int nrec, Key&& key, Value&& value, Args&&... args);
-
-Creates a table. Forwards its arguments to :ref:`table::create<table-create>`.
-
-.. _standard lua libraries: http://www.lua.org/manual/5.3/manual.html#6
-.. _luaL_requiref: https://www.lua.org/manual/5.3/manual.html#luaL_requiref
-.. _Eric (EToreo) for the suggestion on this one: https://github.com/ThePhD/sol2/issues/90 \ No newline at end of file
diff --git a/3rdparty/sol2/docs/source/api/table.rst b/3rdparty/sol2/docs/source/api/table.rst
deleted file mode 100644
index 25197b126c7..00000000000
--- a/3rdparty/sol2/docs/source/api/table.rst
+++ /dev/null
@@ -1,216 +0,0 @@
-table
-=====
-a representation of a Lua (meta)table
--------------------------------------
-
-.. code-block:: cpp
-
- template <bool global>
- class table_core;
-
- typedef table_core<false> table;
- typedef table_core<true> global_table;
-
-``sol::table`` is an extremely efficient manipulator of state that brings most of the magic of the Sol abstraction. Capable of doing multiple sets at once, multiple gets into a ``std::tuple``, being indexed into using ``[key]`` syntax and setting keys with a similar syntax (see: :doc:`here<proxy>`), ``sol::table`` is the corner of the interaction between Lua and C++.
-
-There are two kinds of tables: the global table and non-global tables: however, both have the exact same interface and all ``sol::global_table`` s are convertible to regular ``sol::table`` s.
-
-Tables are the core of Lua, and they are very much the core of Sol.
-
-
-members
--------
-
-.. code-block:: cpp
- :caption: constructor: table
-
- table(lua_State* L, int index = -1);
-
-Takes a table from the Lua stack at the specified index and allows a person to use all of the abstractions therein.
-
-.. code-block:: cpp
- :caption: function: get / traversing get
-
- template<typename... Args, typename... Keys>
- decltype(auto) get(Keys&&... keys) const;
-
- template<typename T, typename... Keys>
- decltype(auto) traverse_get(Keys&&... keys) const;
-
- template<typename T, typename Key>
- decltype(auto) get_or(Key&& key, T&& otherwise) const;
-
- template<typename T, typename Key, typename D>
- decltype(auto) get_or(Key&& key, D&& otherwise) const;
-
-
-These functions retrieve items from the table. The first one (``get``) can pull out *multiple* values, 1 for each key value passed into the function. In the case of multiple return values, it is returned in a ``std::tuple<Args...>``. It is similar to doing ``return table["a"], table["b"], table["c"]``. Because it returns a ``std::tuple``, you can use ``std::tie``/``std::make_tuple`` on a multi-get to retrieve all of the necessary variables. The second one (``traverse_get``) pulls out a *single* value, using each successive key provided to do another lookup into the last. It is similar to doing ``x = table["a"]["b"]["c"][...]``.
-
-If the keys within nested queries try to traverse into a table that doesn't exist, the second lookup into the nil-returned variable and belong will cause a panic to be fired by the lua C API. If you need to check for keys, check with ``auto x = table.get<sol::optional<int>>( std::tie("a", "b", "c" ) );``, and then use the :doc:`optional<optional>` interface to check for errors. As a short-hand, easy method for returning a default if a value doesn't exist, you can use ``get_or`` instead.
-
-.. code-block:: cpp
- :caption: function: set / traversing set
- :name: set-value
-
- template<typename... Args>
- table& set(Args&&... args);
-
- template<typename... Args>
- table& traverse_set(Args&&... args);
-
-These functions set items into the table. The first one (``set``) can set *multiple* values, in the form ``key_a, value_a, key_b, value_b, ...``. It is similar to ``table[key_a] = value_a; table[key_b] = value_b, ...``. The second one (``traverse_set``) sets a *single* value, using all but the last argument as keys to do another lookup into the value retrieved prior to it. It is equivalent to ``table[key_a][key_b][...] = value;``.
-
-.. note::
-
- Value semantics are applied to all set operations. If you do not ``std::ref( obj )`` or specifically make a pointer with ``std::addressof( obj )`` or ``&obj``, it will copy / move. This is different from how :doc:`sol::function<function>` behaves with its call operator.
-
-.. code-block:: cpp
- :caption: function: set a function with the specified key into lua
- :name: set-function
-
- template<typename Key, typename Fx>
- state_view& set_function(Key&& key, Fx&& fx, [...]);
-
-Sets the desired function to the specified key value. Note that it also allows for passing a member function plus a member object or just a single member function: however, using a lambda is almost always better when you want to bind a member function + class instance to a single function call in Lua.
-
-.. code-block:: cpp
- :caption: function: add
-
- template<typename... Args>
- table& add(Args&&... args);
-
-This function appends a value to a table. The definition of appends here is only well-defined for a table which has a perfectly sequential (and integral) ordering of numeric keys with associated non-null values (the same requirement for the :ref:`size<size-function>` function). Otherwise, this falls to the implementation-defined behavior of your Lua VM, whereupon is may add keys into empty 'holes' in the array (e.g., the first empty non-sequential integer key it gets to from ``size``) or perhaps at the very "end" of the "array". Do yourself the favor of making sure your keys are sequential.
-
-Each argument is appended to the list one at a time.
-
-.. code-block:: cpp
- :caption: function: size
- :name: size-function
-
- std::size_t size() const;
-
-This function returns the size of a table. It is only well-defined in the case of a Lua table which has a perfectly sequential (and integral) ordering of numeric keys with associated non-null values.
-
-.. code-block:: cpp
- :caption: function: setting a usertype
- :name: new-usertype
-
- template<typename Class, typename... Args>
- table& new_usertype(const std::string& name, Args&&... args);
- template<typename Class, typename CTor0, typename... CTor, typename... Args>
- table& new_usertype(const std::string& name, Args&&... args);
- template<typename Class, typename... CArgs, typename... Args>
- table& new_usertype(const std::string& name, constructors<CArgs...> ctor, Args&&... args);
-
-This class of functions creates a new :doc:`usertype<usertype>` with the specified arguments, providing a few extra details for constructors. After creating a usertype with the specified argument, it passes it to :ref:`set_usertype<set_usertype>`.
-
-.. code-block:: cpp
- :caption: function: setting a simple usertype
- :name: new-simple-usertype
-
- template<typename Class, typename... Args>
- table& new_simple_usertype(const std::string& name, Args&&... args);
- template<typename Class, typename CTor0, typename... CTor, typename... Args>
- table& new_simple_usertype(const std::string& name, Args&&... args);
- template<typename Class, typename... CArgs, typename... Args>
- table& new_simple_usertype(const std::string& name, constructors<CArgs...> ctor, Args&&... args);
-
-This class of functions creates a new :doc:`simple usertype<simple_usertype>` with the specified arguments, providing a few extra details for constructors and passing the ``sol::simple`` tag as well. After creating a usertype with the specified argument, it passes it to :ref:`set_usertype<set_usertype>`.
-
-.. code-block:: cpp
- :caption: function: creating an enum
- :name: new-enum
-
- template<bool read_only = true, typename... Args>
- basic_table_core& new_enum(const std::string& name, Args&&... args);
-
-Use this function to create an enumeration type in Lua. By default, the enum will be made read-only, which creates a tiny performance hit to make the values stored in this table behave exactly like a read-only enumeration in C++. If you plan on changing the enum values in Lua, set the ``read_only`` template parameter in your ``new_enum`` call to false. The arguments are expected to come in ``key, value, key, value, ...`` list.
-
-.. _set_usertype:
-
-.. code-block:: cpp
- :caption: function: setting a pre-created usertype
- :name: set-usertype
-
- template<typename T>
- table& set_usertype(usertype<T>& user);
- template<typename Key, typename T>
- table& set_usertype(Key&& key, usertype<T>& user);
-
-Sets a previously created usertype with the specified ``key`` into the table. Note that if you do not specify a key, the implementation falls back to setting the usertype with a ``key`` of ``usertype_traits<T>::name``, which is an implementation-defined name that tends to be of the form ``{namespace_name 1}_[{namespace_name 2 ...}_{class name}``.
-
-.. code-block:: cpp
- :caption: function: begin / end for iteration
- :name: table-iterators
-
- table_iterator begin () const;
- table_iterator end() const;
- table_iterator cbegin() const;
- table_iterator cend() const;
-
-Provides (what can barely be called) `input iterators`_ for a table. This allows tables to work with single-pass, input-only algorithms (like ``std::for_each``). Note that manually getting an iterator from ``.begin()`` without a ``.end()`` or using postfix incrementation (``++mytable.begin()``) will lead to poor results. The Lua stack is manipulated by an iterator and thusly not performing the full iteration once you start is liable to ruin either the next iteration or break other things subtly. Use a C++11 ranged for loop, ``std::for_each``, or other algorithims which pass over the entire collection at least once and let the iterators fall out of scope.
-
-.. _iteration_note:
-.. warning::
-
- The iterators you use to walk through a ``sol::table`` are NOT guaranteed to iterate in numeric order, or ANY kind of order. They may iterate backwards, forwards, in the style of cuckoo-hashing, by accumulating a visited list while calling ``rand()`` to find the next target, or some other crazy scheme. Now, no implementation would be crazy, but it is behavior specifically left undefined because there are many ways that your Lua package can implement the table type.
-
- Iteration order is NOT something you should rely on. If you want to figure out the length of a table, call the length operation (``int count = mytable.size();`` using the sol API) and then iterate from ``1`` to ``count`` (inclusive of the value of count, because Lua expects iteration to work in the range of ``[1, count]``). This will save you some headaches in the future when the implementation decides not to iterate in numeric order.
-
-
-.. code-block:: cpp
- :caption: function: iteration with a function
- :name: table-for-each
-
- template <typename Fx>
- void for_each(Fx&& fx);
-
-A functional ``for_each`` loop that calls the desired function. The passed in function must take either ``sol::object key, sol::object value`` or take a ``std::pair<sol::object, sol::object> key_value_pair``. This version can be a bit safer as allows the implementation to definitively pop the key/value off the Lua stack after each call of the function.
-
-.. code-block:: cpp
- :caption: function: operator[] access
-
- template<typename T>
- proxy<table&, T> operator[](T&& key);
- template<typename T>
- proxy<const table&, T> operator[](T&& key) const;
-
-Generates a :doc:`proxy<proxy>` that is templated on the table type and the key type. Enables lookup of items and their implicit conversion to a desired type.
-
-.. code-block:: cpp
- :caption: function: create a table with defaults
- :name: table-create
-
- table create(int narr = 0, int nrec = 0);
- template <typename Key, typename Value, typename... Args>
- table create(int narr, int nrec, Key&& key, Value&& value, Args&&... args);
-
- static table create(lua_State* L, int narr = 0, int nrec = 0);
- template <typename Key, typename Value, typename... Args>
- static table create(lua_State* L, int narr, int nrec, Key&& key, Value&& value, Args&&... args);
-
-Creates a table, optionally with the specified values pre-set into the table. If ``narr`` or ``nrec`` are 0, then compile-time shenanigans are used to guess the amount of array entries (e.g., integer keys) and the amount of hashable entries (e.g., all other entries).
-
-.. code-block:: cpp
- :caption: function: create a table with compile-time defaults assumed
- :name: table-create-with
-
- template <typename... Args>
- table create_with(Args&&... args);
- template <typename... Args>
- static table create_with(lua_State* L, Args&&... args);
-
-
-Creates a table, optionally with the specified values pre-set into the table. It checks every 2nd argument (the keys) and generates hints for how many array or map-style entries will be placed into the table.
-
-.. code-block:: cpp
- :caption: function: create a named table with compile-time defaults assumed
- :name: table-create-named
-
- template <typename Name, typename... Args>
- table create_named(Name&& name, Args&&... args);
-
-
-Creates a table, optionally with the specified values pre-set into the table, and sets it as the key ``name`` in the table.
-
-.. _input iterators: http://en.cppreference.com/w/cpp/concept/InputIterator \ No newline at end of file
diff --git a/3rdparty/sol2/docs/source/api/this_state.rst b/3rdparty/sol2/docs/source/api/this_state.rst
deleted file mode 100644
index c4c6b3b7f75..00000000000
--- a/3rdparty/sol2/docs/source/api/this_state.rst
+++ /dev/null
@@ -1,31 +0,0 @@
-this_state
-==========
-transparent state argument for the current state
-------------------------------------------------
-
-.. code-block:: cpp
-
- struct this_state;
-
-This class is a transparent type that is meant to be gotten in functions to get the current lua state a bound function or usertype method is being called from. It does not actually retrieve anything from lua nor does it increment the argument count, making it "invisible" to function calls in lua and calls through ``std::function<...>`` and :doc:`sol::function<function>` on this type. It can be put in any position in the argument list of a function:
-
-.. code-block:: cpp
- :linenos:
-
- sol::state lua;
-
- lua.set_function("bark", []( sol::this_state s, int a, int b ){
- lua_State* L = s; // current state
- return a + b + lua_gettop(L);
- });
-
- lua.script("first = bark(2, 2)"); // only takes 2 arguments, NOT 3
-
- // Can be at the end, too, or in the middle: doesn't matter
- lua.set_function("bark", []( int a, int b, sol::this_state s ){
- lua_State* L = s; // current state
- return a + b + lua_gettop(L);
- });
-
- lua.script("second = bark(2, 2)"); // only takes 2 arguments
- \ No newline at end of file
diff --git a/3rdparty/sol2/docs/source/api/thread.rst b/3rdparty/sol2/docs/source/api/thread.rst
deleted file mode 100644
index b7349d97efb..00000000000
--- a/3rdparty/sol2/docs/source/api/thread.rst
+++ /dev/null
@@ -1,80 +0,0 @@
-thread
-======
-a separate state that can contain and run functions
----------------------------------------------------
-
-.. code-block:: cpp
-
- class thread : public reference { /* ... */ };
-
-``sol::thread`` is a separate runnable part of the Lua VM that can be used to execute work separately from the main thread, such as with :doc:`coroutines<coroutine>`. To take a table or a coroutine and run it specifically on the ``sol::thread`` you either pulled out of lua or created, just get that function through the :ref:`state of the thread<thread_state>`
-
-.. note::
-
- A CPU thread is not always equivalent to a new thread in Lua: ``std::this_thread::get_id()`` can be the same for 2 callbacks that have 2 distinct Lua threads. In order to know which thread a callback was called in, hook into :doc:`sol::this_state<this_state>` from your Lua callback and then construct a ``sol::thread``, passing in the ``sol::this_state`` for both the first and last arguments. Then examine the results of the status and ``is_...`` calls below.
-
-free function
--------------
-
-.. code-block:: cpp
- :caption: function: main_thread
-
- main_thread(lua_State* current, lua_State* backup_if_bad_platform = nullptr);
-
-The function ``sol::main_thread( ... )`` retrieves the main thread of the application on Lua 5.2 and above *only*. It is designed for code that needs to be multithreading-aware (e.g., uses multiple :doc:`threads<thread>` and :doc:`coroutines<coroutine>`).
-
-.. warning::
-
- This code function will be present in Lua 5.1/LuaJIT, but only have proper behavior when given a single argument on Lua 5.2 and beyond. Lua 5.1 does not support retrieving the main thread from its registry, and therefore it is entirely suggested if you are writing cross-platform Lua code that you must store the main thread of your application in some global storage accessible somewhere. Then, pass this item into the ``sol::main_thread( possibly_thread_state, my_actual_main_state )`` and it will select that ``my_actual_main_state`` every time. If you are not going to use Lua 5.1 / LuaJIT, you can ignore the last parameter.
-
-
-members
--------
-
-.. code-block:: cpp
- :caption: constructor: thread
-
- thread(stack_reference r);
- thread(lua_State* L, int index = -1);
- thread(lua_State* L, lua_State* actual_thread);
-
-Takes a thread from the Lua stack at the specified index and allows a person to use all of the abstractions therein. It can also take an actual thread state to make a thread from that as well.
-
-.. code-block:: cpp
- :caption: function: view into thread_state()'s state
-
- state_view state() const;
-
-This retrieves the current state of the thread, producing a :doc:`state_view<state>` that can be manipulated like any other. :doc:`Coroutines<coroutine>` pulled from Lua using the thread's state will be run on that thread specifically.
-
-.. _thread_state:
-
-.. code-block:: cpp
- :caption: function: retrieve thread state object
-
- lua_State* thread_state () const;
-
-This function retrieves the ``lua_State*`` that represents the thread.
-
-.. code-block:: cpp
- :caption: current thread status
-
- thread_status status () const;
-
-Retrieves the :doc:`thread status<types>` that describes the current state of the thread.
-
-.. code-block:: cpp
- :caption: main thread status
-
- bool is_main_thread () const;
-
-Checks to see if the thread is the main Lua thread.
-
-.. code-block:: cpp
- :caption: function: thread creation
- :name: thread-create
-
- thread create();
- static thread create (lua_State* L);
-
-Creates a new thread from the given a ``lua_State*``. \ No newline at end of file
diff --git a/3rdparty/sol2/docs/source/api/tie.rst b/3rdparty/sol2/docs/source/api/tie.rst
deleted file mode 100644
index 080c8a1cc4f..00000000000
--- a/3rdparty/sol2/docs/source/api/tie.rst
+++ /dev/null
@@ -1,26 +0,0 @@
-tie
-===
-An improved version of ``std::tie``
------------------------------------
-
-`std::tie()`_ does not work well with :doc:`sol::function<function>`'s ``sol::function_result`` returns. Use ``sol::tie`` instead. Because they're both named `tie`, you'll need to be explicit when you use Sol's by naming it with the namespace (``sol::tie``), even with a ``using namespace sol;``. Here's an example:
-
-.. code-block:: cpp
-
- sol::state lua;
- lua.open_libraries(sol::lib::base);
-
- const auto& code = R"(
- function test()
- return 1, 2, 3
- end
- )";
- lua.script(code);
-
- int a, b, c;
- //std::tie(a, b, c) = lua["test"]();
- // will error: use the line below
- sol::tie(a, b, c) = lua["test"]();
-
-
-.. _std::tie(): http://en.cppreference.com/w/cpp/utility/tuple/tie
diff --git a/3rdparty/sol2/docs/source/api/types.rst b/3rdparty/sol2/docs/source/api/types.rst
deleted file mode 100644
index 9f761ee25b9..00000000000
--- a/3rdparty/sol2/docs/source/api/types.rst
+++ /dev/null
@@ -1,207 +0,0 @@
-types
-=====
-nil, lua_primitive type traits, and other fundamentals
-------------------------------------------------------
-
-The ``types.hpp`` header contains various fundamentals and utilities of Sol.
-
-
-enumerations
-------------
-
-.. code-block:: cpp
- :caption: syntax of a function called by Lua
- :name: call-syntax
-
- enum class call_syntax {
- dot = 0,
- colon = 1
- };
-
-This enumeration indicates the syntax a function was called with in a specific scenario. There are two ways to call a function: with ``obj:func_name( ... )`` or ``obj.func_name( ... );`` The first one passes "obj" as the first argument: the second one does not. In the case of usertypes, this is used to determine whether the call to a :doc:`constructor/initializer<usertype>` was called with a ``:`` or a ``.``, and not misalign the arguments.
-
-.. code-block:: cpp
- :caption: status of a Lua function call
- :name: call-status
-
- enum class call_status : int {
- ok = LUA_OK,
- yielded = LUA_YIELD,
- runtime = LUA_ERRRUN,
- memory = LUA_ERRMEM,
- handler = LUA_ERRERR,
- gc = LUA_ERRGCMM
- };
-
-This strongly-typed enumeration contains the errors potentially generated by a call to a :doc:`protected function<protected_function>` or a :doc:`coroutine<coroutine>`.
-
-.. code-block:: cpp
- :caption: status of a Lua thread
- :name: thread-status
-
- enum class thread_status : int {
- ok = LUA_OK,
- yielded = LUA_YIELD,
- runtime = LUA_ERRRUN,
- memory = LUA_ERRMEM,
- gc = LUA_ERRGCMM,
- handler = LUA_ERRERR,
- dead,
- };
-
-This enumeration contains the status of a thread. The ``thread_status::dead`` state is generated when the thread has nothing on its stack and it is not running anything.
-
-.. code-block:: cpp
- :caption: status of a Lua load operation
- :name: load-status
-
- enum class load_status : int {
- ok = LUA_OK,
- runtime = LUA_ERRSYNTAX,
- memory = LUA_ERRMEM,
- gc = LUA_ERRGCMM,
- file = LUA_ERRFILE,
- };
-
-This enumeration contains the status of a load operation from :ref:`state::load(_file)<state-load-code>`.
-
-.. code-block:: cpp
- :caption: type enumeration
- :name: type-enum
-
- enum class type : int {
- none = LUA_TNONE,
- nil = LUA_TNIL,
- string = LUA_TSTRING,
- number = LUA_TNUMBER,
- thread = LUA_TTHREAD,
- boolean = LUA_TBOOLEAN,
- function = LUA_TFUNCTION,
- userdata = LUA_TUSERDATA,
- lightuserdata = LUA_TLIGHTUSERDATA,
- table = LUA_TTABLE,
- poly = none | nil | string | number | thread |
- table | boolean | function | userdata | lightuserdata
- };
-
-The base types that Lua natively communicates in and understands. Note that "poly" isn't really a true type, it's just a symbol used in Sol for something whose type hasn't been checked (and you should almost never see it).
-
-
-type traits
------------
-
-.. code-block:: cpp
- :caption: lua_type_of trait
- :name: lua-type-of
-
- template <typename T>
- struct lua_type_of;
-
-This type trait maps a C++ type to a :ref:`type enumeration<type-enum>` value. The default value is ``type::userdata``.
-
-.. code-block:: cpp
- :caption: primitive checking traits
- :name: is-primitive
-
- template <typename T>
- struct is_lua_primitive;
-
- template <typename T>
- struct is_proxy_primitive;
-
-
-This trait is used by :doc:`proxy<proxy>` to know which types should be returned as references to internal Lua memory (e.g., ``userdata`` types) and which ones to return as values (strings, numbers, :doc:`references<reference>`). ``std::reference_wrapper``, ``std::tuple<...>`` are returned as values, but their contents can be references. The default value is false.
-
-special types
--------------
-
-.. code-block:: cpp
- :caption: nil
- :name: nil
-
- strunil_t {};
- const nil_t nil {};
- bool operator==(nil_t, nil_t);
- bool operator!=(nil_t, nil_t);
-
-``nil`` is a constant used to signify Lua's ``nil``, which is a type and object that something does not exist. It is comparable to itself, :doc:`sol::object<object>` and :doc:`proxy values<proxy>`.
-
-
-.. code-block:: cpp
- :caption: non_null
-
- template <typename T>
- struct non_null {};
-
-A tag type that, when used with :doc:`stack::get\<non_null\<T*>><stack>`, does not perform a ``nil`` check when attempting to retrieve the userdata pointer.
-
-
-.. code-block:: cpp
- :caption: type list
- :name: type-list
-
- template <typename... Args>
- struct types;
-
-A type list that, unlike ``std::tuple<Args...>``, does not actually contain anything. Used to indicate types and groups of types all over Sol.
-
-
-functions
----------
-
-.. code-block:: cpp
- :caption: type_of
-
- template<typename T>
- type type_of();
-
- type type_of(lua_State* L, int index);
-
-
-These functions get the type of a C++ type ``T``; or the type at the specified index on the Lua stack.
-
-.. code-block:: cpp
- :caption: type checking convenience functions
-
- int type_panic(lua_State* L, int index, type expected, type actual);
-
- int no_panic(lua_State*, int, type, type) noexcept;
-
- void type_error(lua_State* L, int expected, int actual);
-
- void type_error(lua_State* L, type expected, type actual);
-
- void type_assert(lua_State* L, int index, type expected, type actual);
-
- void type_assert(lua_State* L, int index, type expected);
-
-The purpose of these functions is to assert / throw / crash / error (or do nothing, as is the case with ``no_panic``). They're mostly used internally in the framework, but they're provided here if you should need them.
-
-.. code-block:: cpp
- :caption: type name retrieval
-
- std::string type_name(lua_State*L, type t);
-
-Gets the Lua-specified name of the :ref:`type<type-enum>`.
-
-structs
--------
-
-.. code-block:: cpp
-
- struct userdata_value {
- void* value;
- };
-
- struct light_userdata_value {
- void* value;
- };
-
- struct up_value_index {
- int index;
- };
-
-
-Types that differentiate between the two kinds of ``void*`` Lua hands back from its API: full userdata and light userdata, as well as a type that modifies the index passed to ``get`` to refer to `up values`_ These types can be used to trigger different underlying API calls to Lua when working with :doc:`stack<stack>` namespace and the ``push``/``get``/``pop``/``check`` functions.
-
-.. _up values: http://www.Lua.org/manual/5.3/manual.html#4.4 \ No newline at end of file
diff --git a/3rdparty/sol2/docs/source/api/unique_usertype_traits.rst b/3rdparty/sol2/docs/source/api/unique_usertype_traits.rst
deleted file mode 100644
index 4568b11349c..00000000000
--- a/3rdparty/sol2/docs/source/api/unique_usertype_traits.rst
+++ /dev/null
@@ -1,44 +0,0 @@
-unique_usertype_traits<T>
-=========================
-A trait for hooking special handles / pointers
-----------------------------------------------
-
-.. code-block:: cpp
- :caption: unique_usertype
- :name: unique-usertype
-
- template <typename T>
- struct unique_usertype_traits {
- typedef T type;
- typedef T actual_type;
- static const bool value = false;
-
- static bool is_null(const actual_type&) {...}
-
- static type* get (const actual_type&) {...}
- };
-
-This is a customization point for users who need to *work with special kinds of pointers/handles*. For generic customization, please review the :doc:`customization tutorial<../tutorial/customization>` A traits type for alerting the library that a certain type is to be pushed as a special userdata with special deletion / destruction semantics. It is already defined for ``std::unique_ptr<T, D>`` and ``std::shared_ptr<T>``. You can specialize this to get ``unique_usertype_traits`` semantics with your code, for example with ``boost::shared_ptr<T>`` like so:
-
-.. code-block:: cpp
-
- namespace sol {
- template <typename T>
- struct unique_usertype_traits<boost::shared_ptr<T>> {
- typedef T type;
- typedef boost::shared_ptr<T> actual_type;
- static const bool value = true;
-
- static bool is_null(const actual_type& value) {
- return value == nullptr;
- }
-
- static type* get (const actual_type& p) {
- return p.get();
- }
- }
- }
-
-This will allow the framework to properly handle ``boost::shared_ptr<T>``, with ref-counting and all. The `type` is the type that lua and sol will interact with, and will allow you to pull out a non-owning reference / pointer to the data when you just ask for a plain `T*` or `T&` or `T` using the getter functions and properties of Sol.
-
-Note that if ``is_null`` triggers, a ``nil`` value will be pushed into Sol. \ No newline at end of file
diff --git a/3rdparty/sol2/docs/source/api/user.rst b/3rdparty/sol2/docs/source/api/user.rst
deleted file mode 100644
index 9a0905d76bd..00000000000
--- a/3rdparty/sol2/docs/source/api/user.rst
+++ /dev/null
@@ -1,19 +0,0 @@
-light<T>/user<T>
-================
-Utility class for the cheapest form of (light) userdata
--------------------------------------------------------
-
-.. code-block:: cpp
-
- template <typename T>
- struct user;
-
- template <typename T>
- struct light;
-
-
-``sol::user<T>`` and ``sol::light<T>`` are two utility classes that do not participate in the full :doc:`sol::usertype\<T><usertype>` system. The goal of these classes is to provide the most minimal memory footprint and overhead for putting a single item and getting a single item out of Lua. ``sol::user<T>``, when pushed into Lua, will create a thin, unnamed metatable for that instance specifically which will be for calling its destructor. ``sol::light<T>`` specifically pushes a reference / pointer into Lua as a ``sol::type::lightuserdata``.
-
-If you feel that you do not need to have something participate in the full :doc:`usertype\<T><usertype>` system, use the utility functions ``sol::make_user( ... )`` and ``sol::make_light( ... )`` to create these types and store them into Lua. You can get them off the Lua stack / out of the Lua system by using the same retrieval techniques on ``get`` and ``operator[]`` on tables and with stack operations.
-
-Both have implicit conversion operators to ``T*`` and ``T&``, so you can set them immediately to their respective pointer and reference types if you need them. \ No newline at end of file
diff --git a/3rdparty/sol2/docs/source/api/userdata.rst b/3rdparty/sol2/docs/source/api/userdata.rst
deleted file mode 100644
index 6bc64791552..00000000000
--- a/3rdparty/sol2/docs/source/api/userdata.rst
+++ /dev/null
@@ -1,13 +0,0 @@
-userdata
-========
-reference to a userdata
------------------------
-
-.. code-block:: cpp
- :caption: (light\_)userdata reference
-
- class userdata : public reference;
-
- class light_userdata : public reference;
-
-These type is meant to hold a reference to a (light) userdata from Lua and make it easy to push an existing userdata onto the stack. It is essentially identical to :doc:`reference<reference>` in every way, just with a definitive C++ type.
diff --git a/3rdparty/sol2/docs/source/api/usertype.rst b/3rdparty/sol2/docs/source/api/usertype.rst
deleted file mode 100644
index bd941c527dc..00000000000
--- a/3rdparty/sol2/docs/source/api/usertype.rst
+++ /dev/null
@@ -1,330 +0,0 @@
-usertype<T>
-===========
-structures and classes from C++ made available to Lua code
-----------------------------------------------------------
-
-*Note: ``T`` refers to the type being turned into a usertype.*
-
-While other frameworks extend lua's syntax or create Data Structure Languages (DSLs) to create classes in lua, :doc:`Sol<../index>` instead offers the ability to generate easy bindings. These use metatables and userdata in lua for their implementation. If you need a usertype that is also extensible at runtime and has less compiler crunch to it, try the :doc:`simple version of this after reading these docs<simple_usertype>` Given this C++ class:
-
-.. code-block:: cpp
- :linenos:
-
- struct ship {
- int bullets = 20;
- int life = 100;
-
- bool shoot () {
- if (bullets > 0) {
- --bullets;
- // successfully shot
- return true;
- }
- // cannot shoot
- return false;
- }
-
- bool hurt (int by) {
- life -= by;
- // have we died?
- return life < 1;
- }
- };
-
-You can bind the it to Lua using the following C++ code:
-
-.. code-block:: cpp
- :linenos:
-
- sol::state lua;
-
- lua.new_usertype<ship>( "ship", // the name of the class, as you want it to be used in lua
- // List the member functions you wish to bind:
- // "name_of_item", &class_name::function_or_variable
- "shoot", &ship::shoot,
- "hurt", &ship::hurt,
- // bind variable types, too
- "life", &ship::bullets
- // names in lua don't have to be the same as C++,
- // but it probably helps if they're kept the same,
- // here we change it just to show its possible
- "bullet_count", &ship::bullets
- );
-
-
-Equivalently, you can also write:
-
-.. code-block:: cpp
- :linenos:
- :emphasize-lines: 4,12
-
- sol::state lua;
-
- // Use constructor directly
- usertype<ship> shiptype(
- "shoot", &ship::shoot,
- "hurt", &ship::hurt,
- "life", &ship::bullets
- "bullet_count", &ship::bullets
- );
-
- // set usertype explicitly, with the given name
- lua.set_usertype<ship>( "ship", shiptype );
-
- // shiptype is now a useless skeleton type, just let it destruct naturally and don't use it again.
-
-
-Note that here, because the C++ class is default-constructible, it will automatically generate a creation function that can be called in lua called "new" that takes no arguments. You can use it like this in lua code:
-
-.. code-block:: lua
- :linenos:
-
- fwoosh = ship.new()
- -- note the ":" that is there: this is mandatory for member function calls
- -- ":" means "pass self" in Lua
- local success = fwoosh:shoot()
- local is_dead = fwoosh:hurt(20)
- -- check if it works
- print(is_dead) -- the ship is not dead at this point
- print(fwoosh.life .. "life left") -- 80 life left
- print(fwoosh.bullet_count) -- 19
-
-
-There are more advanced use cases for how to create and use a usertype, which are all based on how to use its constructor (see below).
-
-enumerations
-------------
-
-.. _meta_function_enum:
-
-.. code-block:: cpp
- :caption: meta_function enumeration for names
- :linenos:
-
- enum class meta_function {
- construct,
- index,
- new_index,
- mode,
- call,
- metatable,
- to_string,
- length,
- unary_minus,
- addition,
- subtraction,
- multiplication,
- division,
- modulus,
- power_of,
- involution = power_of,
- concatenation,
- equal_to,
- less_than,
- less_than_or_equal_to,
- garbage_collect,
- call_function,
- };
-
-
-Use this enumeration to specify names in a manner friendlier than memorizing the special lua metamethod names for each of these. Each binds to a specific operation indicated by the descriptive name of the enum.
-
-members
--------
-
-.. code-block:: cpp
- :caption: function: usertype<T> constructor
- :name: usertype-constructor
-
- template<typename... Args>
- usertype<T>(Args&&... args);
-
-
-The constructor of usertype takes a variable number of arguments. It takes an even number of arguments (except in the case where the very first argument is passed as the :ref:`constructor list type<constructor>`). Names can either be strings, :ref:`special meta_function enumerations<meta_function_enum>`, or one of the special indicators for initializers.
-
-
-usertype constructor options
-++++++++++++++++++++++++++++
-
-If you don't specify any constructor options at all and the type is `default_constructible`_, Sol will generate a ``new`` for you. Otherwise, the following are special ways to handle the construction of a usertype:
-
-.. _constructor:
-
-* ``"{name}", constructors<Type-List-0, Type-List-1, ...>``
- - ``Type-List-N`` must be a ``sol::types<Args...>``, where ``Args...`` is a list of types that a constructor takes. Supports overloading by default
- - If you pass the ``constructors<...>`` argument first when constructing the usertype, then it will automatically be given a ``"{name}"`` of ``"new"``
-* ``"{name}", sol::initializers( func1, func2, ... )``
- - Used to handle *initializer functions* that need to initialize the memory itself (but not actually allocate the memory, since that comes as a userdata block from Lua)
- - Given one or more functions, provides an overloaded Lua function for creating a the specified type
- + The function must have the argument signature ``func( T*, Arguments... )`` or ``func( T&, Arguments... )``, where the pointer or reference will point to a place of allocated memory that has an uninitialized ``T``. Note that Lua controls the memory, so performing a ``new`` and setting it to the ``T*`` or ``T&`` is a bad idea: instead, use ``placement new`` to invoke a constructor, or deal with the memory exactly as you see fit
-* ``{anything}, sol::factories( func1, func2, ... )``
- - Used to indicate that a factory function (e.g., something that produces a ``std::unique_ptr<T, ...>``, ``std::shared_ptr<T>``, ``T``, or similar) will be creating the object type
- - Given one or more functions, provides an overloaded function for invoking
- + The functions can take any form and return anything, since they're just considered to be some plain function and no placement new or otherwise needs to be done. Results from this function will be pushed into Lua according to the same rules as everything else.
- + Can be used to stop the generation of a ``.new()`` default constructor since a ``sol::factories`` entry will be recognized as a constructor for the usertype
- + If this is not sufficient, see next 2 entries on how to specifically block a constructor
-* ``{anything}, sol::no_constructor``
- - Specifically tells Sol not to create a ``.new()`` if one is not specified and the type is default-constructible
- - ``{anything}`` should probably be ``"new"``, which will specifically block its creation and give a proper warning if someone calls ``new`` (otherwise it will just give a nil value error)
- - *Combine with the next one to only allow a factory function for your function type*
-* ``{anything}, {some_factory_function}``
- - Essentially binds whatever the function is to name ``{anything}``
- - When used WITH the ``sol::no_constructor`` option above (e.g. ``"new", sol::no_constructor`` and after that having ``"create", &my_creation_func``), one can remove typical constructor avenues and then only provide specific factory functions. Note that this combination is similar to using the ``sol::factories`` method mentioned earlier in this list. To control the destructor as well, see further below
-* ``sol::call_constructor, {valid constructor / initializer / factory}``
- - The purpose of this is to enable the syntax ``local v = my_class( 24 )`` and have that call a constructor; it has no other purpose
- - This is compatible with luabind, kaguya and other Lua library syntaxes and looks similar to C++ syntax, but the general consensus in Programming with Lua and other places is to use a function named ``new``
- - Note that with the ``sol::call_constructor`` key, a construct type above must be specified. A free function without it will pass in the metatable describing this object as the first argument without that distinction, which can cause strange runtime errors.
-
-usertype destructor options
-+++++++++++++++++++++++++++
-
-If you don't specify anything at all and the type is `destructible`_, then a destructor will be bound to the garbage collection metamethod. Otherwise, the following are special ways to handle the destruction of a usertype:
-
-* ``"__gc", sol::destructor( func )`` or ``sol::meta_function::garbage_collect, sol::destructor( func )``
- - Creates a custom destructor that takes an argument ``T*`` or ``T&`` and expects it to be destructed/destroyed. Note that lua controls the memory and thusly will deallocate the necessary space AFTER this function returns (e.g., do not call ``delete`` as that will attempt to deallocate memory you did not ``new``)
- - If you just want the default constructor, you can replace the second argument with ``sol::default_destructor``
- - The usertype will error / throw if you specify a destructor specifically but do not map it to ``sol::meta_function::gc`` or a string equivalent to ``"__gc"``
-
-usertype regular function options
-+++++++++++++++++++++++++++++++++
-
-If you don't specify anything at all and the type ``T`` supports ``operator <``, ``operator <=``, or ``operator==`` (``const`` or non-``const`` qualified):
-
-* for ``operator <`` and ``operator <=``
- - These two ``sol::meta_function::less_than(_or_equal_to)`` are generated for you and overriden in Lua.
-* for ``operator==``
- - An equality operator will always be generated, doing pointer comparison if ``operator==`` on the two value types is not supported or doing a reference comparison and a value comparison if ``operator==`` is supported
-* heterogenous operators cannot be supported for equality, as Lua specifically checks if they use the same function to do the comparison: if they do not, then the equality method is not invoked; one way around this would be to write one ``int super_equality_function(lua_State* L) { ... }``, pull out arguments 1 and 2 from the stack for your type, and check all the types and then invoke ``operator==`` yourself after getting the types out of Lua (possibly using :ref:`sol::stack::get<stack-get>` and :ref:`sol::stack::check_get<stack-check-get>`)
-
-Otherwise, the following is used to specify functions to bind on the specific usertype for ``T``.
-
-* ``"{name}", &free_function``
- - Binds a free function / static class function / function object (lambda) to ``"{name}"``. If the first argument is ``T*`` or ``T&``, then it will bind it as a member function. If it is not, it will be bound as a "static" function on the lua table
-* ``"{name}", &type::function_name`` or ``"{name}", &type::member_variable``
- - Binds a typical member function or variable to ``"{name}"``. In the case of a member variable or member function, ``type`` must be ``T`` or a base of ``T``
-* ``"{name}", sol::readonly( &type::member_variable )``
- - Binds a typical variable to ``"{name}"``. Similar to the above, but the variable will be read-only, meaning an error will be generated if anything attemps to write to this variable
-* ``"{name}", sol::as_function( &type::member_variable )``
- - Binds a typical variable to ``"{name}"`` *but forces the syntax to be callable like a function*. This produces a getter and a setter accessible by ``obj:name()`` to get and ``obj::name(value)`` to set.
-* ``"{name}", sol::property( getter_func, setter_func )``
- - Binds a typical variable to ``"{name}"``, but gets and sets using the specified setter and getter functions. Not that if you do not pass a setter function, the variable will be read-only. Also not that if you do not pass a getter function, it will be write-only
-* ``"{name}", sol::var( some_value )`` or ``"{name}", sol::var( std::ref( some_value ) )``
- - Binds a typical variable to ``"{name}"``, optionally by reference (e.g., refers to the same memory in C++). This is useful for global variables / static class variables and the like
-* ``"{name}", sol::overloaded( Func1, Func2, ... )``
- - Creates an oveloaded member function that discriminates on number of arguments and types.
-* ``sol::base_classes, sol::bases<Bases...>``
- - Tells a usertype what its base classes are. You need this to have derived-to-base conversions work properly. See :ref:`inheritance<usertype-inheritance>`
-
-
-usertype arguments - simple usertype
-++++++++++++++++++++++++++++++++++++
-
-* ``sol::simple``
- - Only allowed as the first argument to the usertype constructor, must be accompanied by a ``lua_State*``
- - This tag triggers the :doc:`simple usertype<simple_usertype>` changes / optimizations
- - Only supported when directly invoking the constructor (e.g. not when calling ``sol::table::new_usertype`` or ``sol::table::new_simple_usertype``)
- - Should probably not be used directly. Use ``sol::table::new_usertype`` or ``sol::table::new_simple_usertype`` instead
-
-
-
-overloading
------------
-
-Functions set on a usertype support overloading. See :doc:`here<overload>` for an example.
-
-
-.. _usertype-inheritance:
-
-inheritance
------------
-
-Sol can adjust pointers from derived classes to base classes at runtime, but it has some caveats based on what you compile with:
-
-If your class has no complicatedâ„¢ virtual inheritance or multiple inheritance, than you can try to sneak away with a performance boost from not specifying any base classes and doing any casting checks. (What does "complicatedâ„¢" mean? Ask your compiler's documentation, if you're in that deep.)
-
-For the rest of us safe individuals out there: You must specify the ``sol::base_classes`` tag with the ``sol::bases<Types...>()`` argument, where ``Types...`` are all the base classes of the single type ``T`` that you are making a usertype out of.
-
-.. note::
-
- Always specify your bases if you plan to retrieve a base class using the Sol abstraction directly and not casting yourself.
-
-.. code-block:: cpp
- :linenos:
-
- struct A {
- int a = 10;
- virtual int call() { return 0; }
- };
- struct B : A {
- int b = 11;
- virtual int call() override { return 20; }
- };
-
-Then, to register the base classes explicitly:
-
-.. code-block:: cpp
- :linenos:
- :emphasize-lines: 5
-
- sol::state lua;
-
- lua.new_usertype<B>( "B",
- "call", &B::call,
- sol::base_classes, sol::bases<A>()
- );
-
-.. note::
-
- You must list ALL base classes, including (if there were any) the base classes of A, and the base classes of those base classes, etc. if you want Sol/Lua to handle them automagically.
-
-.. note::
-
- Sol does not support down-casting from a base class to a derived class at runtime.
-
-.. warning::
-
- Specify all base class member variables and member functions to avoid current implementation caveats regarding automatic base member lookup. Sol currently attempts to link base class methods and variables with their derived classes with an undocumented, unsupported feature, provided you specify ``sol::base_classes<...>``. Unfortunately, this can come at the cost of performance, depending on how "far" the base is from the derived class in the bases lookup list. If you do not want to suffer the performance degradation while we iron out the kinks in the implementation (and want it to stay performant forever), please specify all the base methods on the derived class in the method listing you write. In the future, we hope that with reflection we will not have to worry about this.
-
-
-inheritance + overloading
--------------------------
-
-While overloading is supported regardless of inheritance caveats or not, the current version of Sol has a first-match, first-call style of overloading when it comes to inheritance. Put the functions with the most derived arguments first to get the kind of matching you expect or cast inside of an intermediary C++ function and call the function you desire.
-
-traits
-------
-
-.. code-block:: cpp
- :caption: usertype_traits<T>
- :name: usertype-traits
-
- template<typename T>
- struct usertype_traits {
- static const std::string name;
- static const std::string metatable;
- static const std::string variable_metatable;
- static const std::string gc_table;
- };
-
-
-This trait is used to provide names for the various metatables and global tables used to perform cleanup and lookup. They are automagically generated at runtime. Sol attempts to parse the output of ``__PRETTY_FUCNTION__`` (``g++``/``clang++``) or ``_FUNCDSIG`` (``vc++``) to get the proper type name. If you have a special need you can override the names for your specific type. If you notice a bug in a class name when you don't manually specify it during setting a usertype, feel free to open an issue request or send an e-mail!
-
-
-compilation speed
------------------
-
-.. note::
-
- If you find that compilation times are too long and you're only binding member functions, consider perhaps using :doc:`simple usertypes<simple_usertype>`. This can reduce compile times (but may cost memory size and speed). See the simple usertypes documentation for more details.
-
-
-performance note
-----------------
-
-.. note::
-
- Note that performance for member function calls goes down by a fixed overhead if you also bind variables as well as member functions. This is purely a limitation of the Lua implementation and there is, unfortunately, nothing that can be done about it. If you bind only functions and no variables, however, Sol will automatically optimize the Lua runtime and give you the maximum performance possible. *Please consider ease of use and maintenance of code before you make everything into functions.*
-
-
-.. _destructible: http://en.cppreference.com/w/cpp/types/is_destructible
-.. _default_constructible: http://en.cppreference.com/w/cpp/types/is_constructible \ No newline at end of file
diff --git a/3rdparty/sol2/docs/source/api/usertype_memory.rst b/3rdparty/sol2/docs/source/api/usertype_memory.rst
deleted file mode 100644
index e3a82ed120e..00000000000
--- a/3rdparty/sol2/docs/source/api/usertype_memory.rst
+++ /dev/null
@@ -1,47 +0,0 @@
-usertype memory
-===============
-
-.. note::
-
- Sol does not take ownership of raw pointers, returned from functions or set through the ``set`` functions. Return a value, a ``std::unique_ptr``, a ``std::shared_ptr`` of some kind, or hook up the :doc:`unique usertypes traits<unique_usertype_traits>` to work for some specific handle structure you use (AKA, for ``boost::shared_ptr``).
-
-The userdata generated by Sol has a specific layout, depending on how Sol recognizes userdata passed into it. All of the referred to metatable names are generated from :ref:`usertype_traits\<T><usertype-traits>`. Note that we use 1 metatable per the 3 styles listed below, plus 1 additional metatable that is used for the actual table that you bind with the name when calling ``table::new/set_(simple_)usertype``.
-
-In general, we always insert a T* in the first `sizeof(T*)` bytes, so the any framework that pulls out those first bytes expecting a pointer will work. The rest of the data has some different alignments and contents based on what it's used for and how it's used.
-
-For ``T``
----------
-
-These are classified with the metatable name from :ref:`usertype_traits\<T><usertype-traits>`.
-
-The data layout for references is as follows::
-
- | T* | T |
- ^-sizeof(T*) bytes-^-sizeof(T) bytes, actual data-^
-
-Lua will clean up the memory itself but does not know about any destruction semantics T may have imposed, so when we destroy this data we simply call the destructor to destroy the object and leave the memory changes to for lua to handle after the "__gc" method exits.
-
-
-For ``T*``
-----------
-
-These are classified as a separate ``T*`` metatable, essentially the "reference" table. Things passed to Sol as a pointer or as a ``std::reference<T>`` are considered to be references, and thusly do not have a ``__gc`` (garbage collection) method by default. All raw pointers are non-owning pointers in C++. If you're working with a C API, provide a wrapper around pointers that are supposed to own data and use the constructor/destructor idioms (e.g., with an internal ``std::unique_ptr``) to keep things clean.
-
-The data layout for data that only refers is as follows::
-
- | T* |
- ^-sizeof(T*) bytes-^
-
-That is it. No destruction semantics need to be called.
-
-For ``std::unique_ptr<T, D>`` and ``std::shared_ptr<T>``
---------------------------------------------------------
-
-These are classified as :ref:`"unique usertypes"<unique-usertype>`, and have a special metatable for them as well. The special metatable is either generated when you add the usertype to Lua using :ref:`set_usertype<set-usertype>` or when you first push one of these special types. In addition to the data, a deleter function that understands the following layout is injected into the userdata layout.
-
-The data layout for these kinds of types is as follows::
-
- | T* | void(*)(void*) function_pointer | T |
- ^-sizeof(T*) bytes-^-sizeof(void(*)(void*)) bytes, deleter-^- sizeof(T) bytes, actal data -^
-
-Note that we put a special deleter function before the actual data. This is because the custom deleter must know where the offset to the data is and where the special deleter is. In other words, fixed-size-fields come before any variably-sized data (T can be known at compile time, but when serialized into Lua in this manner it becomes a runtime entity). Sol just needs to know about ``T*`` and the userdata (and userdata metatable) to work, everything else is for preserving construction / destruction semantics. \ No newline at end of file
diff --git a/3rdparty/sol2/docs/source/api/var.rst b/3rdparty/sol2/docs/source/api/var.rst
deleted file mode 100644
index 9e9bcec57d9..00000000000
--- a/3rdparty/sol2/docs/source/api/var.rst
+++ /dev/null
@@ -1,49 +0,0 @@
-var
-===
-For hooking up static / global variables to Lua usertypes
----------------------------------------------------------
-
-The sole purpose of this tagging type is to work with :doc:`usertypes<usertype>` to provide ``my_class.my_static_var`` access, and to also provide reference-based access as well.
-
-.. code-block:: cpp
-
- #include <sol.hpp>
-
- struct test {
- static int muh_variable;
- };
- int test::muh_variable = 25;
-
-
- int main () {
- sol::state lua;
- lua.open_libraries();
- lua.new_usertype<test>("test",
- "direct", sol::var(2),
- "global", sol::var(test::muh_variable),
- "ref_global", sol::var(std::ref(test::muh_variable))
- );
-
- int direct_value = lua["test"]["direct"];
- // direct_value == 2
-
- int global = lua["test"]["global"];
- // global == 25
- int global2 = lua["test"]["ref_global"];
- // global2 == 25
-
- test::muh_variable = 542;
-
- global = lua["test"]["global"];
- // global == 25
- // global is its own memory: was passed by value
-
- global2 = lua["test"]["ref_global"];
- // global2 == 542
- // global2 was passed through std::ref
- // global2 holds a reference to muh_variable
- // if muh_variable goes out of scope or is deleted
- // problems could arise, so be careful!
-
- return 0;
- }
diff --git a/3rdparty/sol2/docs/source/api/variadic_args.rst b/3rdparty/sol2/docs/source/api/variadic_args.rst
deleted file mode 100644
index 5d3e0c10282..00000000000
--- a/3rdparty/sol2/docs/source/api/variadic_args.rst
+++ /dev/null
@@ -1,49 +0,0 @@
-variadic_args
-=============
-transparent argument to deal with multiple parameters to a function
--------------------------------------------------------------------
-
-
-.. code-block:: cpp
-
- struct variadic_args;
-
-This class is meant to represent every single argument at its current index and beyond in a function list. It does not increment the argument count and is thus transparent. You can place it anywhere in the argument list, and it will represent all of the objects in a function call that come after it, whether they are listed explicitly or not.
-
-``variadic_args`` also has ``begin()`` and ``end()`` functions that return (almost) random-acess iterators. These return a proxy type that can be implicitly converted, much like the :doc:`table proxy type<proxy>`.
-
-.. code-block:: cpp
- :linenos:
-
- #include <sol.hpp>
-
- int main () {
-
- sol::state lua;
-
- // Function requires 2 arguments
- // rest can be variadic, but:
- // va will include everything after "a" argument,
- // which means "b" will be part of the varaidic_args list too
- // at position 0
- lua.set_function("v", [](int a, sol::variadic_args va, int b) {
- int r = 0;
- for (auto v : va) {
- int value = v; // get argument out (implicit conversion)
- // can also do int v = va.get<int>(i); with index i
- r += value;
- }
- // Only have to add a, b was included
- return r + a;
- });
-
- lua.script("x = v(25, 25)");
- lua.script("x2 = v(25, 25, 100, 50, 250, 150)");
- lua.script("x3 = v(1, 2, 3, 4, 5, 6)");
- // will error: not enough arguments
- //lua.script("x4 = v(1)");
-
- lua.script("print(x)"); // 50
- lua.script("print(x2)"); // 600
- lua.script("print(x3)"); // 21
- }
diff --git a/3rdparty/sol2/docs/source/benchmarks.rst b/3rdparty/sol2/docs/source/benchmarks.rst
deleted file mode 100644
index 6fa3224ffda..00000000000
--- a/3rdparty/sol2/docs/source/benchmarks.rst
+++ /dev/null
@@ -1,94 +0,0 @@
-benchmarks
-==========
-because somebody is going to ask eventually...
-----------------------------------------------
-
-
-Here are measurements of the *overhead that libraries impose around the Lua C API*: that is, the cost of abstracting / wrapping the plain Lua C API. Measurements are (at the time of writing) done with all libraries compiled against a DLL version of Lua 5.3.3 to make sure each Lua call has the same overhead between libraries (no Link Time Optimizations or other static library optimizations).
-
-These are some informal and formal benchmarks done by both the developers of sol and other library developers / users. We leave you to interpret the data as you see fit.
-
-* `lua_binding_benchmarks`_ by satoren (developer of `kaguya`_) (`Sol`_ is the "sol2" entry)
-* `lua-bench`_ by ThePhD (developer of `Sol`_)
-
-As of the writing of this documentation (August 12th, 2016), :doc:`Sol<index>` (Sol2) seems to take the cake in most categories for speed! Below are some graphs from `lua-bench`_. You can read the benchmarking code there if you think something was done wrong, and submit a pull requests or comment on something to make sure that ThePhD is being honest about his work. All categories are the performance of things described at the top of the :doc:`feature table<features>`.
-
-Note that Sol here makes use of its more performant variants (see :doc:`c_call<api/c_call>`), and ThePhD also does his best to make use of the most performant variants for other frameworks by disabling type checks where possible as well (Thanks to Liam Devine of OOLua for explaining how to turn off type checks in OOLua).
-
-Bars go up to the average execution time. Lower is better. Reported times are for the desired operation run through `nonius`_. Results are sorted from top to bottom by best to worst. Note that there are error bars to show potential variance in performance: generally, same-sized errors bars plus very close average execution time implies no significant difference in speed, despite the vastly different abstraction techniques used.
-
-.. image:: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua%20bench%20graph%20-%20member%20function%20calls.png
- :target: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua%20bench%20graph%20-%20member%20function%20calls.png
- :alt: bind several member functions to an object and call them in Lua code
-
-.. image:: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua%20bench%20graph%20-%20userdata%20variable%20access.png
- :target: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua%20bench%20graph%20-%20userdata%20variable%20access.png
- :alt: bind a variable to an object and call it in Lua code
-
-.. image:: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua%20bench%20graph%20-%20many%20userdata%20variables%20access.png
- :target: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua%20bench%20graph%20-%20many%20userdata%20variables%20access.png
- :alt: bind MANY variables to an object and call it in Lua code
-
-.. image:: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua%20bench%20graph%20-%20c%20function%20through%20lua.png
- :target: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua%20bench%20graph%20-%20c%20function%20through%20lua.png
- :alt: retrieve a C function bound in Lua and call it from C++
-
-.. image:: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua%20bench%20graph%20-%20stateful%20c%20function.png
- :target: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua%20bench%20graph%20-%20stateful%20c%20function.png
- :alt: bind a stateful C function (e.g., a mutable lambda), retrieve it, and call it from C++
-
-.. image:: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua%20bench%20graph%20-%20c%20function.png
- :target: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua%20bench%20graph%20-%20c%20function.png
- :alt: call a C function through Lua code
-
-.. image:: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua%20bench%20graph%20-%20lua%20function.png
- :target: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua%20bench%20graph%20-%20lua%20function.png
- :alt: retrieve a plain Lua function and call it from C++
-
-.. image:: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua%20bench%20graph%20-%20multi%20return.png
- :target: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua%20bench%20graph%20-%20multi%20return.png
- :alt: return mutliple objects from C++ using std::tuple or through a library-defined mechanism
-
-.. image:: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua%20bench%20graph%20-%20global%20get.png
- :target: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua%20bench%20graph%20-%20global%20get.png
- :alt: retrieve a value from the global table
-
-.. image:: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua%20bench%20graph%20-%20global%20set.png
- :target: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua%20bench%20graph%20-%20global%20set.png
- :alt: set a value into the global table
-
-.. image:: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua%20bench%20graph%20-%20table%20chained%20get.png
- :target: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua%20bench%20graph%20-%20table%20chained%20get.png
- :alt: measures the cost of doing consecutive lookups into a table that exists from C++; some libraries fail here because they do not do lazy evaluation or chaining properly
-
-.. image:: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua%20bench%20graph%20-%20table%20get.png
- :target: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua%20bench%20graph%20-%20table%20get.png
- :alt: measures the cost of retrieving a value from a table in C++; this nests 1 level so as to not be equivalent to any measured global table get optimzations
-
-.. image:: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua%20bench%20graph%20-%20table%20chained%20set.png
- :target: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua%20bench%20graph%20-%20table%20chained%20set.png
- :alt: measures the cost of doing consecutive lookups into a table that exists from C++ and setting the final value; some libraries fail here because they do not do lazy evaluation or chaining properly
-
-.. image:: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua%20bench%20graph%20-%20table%20set.png
- :target: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua%20bench%20graph%20-%20table%20set.png
- :alt: measures the cost of setting a value into a table in C++; this nests 1 level so as to not be equivalent to any measured global table set optimzations
-
-.. image:: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua%20bench%20graph%20-%20return%20userdata.png
- :target: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua%20bench%20graph%20-%20return%20userdata.png
- :alt: bind a C function which returns a custom class by-value and call it through Lua code
-
-.. image:: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua%20bench%20graph%20-%20get%20optional.png
- :target: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua%20bench%20graph%20-%20get%20optional.png
- :alt: retrieve an item from a table that does not exist in Lua and check for its existence (testing the cost of the failure case)
-
-.. image:: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua%20bench%20graph%20-%20base%20from%20derived.png
- :target: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua%20bench%20graph%20-%20base%20from%20derived.png
- :alt: retrieve base class pointer out of Lua without knowing exact derived at compile-time, and have it be correct for multiple-inheritance
-
-
-
-.. _lua-bench: https://github.com/ThePhD/lua-bench
-.. _lua_binding_benchmarks: http://satoren.github.io/lua_binding_benchmark/
-.. _kaguya: https://github.com/satoren/kaguya
-.. _Sol: https://github.com/ThePhD/sol2
-.. _nonius: https://github.com/rmartinho/nonius/
diff --git a/3rdparty/sol2/docs/source/cmake.rst b/3rdparty/sol2/docs/source/cmake.rst
deleted file mode 100644
index 2d9e378d7e6..00000000000
--- a/3rdparty/sol2/docs/source/cmake.rst
+++ /dev/null
@@ -1,54 +0,0 @@
-CMake Script
-============
-
-Thanks to `Kevin Brightwell`_, you can drop this CMake Script into your CMake Projects to have Sol part of one of its builds:
-
-.. code-block:: cmake
- :caption: CMake Build Script
- :name: cmake-build-script
-
- # Needed for ExternalProject_Add()
- include(ExternalProject)
-
- # Needed for building single header for sol2
- find_package(PythonInterp 3 REQUIRED)
-
- # Configuration data for What sol2 version to use and where to put it
- set(SOL2_TAG v2.5.6)
- set(SOL2_HPP "${CMAKE_BINARY_DIR}/include/sol.hpp")
-
- # Download and "install" sol2
- ExternalProject_add(
- sol2
- PREFIX ${VENDOR_PATH} # Set this value yourself
-
- GIT_REPOSITORY "https://github.com/ThePhD/sol2.git"
- GIT_TAG ${SOL2_TAG}
-
- # No CMake commands to run, so tell CMake not to configure
- CONFIGURE_COMMAND ""
-
- # Generate the single header and put it in ${SOL2_HPP}
- BINARY_DIR ${VENDOR_PREFIX}/src/sol2
- BUILD_COMMAND
- ${CMAKE_COMMAND} -E make_directory ${CMAKE_BINARY_DIR}/include
- COMMAND
- ${PYTHON_EXECUTABLE} ./single.py -o "${SOL2_HPP}"
-
- # No install or test command for the library
- INSTALL_COMMAND ""
- TEST_COMMAND "")
-
- # Conditionally turn on SOL_CHECK_ARGUMENTS if using Debug mode
- if (CMAKE_BUILD_TYPE MATCHES "[Dd]ebug")
- if (VERBOSE)
- message(STATUS "Turning on SOL_CHECK_ARGUMENTS in Debug mode.")
- endif()
- add_definitions(-DSOL_CHECK_ARGUMENTS)
- endif()
-
- # Make sure sol2 is found as a system directory
- include_directories(SYSTEM ${CMAKE_BINARY_DIR}/include)
-
-
-.. _Kevin Brightwell: https://github.com/ThePhD/sol2/issues/89
diff --git a/3rdparty/sol2/docs/source/codecvt.rst b/3rdparty/sol2/docs/source/codecvt.rst
deleted file mode 100644
index 750f6936bd3..00000000000
--- a/3rdparty/sol2/docs/source/codecvt.rst
+++ /dev/null
@@ -1,8 +0,0 @@
-std::(w/u16/u32)string support
-==============================
-because this is surprisingly hard using standard C++
-----------------------------------------------------
-
-Individuals using Visual Studio 2015, or on Windows with the VC++ and MinGW compilers (possibly Clang++ on Windows as well) have ``<codecvt>`` headers, and thusly Sol will attempt to include it. Individuals on GC 4.9.x, Clang 3.5.x, Clang 3.6.x do not seem to have ``<codecvt>`` shipped with the standard library that comes with installation of these compilers. If you want ``std::wstring``, ``std::u16string``, ``std::u32string`` automatic handling then you need to make sure you have those headers and then define ``SOL_CODECVT_SUPPORT`` on unsupported compilers.
-
-ThePhD did not want this to have to be a thing, but slow implementations and such force their hand. When GCC 7.x comes out, ThePhD will consider removing the effect of defining this macro and leaving <codecvt> support in at all times.
diff --git a/3rdparty/sol2/docs/source/compilation.rst b/3rdparty/sol2/docs/source/compilation.rst
deleted file mode 100644
index 22b894e7f8d..00000000000
--- a/3rdparty/sol2/docs/source/compilation.rst
+++ /dev/null
@@ -1,25 +0,0 @@
-binary size, compile time
-=========================
-getting good final product out of sol2
---------------------------------------
-
-For individiauls who use :doc:`usertypes<api/usertype>` a lot, they can find their compilation times increase. This is due to C++11 and C++14 not having very good facilities for handling template parameters and variadic template parameters. There are a few things in cutting-edge C++17 and C++Next that sol can use, but the problem is many people cannot work with the latest and greatest: therefore, we have to use older techniques that result in a fair amount of redundant function specializations that can be subject to the pickiness of the compiler's inlining and other such techniques.
-
-what to do
-----------
-
-Here are some notes on achieving better compile-times without sacrificing too much performance:
-
-* When you bind lots of usertypes, put them all in a *single* translation unit (one C++ file) so that it is not recompiled multiple times over, only to be discarded later by the linker.
- - Remember that the usertype binding ends up being serialized into the Lua state, so you never need them to appear in a header and cause that same compilation overhead for every compiled unit in your project.
-* For extremely large usertypes, consider using :doc:`simple_usertype<api/simple_usertype>`.
- - It performs much more work at runtime rather than compile-time, and should still give comparative performance (but it loses out in some cases for variable bindings or when you bind all functions to a usertype).
-* If you are developing a shared library, restrict your overall surface area by specifically and explicitly marking functions as visible and exported and leaving everything else as hidden or invisible by default
-
-
-next steps
-----------
-
-The next step for Sol from a developer standpoint is to formally make the library a C++17 one. This would mean using Fold Expressions and several other things which will reduce compilation time drastically. Unfortunately, that means also boosting compiler requirements. While most wouldn't care, others are very slow to upgrade: finding the balance is difficult, and often we have to opt for backwards compatibility and fixes for bad / older compilers (of which there are many in the codebase already).
-
-Hopefully, as things progress, we move things forward.
diff --git a/3rdparty/sol2/docs/source/conf.py b/3rdparty/sol2/docs/source/conf.py
deleted file mode 100644
index 02d00f92ef4..00000000000
--- a/3rdparty/sol2/docs/source/conf.py
+++ /dev/null
@@ -1,291 +0,0 @@
-#!/usr/bin/env python3
-# -*- coding: utf-8 -*-
-#
-# Sol documentation build configuration file, created by
-# sphinx-quickstart on Mon Feb 29 21:49:51 2016.
-#
-# This file is execfile()d with the current directory set to its
-# containing dir.
-#
-# Note that not all possible configuration values are present in this
-# autogenerated file.
-#
-# All configuration values have a default; values that are commented out
-# serve to show the default.
-
-import sys
-import os
-
-# If extensions (or modules to document with autodoc) are in another directory,
-# add these directories to sys.path here. If the directory is relative to the
-# documentation root, use os.path.abspath to make it absolute, like shown here.
-#sys.path.insert(0, os.path.abspath('.'))
-
-# -- General configuration ------------------------------------------------
-
-# If your documentation needs a minimal Sphinx version, state it here.
-#needs_sphinx = '1.0'
-
-# Add any Sphinx extension module names here, as strings. They can be
-# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
-# ones.
-extensions = [
- 'sphinx.ext.autodoc',
- 'sphinx.ext.doctest',
- 'sphinx.ext.todo'
-]
-
-# Add any paths that contain templates here, relative to this directory.
-templates_path = ['_templates']
-
-# The suffix(es) of source filenames.
-# You can specify multiple suffix as a list of string:
-# source_suffix = ['.rst', '.md']
-source_suffix = '.rst'
-
-# The encoding of source files.
-#source_encoding = 'utf-8-sig'
-
-# The master toctree document.
-master_doc = 'index'
-
-# General information about the project.
-project = 'Sol'
-copyright = '2016, ThePhD'
-author = 'ThePhD'
-
-# The version info for the project you're documenting, acts as replacement for
-# |version| and |release|, also used in various other places throughout the
-# built documents.
-#
-# The short X.Y version.
-version = '2.15'
-# The full version, including alpha/beta/rc tags.
-release = '2.15.5'
-
-# The language for content autogenerated by Sphinx. Refer to documentation
-# for a list of supported languages.
-#
-# This is also used if you do content translation via gettext catalogs.
-# Usually you set "language" from the command line for these cases.
-language = None
-
-# There are two options for replacing |today|: either, you set today to some
-# non-false value, then it is used:
-#today = ''
-# Else, today_fmt is used as the format for a strftime call.
-#today_fmt = '%B %d, %Y'
-
-# List of patterns, relative to source directory, that match files and
-# directories to ignore when looking for source files.
-exclude_patterns = []
-
-# The reST default role (used for this markup: `text`) to use for all
-# documents.
-#default_role = None
-
-# If true, '()' will be appended to :func: etc. cross-reference text.
-#add_function_parentheses = True
-
-# If true, the current module name will be prepended to all description
-# unit titles (such as .. function::).
-#add_module_names = True
-
-# If true, sectionauthor and moduleauthor directives will be shown in the
-# output. They are ignored by default.
-#show_authors = False
-
-# The name of the Pygments (syntax highlighting) style to use.
-pygments_style = 'sphinx'
-
-# The default highlighting language: default is python
-highlight_language = 'c++'
-
-# A list of ignored prefixes for module index sorting.
-#modindex_common_prefix = []
-
-# If true, keep warnings as "system message" paragraphs in the built documents.
-#keep_warnings = False
-
-# If true, `todo` and `todoList` produce output, else they produce nothing.
-todo_include_todos = True
-
-
-# -- Options for HTML output ----------------------------------------------
-
-# The theme to use for HTML and HTML Help pages. See the documentation for
-# a list of builtin themes.
-html_theme = "haiku"
-
-# Theme options are theme-specific and customize the look and feel of a theme
-# further. For a list of options available for each theme, see the
-# documentation.
-#html_theme_options = {}
-
-# Add any paths that contain custom themes here, relative to this directory.
-html_theme_path = ["_themes", ]
-
-# The name for this set of Sphinx documents. If None, it defaults to
-# "<project> v<release> documentation".
-#html_title = None
-
-# A shorter title for the navigation bar. Default is the same as html_title.
-#html_short_title = None
-
-# The name of an image file (relative to this directory) to place at the top
-# of the sidebar.
-#html_logo = None
-
-# The name of an image file (relative to this directory) to use as a favicon of
-# the docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32
-# pixels large.
-#html_favicon = None
-
-# Add any paths that contain custom static files (such as style sheets) here,
-# relative to this directory. They are copied after the builtin static files,
-# so a file named "default.css" will overwrite the builtin "default.css".
-html_static_path = ['_static']
-
-# Add any extra paths that contain custom files (such as robots.txt or
-# .htaccess) here, relative to this directory. These files are copied
-# directly to the root of the documentation.
-#html_extra_path = []
-
-# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
-# using the given strftime format.
-#html_last_updated_fmt = '%b %d, %Y'
-
-# If true, SmartyPants will be used to convert quotes and dashes to
-# typographically correct entities.
-#html_use_smartypants = True
-
-# Custom sidebar templates, maps document names to template names.
-#html_sidebars = {}
-
-# Additional templates that should be rendered to pages, maps page names to
-# template names.
-#html_additional_pages = {}
-
-# If false, no module index is generated.
-#html_domain_indices = True
-
-# If false, no index is generated.
-#html_use_index = True
-
-# If true, the index is split into individual pages for each letter.
-#html_split_index = False
-
-# If true, links to the reST sources are added to the pages.
-#html_show_sourcelink = True
-
-# If true, "Created using Sphinx" is shown in the HTML footer. Default is True.
-#html_show_sphinx = True
-
-# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True.
-#html_show_copyright = True
-
-# If true, an OpenSearch description file will be output, and all pages will
-# contain a <link> tag referring to it. The value of this option must be the
-# base URL from which the finished HTML is served.
-#html_use_opensearch = ''
-
-# This is the file name suffix for HTML files (e.g. ".xhtml").
-#html_file_suffix = None
-
-# Language to be used for generating the HTML full-text search index.
-# Sphinx supports the following languages:
-# 'da', 'de', 'en', 'es', 'fi', 'fr', 'h', 'it', 'ja'
-# 'nl', 'no', 'pt', 'ro', 'r', 'sv', 'tr'
-#html_search_language = 'en'
-
-# A dictionary with options for the search language support, empty by default.
-# Now only 'ja' uses this config value
-#html_search_options = {'type': 'default'}
-
-# The name of a javascript file (relative to the configuration directory) that
-# implements a search results scorer. If empty, the default will be used.
-#html_search_scorer = 'scorer.js'
-
-# Output file base name for HTML help builder.
-htmlhelp_basename = 'Soldoc'
-
-# -- Options for LaTeX output ---------------------------------------------
-
-latex_elements = {
-# The paper size ('letterpaper' or 'a4paper').
-#'papersize': 'letterpaper',
-
-# The font size ('10pt', '11pt' or '12pt').
-#'pointsize': '10pt',
-
-# Additional stuff for the LaTeX preamble.
-#'preamble': '',
-
-# Latex figure (float) alignment
-#'figure_align': 'htbp',
-}
-
-# Grouping the document tree into LaTeX files. List of tuples
-# (source start file, target name, title,
-# author, documentclass [howto, manual, or own class]).
-latex_documents = [
- (master_doc, 'Sol.tex', 'Sol Documentation',
- 'ThePhD', 'manual'),
-]
-
-# The name of an image file (relative to this directory) to place at the top of
-# the title page.
-#latex_logo = None
-
-# For "manual" documents, if this is true, then toplevel headings are parts,
-# not chapters.
-#latex_use_parts = False
-
-# If true, show page references after internal links.
-#latex_show_pagerefs = False
-
-# If true, show URL addresses after external links.
-#latex_show_urls = False
-
-# Documents to append as an appendix to all manuals.
-#latex_appendices = []
-
-# If false, no module index is generated.
-#latex_domain_indices = True
-
-
-# -- Options for manual page output ---------------------------------------
-
-# One entry per manual page. List of tuples
-# (source start file, name, description, authors, manual section).
-man_pages = [
- (master_doc, 'sol', 'Sol Documentation',
- [author], 1)
-]
-
-# If true, show URL addresses after external links.
-#man_show_urls = False
-
-
-# -- Options for Texinfo output -------------------------------------------
-
-# Grouping the document tree into Texinfo files. List of tuples
-# (source start file, target name, title, author,
-# dir menu entry, description, category)
-texinfo_documents = [
- (master_doc, 'Sol', 'Sol Documentation',
- author, 'Sol', 'One line description of project.',
- 'Miscellaneous'),
-]
-
-# Documents to append as an appendix to all manuals.
-#texinfo_appendices = []
-
-# If false, no module index is generated.
-#texinfo_domain_indices = True
-
-# How to display URL addresses: 'footnote', 'no', or 'inline'.
-#texinfo_show_urls = 'footnote'
-
-# If true, do not generate a @detailmenu in the "Top" node's menu.
-#texinfo_no_detailmenu = False
diff --git a/3rdparty/sol2/docs/source/eevee_code_after.jpg b/3rdparty/sol2/docs/source/eevee_code_after.jpg
deleted file mode 100644
index 33594ce5e0b..00000000000
--- a/3rdparty/sol2/docs/source/eevee_code_after.jpg
+++ /dev/null
Binary files differ
diff --git a/3rdparty/sol2/docs/source/eevee_code_before.jpg b/3rdparty/sol2/docs/source/eevee_code_before.jpg
deleted file mode 100644
index ea9650ff1ac..00000000000
--- a/3rdparty/sol2/docs/source/eevee_code_before.jpg
+++ /dev/null
Binary files differ
diff --git a/3rdparty/sol2/docs/source/errors.rst b/3rdparty/sol2/docs/source/errors.rst
deleted file mode 100644
index c44ebe76988..00000000000
--- a/3rdparty/sol2/docs/source/errors.rst
+++ /dev/null
@@ -1,56 +0,0 @@
-errors
-======
-how to handle exceptions or other errors
-----------------------------------------
-
-Here is some advice and some tricks for common errors about iteration, compile time / linker errors, and other pitfalls, especially when dealing with thrown exceptions, error conditions and the like in Sol.
-
-
-Linker Errors
--------------
-
-There are lots of reasons for compiler linker errors. A common one is not knowing that you've compiled the Lua library as C++: when building with C++, it is important to note that every typical (static or dynamic) library expects the C calling convention to be used and that Sol includes the code using ``extern 'C'`` where applicable.
-
-However, when the target Lua library is compiled with C++, one must change the calling convention and name mangling scheme by getting rid of the ``extern 'C'`` block. This can be achieved by adding ``#define SOL_USING_CXX_LUA`` before including sol2, or by adding it to your compilation's command line.
-
-
-Catch and CRASH!
-----------------
-
-By default, Sol will add a ``default_at_panic`` handler. If exceptions are not turned off, this handler will throw to allow the user a chance to recover. However, in almost all cases, when Lua calls ``lua_atpanic`` and hits this function, it means that something *irreversibly wrong* occured in your code or the Lua code and the VM is in an unpredictable or dead state. Catching an error thrown from the default handler and then proceeding as if things are cleaned up or okay is NOT the best idea. Unexpected bugs in optimized and release mode builds can result, among other serious issues.
-
-It is preferred if you catch an error that you log what happened, terminate the Lua VM as soon as possible, and then crash if your application cannot handle spinning up a new Lua state. Catching can be done, but you should understand the risks of what you're doing when you do it. For more information about catching exceptions, the potentials, not turning off exceptions and other tricks and caveats, read about :doc:`exceptions in Sol here<exceptions>`.
-
-Lua is a C API first and foremost: exceptions bubbling out of it is essentially last-ditch, terminal behavior that the VM does not expect. You can see an example of handling a panic on the exceptions page :ref:`here<typical-panic-function>`.
-
-
-Destructors and Safety
-----------------------
-
-Another issue is that Lua is a C API. It uses ``setjmp`` and ``longjmp`` to jump out of code when an error occurs. This means it will ignore destructors in your code if you use the library or the underlying Lua VM improperly. To solve this issue, build Lua as C++. When a Lua VM error occurs and ``lua_error`` is triggered, it raises it as an exception which will provoke proper unwinding semantics.
-
-
-Protected Functions and Access
-------------------------------
-
-By default, :doc:`sol::function<api/function>` assumes the code ran just fine and there are no problems. :ref:`sol::state(_view)::script(_file)<state-script-function>` also assumes that code ran just fine. Use :doc:`sol::protected_function<api/protected_function>` to have function access where you can check if things worked out. Use :doc:`sol::optional<api/optional>` to get a value safely from Lua. Use :ref:`sol::state(_view)::do_string/do_file/load/load_file<state-do-code>` to safely load and get results from a script. The defaults are provided to be simple and fast with thrown exceptions to violently crash the VM in case things go wrong.
-
-Protected Functions Are Not Catch All
--------------------------------------
-
-Sometimes, some scripts load poorly. Even if you protect the function call, the actual file loading or file execution will be bad, in which case :doc:`sol::protected_function<api/protected_function>` will not save you. Make sure you register your own panic handler so you can catch errors, or follow the advice of the catch + crash behavior above.
-
-Raw Functions
--------------
-
-When you push a function into Lua using Sol using any methods and that function exactly matches the signature ``int( lua_State* );`` (and is a free function (e.g., not a member function pointer)), it will be treated as a *raw C function*. This means that the usual exception trampoline Sol wraps your other function calls in will not be present. You will be responsible for catching exceptions and handling them before they explode into the C API (and potentially destroy your code). Sol in all other cases adds an exception-handling trampoline that turns exceptions into Lua errors that can be caught by the above-mentioned protected functions and accessors.
-
-.. warning::
-
- Do NOT assume that building Lua as C++ will allow you to throw directly from a raw function. If an exception is raised and it bubbles into the Lua framework, even if you compile as C++, Lua does not recognize exceptions other than the ones that it uses with ``lua_error``. In other words, it will return some completely bogus result, potentially leave your Lua stack thrashed, and the rest of your VM *can* be in a semi-trashed state. Please avoid this!
-
-
-Iteration
----------
-
-Tables may have other junk on them that makes iterating through their numeric part difficult when using a bland ``for-each`` loop, or when calling sol's ``for_each`` function. Use a numeric look to iterate through a table. Iteration does not iterate in any defined order also: see :ref:`this note in the table documentation for more explanation<iteration_note>`.
diff --git a/3rdparty/sol2/docs/source/exceptions.rst b/3rdparty/sol2/docs/source/exceptions.rst
deleted file mode 100644
index 0e6584a20ef..00000000000
--- a/3rdparty/sol2/docs/source/exceptions.rst
+++ /dev/null
@@ -1,65 +0,0 @@
-exceptions
-==========
-since somebody is going to ask about it...
-------------------------------------------
-
-Yes, you can turn off exceptions in Sol with ``#define SOL_NO_EXCEPTIONS`` before including or by passing the command line argument that defines ``SOL_NO_EXCEPTIONS``. We don't recommend it unless you're playing with a Lua distro that also doesn't play nice with exceptions (like non-x64 versions of :ref:`LuaJIT<LuaJIT and exceptions>` ).
-
-If you turn this off, the default `at_panic`_ function :doc:`state<api/state>` set for you will not throw. Instead, the default Lua behavior of aborting will take place (and give you no chance of escape unless you implement your own at_panic function and decide to try ``longjmp`` out).
-
-To make this not be the case, you can set a panic function directly with ``lua_atpanic( lua, my_panic_function );`` or when you create the ``sol::state`` with ``sol::state lua(my_panic_function);``. Here's an example ``my_panic_function`` you can have that prints out its errors:
-
-.. code-block:: cpp
- :caption: regular panic function
- :name: typical-panic-function
-
- #include <sol.hpp>
- #include <iostream>
-
- inline void my_panic(sol::optional<std::string> maybe_msg) {
- std::cerr << "Lua is in a panic state and will now abort() the application" << std::endl;
- if (maybe_msg) {
- const std::string& msg = maybe_msg.value();
- std::cerr << "\terror message: " << msg << std::endl;
- }
- // When this function exits, Lua will exhibit default behavior and abort()
- }
-
- int main () {
- sol::state lua(sol::c_call<decltype(&my_panic), &my_panic>);
- // or, if you already have a lua_State* L
- // lua_atpanic( L, sol::c_call<decltype(&my_panic)>, &my_panic> );
- // or, with state/state_view:
- // sol::state_view lua(L);
- // lua.set_panic( sol::c_call<decltype(&my_panic)>, &my_panic> );
- }
-
-
-Note that ``SOL_NO_EXCEPTIONS`` will also disable :doc:`protected_function<api/protected_function>`'s ability to catch C++ errors you throw from C++ functions bound to Lua that you are calling through that API. So, only turn off exceptions in Sol if you're sure you're never going to use exceptions ever. Of course, if you are ALREADY not using Exceptions, you don't have to particularly worry about this and now you can use Sol!
-
-If there is a place where a throw statement is called or a try/catch is used and it is not hidden behind a ``#ifndef SOL_NO_EXCEPTIONS`` block, please file an issue at `issue`_ or submit your very own pull request so everyone can benefit!
-
-
-.. _LuaJIT and exceptions:
-
-LuaJIT and exceptions
----------------------
-
-It is important to note that a popular 5.1 distribution of Lua, LuaJIT, has some serious `caveats regarding exceptions`_. LuaJIT's exception promises are flaky at best on x64 (64-bit) platforms, and entirely terrible on non-x64 (32-bit, ARM, etc.) platforms. The trampolines we have in place for all functions bound through conventional means in Sol will catch exceptions and turn them into Lua errors so that LuaJIT remainds unperturbed, but if you link up a C function directly yourself and throw, chances are you might have screwed the pooch.
-
-Testing in `this closed issue`_ that it doesn't play nice on 64-bit Linux in many cases either, especially when it hits an error internal to the interpreter (and does not go through Sol). We do have tests, however, that compile for our continuous integration check-ins that check this functionality across several compilers and platforms to keep you protected and given hard, strong guarantees for what happens if you throw in a function bound by Sol. If you stray outside the realm of Sol's protection, however... Good luck.
-
-Lua and LuaJIT C++ Exception Full Interoperability
---------------------------------------------------
-
-You can ``#define SOL_EXCEPTIONS_SAFE_PROPAGATION`` before including Sol or define ``SOL_EXCEPTIONS_SAFE_PROPAGATION`` on the command line if you know your implmentation of Lua has proper unwinding semantics that can be thrown through the version of the Lua API you have built / are using.
-
-This will prevent sol from catching ``(...)`` errors in platforms and compilers that have full C++ exception interoperability. This means that Lua errors can be caught with ``catch (...)`` in the C++ end of your code after it goes through Lua, and exceptions can pass through the Lua API and Stack safely.
-
-Currently, the only known platform to do this is the listed "Full" `platforms for LuaJIT`_ and Lua compiled as C++. This define is not turned on automatically, even if Sol detects LuaJIT: *it is your job to define it if you know that your platform supports it*!
-
-.. _issue: https://github.com/ThePhD/sol2/issues/
-.. _at_panic: http://www.Lua.org/manual/5.3/manual.html#4.6
-.. _caveats regarding exceptions: http://luajit.org/extensions.html#exceptions
-.. _platforms for LuaJIT: http://luajit.org/extensions.html#exceptions
-.. _this closed issue: https://github.com/ThePhD/sol2/issues/28
diff --git a/3rdparty/sol2/docs/source/features.rst b/3rdparty/sol2/docs/source/features.rst
deleted file mode 100644
index 6d52e317eeb..00000000000
--- a/3rdparty/sol2/docs/source/features.rst
+++ /dev/null
@@ -1,259 +0,0 @@
-features
-========
-what does Sol (and other libraries) support?
---------------------------------------------
-
-The goal of Sol is to provide an incredibly clean API that provides high performance (comparable or better than the C it was written on) and extreme ease of use. That is, users should be able to say: "this works pretty much how I expected it to."
-
-For the hard technical components of Lua and its ecosystem we support, here is the full rundown:
-
-what Sol supports
------------------
-
-* Support for Lua 5.1, 5.2, and 5.3. We achieve this through our "doc:`compatibility<compatibility>` header.
-
-* :doc:`Table<api/table>` support: setting values, getting values of multiple (different) types
- - :doc:`Lazy evaluation<api/proxy>` for nested/chained queries
- ``table["a"]["b"]["c"] = 24;``
- - Implicit conversion to the types you want
- ``double b = table["computed_value"];``
-
-* :doc:`Optional<api/optional>` support: setting values, getting values of multiple (different) types
- - :doc:`Lazy evaluation<api/proxy>` for nested/chained queries
- ``optional<int> maybe_number = table["a"]["b"]["invalid_key"];``
- - Turns on safety when you want it: speed when you don't
-
-* Support for callables (functions, lambdas, member functions)
- - Pull out any Lua function with :doc:`sol::function<api/function>`
- ``sol::function fx = table["socket_send"];``
- - Can also set callables into :doc:`operator[] proxies<api/proxy>`
- ``table["move_dude"] = engine::move_dude;``
- - Safety: use :doc:`sol::protected_function<api/protected_function>` to catch any kind of error
- + ANY kind: C++ exception or Lua erors are trapped and run through the optional ``error_handler`` variable
- - *Advanced:* Overloading of a single function so you don't need to do boring typechecks
-
-* User-Defined Type (:doc:`sol::usertype<api/usertype>` in the API) support:
- - Set member functions to be called
- - Set member variables
- - Set variables on a class that are based on setter/getter functions
- - Use free-functions that take the Type as a first argument (pointer or reference)
- - Support for "Factory" classes that do not expose constructor or destructor
- - Modifying memory of userdata in C++ directly affects Lua without copying, and
- - Modifying userdata in Lua directly affects C++ references/pointers
- ``my_class& a = table["a"];``
- ``my_class* a_ptr = table["a"];``
- - If you want a copy, just use value semantics and get copies:
- ``my_class a = table["a"];``
-
-* Thread/Coroutine support
- - Use, resume, and play with :doc:`coroutines<api/coroutine>` like regular functions
- - Get and use them even on a separate Lua :doc:`thread<api/thread>`
- - Monitor status and get check errors
-
-* *Advanced:* Customizable and extensible to your own types if you override :doc:`getter/pusher/checker<api/stack>` template struct definitions.
-
-
-The Feature Matrixâ„¢
--------------------
-
-The below feature table checks for the presence of something. It, however, does not actually account for any kind of laborious syntax.
-
-✔ full support: works as you'd expect (operator[] on tables, etc...)
-
-~ partial support / wonky support: this means its either supported through some other fashion (not with the desired syntax, serious caveats, etc.). Sometimes means dropping down to use the plain C API (at which point, what was the point of the abstraction?).
-
-✗ no support: feature doesn't work or, if it's there, it REALLY sucks to use
-
-Implementation notes from using the libraries are below the tables.
-
-
-category explanations
----------------------
-
-Explanations for a few categories are below (rest are self-explanatory).
-
-* optional: Support for getting an element, or potentially not (and not forcing the default construction of what amounts to a bogus/dead object). Usually comes with ``std(::experimental)::optional``. It's a fairly new class, so a hand-rolled class internal to the library with similar semantics is also acceptable
-* tables: Some sort of abstraction for dealing with tables. Ideal support is ``mytable["some_key"] = value``, and everything that the syntax implies.
-* table chaining: In conjunction with tables, having the ability to query deeply into tables ``mytable["key1"]["key2"]["key3"]``. Note that this becomes a tripping point for some libraries: crashing if ``"key1"`` doesn't exist while trying to access ``"key2"`` (Sol avoids this specifically when you use ``sol::optional``), and sometimes it's also a heavy performance bottleneck as expressions are not lazy-evaluated by a library.
-* arbitrary keys: Letting C++ code use userdata, other tables, integers, etc. as keys for into a table.
-* user-defined types (udts): C++ types given form and function in Lua code.
-* udts - member functions: C++ member functions on a type, usually callable with ``my_object:foo(1)`` or similar in Lua.
-* udts - table variables: C++ member variables/properties, manipulated by ``my_object.var = 24`` and in Lua
-* function binding: Support for binding all types of functions. Lambdas, member functions, free functions, in different contexts, etc...
-* protected function: Use of ``lua_pcall`` to call a function, which offers error-handling and trampolining (as well as the ability to opt-in / opt-out of this behavior)
-* multi-return: returning multiple values from and to Lua (generally through ``std::tuple<...>`` or in some other way)
-* variadic/variant argument: being able to accept "anything" from Lua, and even return "anything" to Lua (``object`` abstraction, variadic arguments, etc...)
-* inheritance: allowing some degree of subtyping or inheritance on classes / userdata from Lua - this generally means that you can retrieve a base pointer from Lua even if you hand the library a derived pointer
-* overloading: the ability to call overloaded functions, matched based on arity or type (``foo( 1 )`` from lua calls a different function then ``foo( "bark" )``).
-* Lua thread: basic wrapping of the lua thread API; ties in with coroutine.
-* coroutines: allowing a function to be called multiple times, resuming the execution of a Lua coroutine each time
-
-+---------------------------+-------------+------------+----------+---------+----------+-----------+-----------+----------------+----------+----------+-----------+-----------------+--------+
-| | plain C | luawrapper | lua-intf | luabind | Selene | Sol2 | oolua | lua-api-pp | kaguya | SLB3 | SWIG | luacppinterface | luwra |
-| | | | | | | | | | | | | | |
-+===========================+=============+============+==========+=========+==========+===========+===========+================+==========+==========+===========+=================+========+
-| optional | ~ | ✗ | ✔ | ✗ | ✗ | ✔ | ✗ | ✗ | ✔ | ✗ | ✗ | ✗ | ✗ |
-+---------------------------+-------------+------------+----------+---------+----------+-----------+-----------+----------------+----------+----------+-----------+-----------------+--------+
-| tables | ~ | ~ | ~ | ✔ | ✔ | ✔ | ~ | ✔ | ✔ | ✗ | ✗ | ~ | ✔ |
-+---------------------------+-------------+------------+----------+---------+----------+-----------+-----------+----------------+----------+----------+-----------+-----------------+--------+
-| table chaining | ~ | ~ | ~ | ✔ | ✔ | ✔ | ✗ | ✔ | ✔ | ✗ | ✗ | ~ | ✔ |
-+---------------------------+-------------+------------+----------+---------+----------+-----------+-----------+----------------+----------+----------+-----------+-----------------+--------+
-| arbitrary keys | ~ | ✔ | ✔ | ✔ | ✔ | ✔ | ✗ | ~ | ✔ | ✗ | ✗ | ✗ | ✗ |
-+---------------------------+-------------+------------+----------+---------+----------+-----------+-----------+----------------+----------+----------+-----------+-----------------+--------+
-| user-defined types (udts) | ~ | ✔ | ✔ | ✔ | ✔ | ✔ | ~ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
-+---------------------------+-------------+------------+----------+---------+----------+-----------+-----------+----------------+----------+----------+-----------+-----------------+--------+
-| udts: member functions | ~ | ✔ | ✔ | ✔ | ✔ | ✔ | ~ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
-+---------------------------+-------------+------------+----------+---------+----------+-----------+-----------+----------------+----------+----------+-----------+-----------------+--------+
-| udts: table variables | ~ | ~ | ~ | ~ | ~ | ✔ | ~ | ~ | ~ | ✗ | ✔ | ✗ | ~ |
-+---------------------------+-------------+------------+----------+---------+----------+-----------+-----------+----------------+----------+----------+-----------+-----------------+--------+
-| stack abstractions | ~ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ~ | ✗ | ~ | ✔ |
-+---------------------------+-------------+------------+----------+---------+----------+-----------+-----------+----------------+----------+----------+-----------+-----------------+--------+
-| lua callables from C(++) | ~ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ~ |
-+---------------------------+-------------+------------+----------+---------+----------+-----------+-----------+----------------+----------+----------+-----------+-----------------+--------+
-| function binding | ~ | ✔ | ✔ | ✔ | ✔ | ✔ | ~ | ~ | ✔ | ~ | ~ | ~ | ✔ |
-+---------------------------+-------------+------------+----------+---------+----------+-----------+-----------+----------------+----------+----------+-----------+-----------------+--------+
-| protected call | ~ | ✗ | ~ | ~ | ~ | ✔ | ~ | ✔ | ~ | ~ | ~ | ~ | ~ |
-+---------------------------+-------------+------------+----------+---------+----------+-----------+-----------+----------------+----------+----------+-----------+-----------------+--------+
-| multi-return | ~ | ✗ | ✔ | ✔ | ✔ | ✔ | ~ | ✔ | ✔ | ~ | ✔ | ~ | ✗ |
-+---------------------------+-------------+------------+----------+---------+----------+-----------+-----------+----------------+----------+----------+-----------+-----------------+--------+
-| variadic/variant argument | ~ | ✔ | ✔ | ✔ | ✔ | ✔ | ~ | ✔ | ✔ | ~ | ~ | ~ | ✗ |
-+---------------------------+-------------+------------+----------+---------+----------+-----------+-----------+----------------+----------+----------+-----------+-----------------+--------+
-| inheritance | ~ | ✔ | ✔ | ✔ | ✔ | ✔ | ~ | ~ | ✔ | ~ | ✔ | ~ | ✗ |
-+---------------------------+-------------+------------+----------+---------+----------+-----------+-----------+----------------+----------+----------+-----------+-----------------+--------+
-| overloading | ~ | ✗ | ✔ | ✗ | ✗ | ✔ | ✗ | ✗ | ✔ | ✔ | ✔ | ✗ | ✗ |
-+---------------------------+-------------+------------+----------+---------+----------+-----------+-----------+----------------+----------+----------+-----------+-----------------+--------+
-| Lua thread | ~ | ✗ | ~ | ✗ | ✗ | ✔ | ✔ | ✗ | ✔ | ✗ | ✗ | ✔ | ✗ |
-+---------------------------+-------------+------------+----------+---------+----------+-----------+-----------+----------------+----------+----------+-----------+-----------------+--------+
-| coroutines | ~ | ✗ | ~ | ✔ | ✔ | ✔ | ✗ | ✗ | ✔ | ✗ | ✗ | ✔ | ✗ |
-+---------------------------+-------------+------------+----------+---------+----------+-----------+-----------+----------------+----------+----------+-----------+-----------------+--------+
-| no-rtti support | ✔ | ✗ | ✔ | ✗ | ✗ | ✔ | ✔ | ✗ | ✔ | ✔ | ~ | ✔ | ✔ |
-+---------------------------+-------------+------------+----------+---------+----------+-----------+-----------+----------------+----------+----------+-----------+-----------------+--------+
-| no-exception support | ✔ | ✗ | ✔ | ~ | ✗ | ✔ | ✔ | ✗ | ✔ | ✔ | ~ | ✔ | ✔ |
-+---------------------------+-------------+------------+----------+---------+----------+-----------+-----------+----------------+----------+----------+-----------+-----------------+--------+
-| Lua 5.1 | ✔ | ✔ | ✔ | ✔ | ✗ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✗ | ✔ |
-+---------------------------+-------------+------------+----------+---------+----------+-----------+-----------+----------------+----------+----------+-----------+-----------------+--------+
-| Lua 5.2 | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
-+---------------------------+-------------+------------+----------+---------+----------+-----------+-----------+----------------+----------+----------+-----------+-----------------+--------+
-| Lua 5.3 | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
-+---------------------------+-------------+------------+----------+---------+----------+-----------+-----------+----------------+----------+----------+-----------+-----------------+--------+
-| luajit | ✔ | ✔ | ✔ | ✔ | ~ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✗ | ✔ |
-+---------------------------+-------------+------------+----------+---------+----------+-----------+-----------+----------------+----------+----------+-----------+-----------------+--------+
-| distribution | compile | header | both | compile | header | header | compile | compile | header | compile | generated | compile | header |
-+---------------------------+-------------+------------+----------+---------+----------+-----------+-----------+----------------+----------+----------+-----------+-----------------+--------+
-
-
-notes on implementations
-------------------------
-
-Plain C -
-
-* Obviously you can do anything you want with Plain C, but the effort involved is astronomical in comparison to what frameworks offer
-* Does not scale very well (in terms of developer ease of use)
-* Compilation (or package manager use) is obviously required for your platform and required to use ANY of these libraries, but that's okay because all libraries need some version of Lua anyways, so you always have this!
-
-kaguya -
-
-* Table variables / member variables are automatically turned into ``obj:x( value )`` to set and ``obj:x()`` to get
-* Has optional support
-* Inspired coroutine support for Sol
-* Library author (satoren) is a nice guy!
-* C++11/14, or boostified (which makes it C++03 compatible)
-* Class registration is a bit verbose, but not as offensive as OOLua or lua-intf or others
-
-Sol -
-
-* One of the few libraries with optional support!
-* Basically the fastest in almomst all respects: http://sol2.readthedocs.io/en/latest/benchmarks.html
-* Overloading support can get messy with inheritance, see :doc:`here<api/overload>`
-* C++14/"C++1y" (-std=c++14, -std=c++1y, =std=c++1z) flags are used (available since GCC 4.9 and Clang 3.5)
-* Active issues, active individuals
-* Deserves lots of love!
-
-lua-intf -
-
-* Can be both header-only or compiled
-* Has optional support
-* C++11
-* Macro-based registration (strange pseudo-language)
-* Fairly fast in most regards
-* Registering classes/"modules" in using C++ code is extremely verbose
-* In order to chain lookups, one has to glue the keys together (e.g. ``"mykey.mykey2"``) on the ``operator[]`` lookup (e.g., you can't nest them arbitrarily, you have to pre-compose the proper lookup string) (fails miserably for non-string lookups!).
-* Not too shabby!
-
-Selene -
-
-* Table variables / member variables are automatically turned into ``obj:set_x( value )`` to set and ``obj:x()`` to get
-* Registering classes/"modules" using C++ code is extremely verbose, similar to lua-intf's style
-* Eats crap when it comes to performance, most of the time (see :doc:`benchmarks<benchmarks>`)
-* Lots of users (blogpost etc. made it popular), but the Repository is kinda stagnant...
-
-luawrapper -
-
-* Takes the approach of writing and reading tables using ``readVariable`` and ``writeVariable`` functions
-* C++11, no macros!
-* The interface can be clunky (no table-like data structures: most things go though ``readVariable`` / ``writeVariable``)
-* Internal Compiler errors in Visual Studio 2015 - submitted a PR to fix it, hopefully it'll get picked up
-
-SWIG (3.0) -
-
-* Very comprehensive for binding concepts of C++ (classes, variables, etc.) to Lua
-* Helps with literally nothing else (tables, threads, stack abstractions, etc.)
-* Not really a good, full-featured Library...
-* Requires preprocessing step (but it's not a... TERRIBLY complicated preprocessing step); some boilerplate in writing additional classes that you've already declared
-
-luacppinterface -
-
-* The branch that fixes VC++ warnings and introduces some new work has type checker issues, so use the stable branch only
-* No table variable support
-* Actually has tables (but no operator[])
-* Does not support arbitrary keys
-
-luabind -
-
-* One of the older frameworks, but has many people updating it and providing "deboostified" versions
-* Strange in-lua keywords and parsing to allow for classes to be written in lua
- - not sure if good feature; vendor lock-in to that library to depend on this specific class syntax?
-* Comprehensive lua bindings (can even bind "properties")
-* There's some code that produces an ICE in Visual C++: I submitted a fix to the library in the hopes that it'll get accepted
-* Wonky table support: no basic conversion functions on ``luabind::object``; have to push object then use lua API to get what you want
-
-lua-api-pp -
-
-* Compiled, but the recommendation is to add the source files directly to your project
-* Userdata registration with thick setup-macros: LUAPP_USERDATA( ... ) plus a bunch of free functions that take a ``T& self`` argument
- - You can bind member functions directly but only if you override metatable entries
- - Otherwise, COMPLICATED self-registration that makes you wonder why you're using the framework
-* You have to create a context and then call it to start accessing the lua state (adding more boilerplate... thanks)
- - Thankfully, unlike many libraries, it actually has a Table type that can be used semi-easily. FINALLY
-* C++11-ish in some regards
-* Sad face, thanks to the way userdata registration is handled
-
-SLB3 -
-
-* Old code exported to github from dying google code
-* ".NET Style" - to override functionality, derive from class -- boilerplate (isn't that what we're trying to get rid of?)
-* Pointers everywhere: ownership semantics unclear
-* Piss-poor documentation, ugh!
-* Least favorite to work with, for sure!
-
-oolua -
-
-* The syntax for this library. `Go read the docs`_
-* The worst in terms of how to use it: may have docs, but the DSL is extraordinarily crappy with thick, hard-to-debug/hard-to-error-check macros
- - Same problem as lua-api-pp: cannot have the declaration macros anywhere but the toplevel namespace because of template declaration macro
-* Supports not having exceptions or rtti turned on (shiny!)
-* Poor RAII support: default-construct-and-get style (requires some form of initalization to perform a ``get`` of an object, and it's hard to extend)
- - The library author has informed me that he does personally advises individuals do not use the ``Table`` abstraction in OOLua... Do I likewise tell people to consider its table abstractions defunct?
-* Table variables / member variables from C++ are turned into function calls (``get_x`` and ``set_x`` by default)
-
-luwra -
-
-* How do you store stateful functors / lambas? So far, no support for such.
-* Cannot pull functions without first leaving them on the stack: manual cleanup becomes a thing
-* Doesn't understand ``std::function`` conversions and the like (but with some extra code can get it to work)
-* Recently improved by a lot: can chain tables and such, even if performance is a bit sad for that use case
-* When you do manage to set function calls with the macros they are fast (can a template solution do just as good? Sol is going to find out!)
-* No table variable support - get turned into getter/setter functions, similar to kaguya
-* Table variables become class statics (surprising)
-
-.. _Go read the docs: https://oolua.org/docs/index.html
diff --git a/3rdparty/sol2/docs/source/index.rst b/3rdparty/sol2/docs/source/index.rst
deleted file mode 100644
index 77fb8fdf9b6..00000000000
--- a/3rdparty/sol2/docs/source/index.rst
+++ /dev/null
@@ -1,132 +0,0 @@
-.. Sol documentation master file, created by
- sphinx-quickstart on Mon Feb 29 21:49:51 2016.
- You can adapt this file completely to your liking, but it should at least
- contain the root `toctree` directive.
-
-.. image:: sol.png
- :target: https://github.com/ThePhD/sol2
- :alt: sol2 repository
-
-Sol |version|
-=============
-a fast, simple C++ and Lua Binding
-----------------------------------
-
-When you need to hit the ground running with Lua and C++, `Sol`_ is the go-to framework for high-performance binding with an easy to use API.
-
-.. image:: https://travis-ci.org/ThePhD/sol2.svg?branch=develop
- :target: https://travis-ci.org/ThePhD/sol2
- :alt: build status
-
-.. image:: https://badges.gitter.im/chat-sol2/Lobby.svg
- :target: https://gitter.im/chat-sol2/Lobby
- :alt: chat about sol2 on gitter
-
-
-get going:
-----------
-
-.. toctree::
- :maxdepth: 1
- :name: mastertoc
-
- tutorial/all-the-things
- tutorial/tutorial-top
- errors
- compilation
- features
- usertypes
- traits
- api/api-top
- mentions
- benchmarks
- performance
- safety
- exceptions
- rtti
- codecvt
- cmake
- licenses
- origin
-
-
-"I need feature X, maybe you have it?"
---------------------------------------
-Take a look at the :doc:`Features<features>` page: it links to much of the API. You can also just straight up browse the :doc:`api<api/api-top>` or ease in with the :doc:`tutorials<tutorial/tutorial-top>`. To know more about the implementation for usertypes, see :doc:`here<usertypes>` To know how function arguments are handled, see :ref:`this note<function-argument-handling>`. Don't see a feature you want? Send inquiries for support for a particular abstraction to the `issues`_ tracker.
-
-
-the basics:
------------
-
-.. note::
- More examples can be found in the `examples directory`_
-
-
-.. code-block:: c++
- :caption: functions
- :linenos:
-
- #include <sol.hpp>
- #include <cassert>
-
- int main() {
- sol::state lua;
- int x = 0;
- lua.set_function("beep", [&x]{ ++x; });
- lua.script("beep()");
- assert(x == 1);
-
- sol::function beep = lua["beep"];
- beep();
- assert(x == 2);
-
- return 0;
- }
-
-
-.. code-block:: c++
- :caption: linking C++ structures to Lua
- :linenos:
-
- #include <sol.hpp>
- #include <cassert>
-
- struct vars {
- int boop = 0;
-
- int bop () const {
- return boop + 1;
- }
- };
-
- int main() {
- sol::state lua;
- lua.new_usertype<vars>("vars",
- "boop", &vars::boop
- "bop", &vars::bop);
- lua.script("beep = vars.new()\n"
- "beep.boop = 1\n"
- "bopvalue = beep:bop()");
-
- vars& beep = lua["beep"];
- int bopvalue = lua["bopvalue"];
-
- assert(beep.boop == 1);
- assert(lua.get<vars>("beep").boop == 1);
- assert(beep.bop() == 2);
- assert(bopvalue == 2);
-
- return 0;
- }
-
-
-
-Indices and tables
-==================
-
-* :ref:`genindex`
-* :ref:`search`
-
-.. _Sol: https://github.com/ThePhD/sol2
-.. _issues: https://github.com/ThePhD/sol2/issues
-.. _examples directory: https://github.com/ThePhD/sol2/tree/develop/examples \ No newline at end of file
diff --git a/3rdparty/sol2/docs/source/licenses.rst b/3rdparty/sol2/docs/source/licenses.rst
deleted file mode 100644
index f43d97b5e3a..00000000000
--- a/3rdparty/sol2/docs/source/licenses.rst
+++ /dev/null
@@ -1,47 +0,0 @@
-licenses
-========
-
-The following licenses cover all of the code in Sol. Spoiler: they're all `MIT`_ and it's safe to use in commercial code: feel free to copy/paste the below right into your own attributions / licenses file.
-
-Sol - ThePhD/sol2:
-------------------
-
- The MIT License (MIT)
-
- Copyright (c) 2013-2016 Rapptz, ThePhD, and contributors
-
- Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
-
- The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
-
- THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
-
-
-Lua-compat-5.3 - keplerproject/Lua-compat-5.3:
-----------------------------------------------
-
- The MIT License (MIT)
-
- Copyright (c) 2015 Kepler Project.
-
- Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
-
- The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
-
- THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
-
-Lua - Lua.org:
---------------
-
- The MIT License (MIT)
-
- Copyright © 1994–2015 Lua.org, PUC-Rio.
-
- Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
-
- The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
-
- THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
-
-
- .. _MIT: http://opensource.org/licenses/MIT \ No newline at end of file
diff --git a/3rdparty/sol2/docs/source/mentions.rst b/3rdparty/sol2/docs/source/mentions.rst
deleted file mode 100644
index 7ce2a1f3485..00000000000
--- a/3rdparty/sol2/docs/source/mentions.rst
+++ /dev/null
@@ -1,62 +0,0 @@
-mentions
-========
-so does anyone cool use this thing...?
---------------------------------------
-
-First off, feel free to `tell me about your uses!`_
-
-Okay, so the features don't convince you, the documentation doesn't convince you, you want to see what *other* people think about Sol? Well, aside from the well-wishes that come through in the issue tracker, here's a few things floating around about sol2 that I occasionally get pinged about:
-
-`eevee`_ demonstrating the sheer code reduction by using sol2:
-
-
-.. |before| image:: eevee_code_before.jpg
- :target: https://twitter.com/eevee/status/762039984085798913
- :alt: Plain C API
- :align: middle
-
-.. |after| image:: eevee_code_after.jpg
- :target: https://twitter.com/eevee/status/762039984085798913
- :alt: Now with sol2!
- :align: middle
-
-+----------+---------+
-| |before| | |after| |
-+----------+---------+
-
-* The `Multiple Arcade Machine Emulator (MAME)`_ project switched from using LuaBridge to sol2!
- - `The pull request`_ in which it was introduced to the master branch.
-* (CppNow) sol2 was mentioned in a comparison to other scripting languages by ChaiScript developer, Jason Turner (@lefticus), at a conference!
- - `Jason Turner's presentation`_
-* (CppCast) Showed up in CppCast with Elias Daler!
- - `Elias Daler's blog`_
- - `CppCast`_
-* (Eevee) A really nice and neat developer/artist/howaretheysotalented person is attempting to use it for zdoom!
- - `eevee's blog`_
-* (Twitter) Twitter has some people that link it:
- - The image above, `tweeted out by eevee`_
- - Eevee: `"I heartily recommend sol2"`_
- - Elias Daler: `"sol2 saved my life."`_
- - Racod's Lair: `"from outdated LuaBridge to superior #sol2"`_
-* (Reddit) Posts on reddit about it!
- - `sol2's initial reddit release`_
- - `Benchmarking Discussing`_
-* Somehow landed on a Torque3D thread...
- - http://forums.torque3d.org/viewtopic.php?f=32&t=629&p=5246&sid=8e759990ab1ce38a48e896fc9fd62653#p5241
-
-Are you using sol2 for something neat? Want it to be featured here or think it's unfair that ThePhD hasn't found it yet? Well, drop an issue in the repo or send an e-mail!
-
-.. _tell me about your uses!: https://github.com/ThePhD/sol2/issues/189
-.. _eevee: https://twitter.com/eevee
-.. _eevee's blog: https://eev.ee/dev/2016/08/07/weekly-roundup-three-big-things/
-.. _Jason Turner's presentation: https://github.com/lefticus/presentations/blob/master/HowAndWhyToAddScripting.md
-.. _Elias Daler's blog: https://eliasdaler.github.io/cppcast#read-more
-.. _CppCast: http://cppcast.com/2016/07/elias-daler/
-.. _tweeted out by eevee: https://twitter.com/eevee/status/762039984085798913
-.. _"I heartily recommend sol2": https://twitter.com/eevee/status/762040086540144644
-.. _"from outdated LuaBridge to superior #sol2": https://twitter.com/racodslair/status/754031870640267264
-.. _sol2's initial reddit release: https://www.reddit.com/r/cpp/comments/4a8gy7/sol2_lua_c_binding_framework/
-.. _Benchmarking Discussing: https://www.reddit.com/r/cpp/comments/4x82hd/plain_c_versus_lua_libraries_benchmarking_speed/
-.. _"sol2 saved my life.": https://twitter.com/EliasDaler/status/739215685264494593
-.. _Multiple Arcade Machine Emulator (MAME): http://www.mamedev.org/index.php
-.. _The pull request: https://github.com/mamedev/mame/pull/1626
diff --git a/3rdparty/sol2/docs/source/origin.rst b/3rdparty/sol2/docs/source/origin.rst
deleted file mode 100644
index cc2e3d72467..00000000000
--- a/3rdparty/sol2/docs/source/origin.rst
+++ /dev/null
@@ -1,28 +0,0 @@
-origin
-======
-
-In the beginning, there was Sir Dennis Ritchie. And Ritchie saw the void, and outstretched his hand, and commanded "Let there be water." And lo, it was so, and there was the C. And with the C, other entities dared to venture on the void given form. Lord Bjarne Stroustrup too did outstretch his hands and say "Let there be an abundance." And lo, into the sea was cast a double portion of surplus of all the things that swam. And for a while, it was good. But other entities were still curious about what yet lay undefined, and one such pantheon, PUC-RIO, saw that it fitting to create the moon. And with the waters and sea made and the moon cast in a starry night sky, PUC-RIO and Dennis and Stroustrup saw that they did good. They oversaw the moon and the sea and gave sound council and it grew. But as the time grew, humanity grew... discontent. No longer were the simple fishing rods and the flowing tides and the dark sky enough lit by a pale moon, no matter how miraculously they were made, enough. They sought out more.
-
-They sought out the light.
-
-And lo, `Danny Y., Rapptz`_ did stand firm in the sea and cast his hands to the sky and said "Let there be Light!". And in the sky was cast a sun. It was an early sun, a growing sun, and many gathered to its warmth, marveling at a life they never knew. And he saw that it was good...
-
-
-seriously
----------
-
-Sol was originally started by many moon cycles ago to interop with Lua and C++. `Rapptz`_ It was very successful and many rejoiced at having an easy to use abstraction on top of the Lua API. Rapptz continued to make a number of great projects and has been busy with other things, so upon seeing the repository grow stagnant and tired in the last very long while (over a year), `ThePhD`_ forked it into Sol2 and rebooted the code with the hopes of reaching the Milestone and the documentation you have today.
-
-To get to the old repo, head over `here`_.
-
-
-the name
---------
-
-Sol means sun. The moon (Lua) needs a sun, because without it only the bleak night of copy-paste programming and off-by-one errors would prevail.
-
-
-.. _here: https://github.com/Rapptz/sol
-.. _ThePhD: https://github.com/ThePhD
-.. _Danny Y., Rapptz: https://github.com/Rapptz
-.. _Rapptz: https://github.com/Rapptz \ No newline at end of file
diff --git a/3rdparty/sol2/docs/source/performance.rst b/3rdparty/sol2/docs/source/performance.rst
deleted file mode 100644
index 4115e01f5a0..00000000000
--- a/3rdparty/sol2/docs/source/performance.rst
+++ /dev/null
@@ -1,17 +0,0 @@
-getting performance
-===================
-things to make Sol as fast as possible
---------------------------------------
-
-
-As shown by the :doc:`benchmarks<benchmarks>`, Sol is very performant with its abstractions. However, in the case where you need every last drop of performance from Sol, a number of tips and API usage tricks will be documented here. PLEASE benchmark / profile your code before you start invoking these, as some of them trade in readability / clarity for performance.
-
-* If you have a bound function call / bound member function that you are going to call in a very tight, performance-heavy loop, considering using :doc:`sol::c_call<api/c_call>`
-* Be wary of passing by value / reference, and what it means by reading :ref:`this note<function-argument-handling>`.
-* It is currently undocumented that usertypes will "inherit" member function / member variables from bound classes, mostly because the semantics are unclear and it is not the most performant (although it is flexible: you can register base classes after / whenever you want in relation to the derived class, provided that derived class has its bases listed). Specifying all member functions / member variables for the usertype constructor / ``new_usertype`` function call and not relying on base lookup will boost performance of member lookup
-* Use the :doc:`sol::stack_{}<api/stack_reference>` versions of functions in order to achieve maximum performance benefits when doing things like calling a function from Lua and knowing that certain arguments of certain Lua types will be on the stack. This can save you a very small fraction of performance to not copy to the register (but is also more dangerous and usually not terribly worth it).
-* Specifying base classes can make getting the usertype out of Sol a bit slower since we have to check and cast; if you know the exact type wherever you're retrieving it, considering not specifying the bases, retrieving the exact type from Sol, and then casting to a base type yourself
-* Member variables can sometimes cost an extra lookup to occur within the Lua system (as mentioned :doc:`bottom of the usertype page<api/usertype>`); until we find out a safe way around this, member variables will always incur that extra lookup cost
-
-
-That's it as far as different performance options are avilable to make Sol run faster. Again, please make sure to invoke these only when you know Sol is the bottleneck. If you find some form of the performance unacceptable to you, also feel free to open an issue at the github. \ No newline at end of file
diff --git a/3rdparty/sol2/docs/source/rtti.rst b/3rdparty/sol2/docs/source/rtti.rst
deleted file mode 100644
index 91aad3e939b..00000000000
--- a/3rdparty/sol2/docs/source/rtti.rst
+++ /dev/null
@@ -1,14 +0,0 @@
-run-time type information (rtti)
-================================
-because somebody's going to want to shut this off, too...
----------------------------------------------------------
-
-Sol does not use RTTI anymore.
-
-*THE BELOW IS NO LONGER NEEDED.*
-
-Not compiling with C++'s run-time type information? Do a ``#define SOL_NO_RTII`` before you include ``sol.hpp`` or define ``SOL_NO_RTTI`` on your command line. Be sure to understand the :ref:`implications<usertype-inheritance>` of doing so if you also turn off exceptions.
-
-If you come across bugs or can't compile because there's a stray `typeid` or `typeinfo` that wasn't hidden behind a ``#ifndef SOL_NO_RTTI``, please file `an issue`_ or even make a pull request so it can be fixed for everyone.
-
-.. _an issue: https://github.com/ThePhD/sol2/issues \ No newline at end of file
diff --git a/3rdparty/sol2/docs/source/safety.rst b/3rdparty/sol2/docs/source/safety.rst
deleted file mode 100644
index 321c37aaa70..00000000000
--- a/3rdparty/sol2/docs/source/safety.rst
+++ /dev/null
@@ -1,22 +0,0 @@
-safety
-======
-
-Sol was designed to be correct and fast, and in the pursuit of both uses the regular ``lua_to{x}`` functions of Lua rather than the checking versions (``lua_check{X}``) functions. The API defaults to paranoidly-safe alternatives if you have a ``#define SOL_CHECK_ARGUMENTS`` before you include Sol, or if you pass the ``SOL_CHECK_ARGUMENTS`` define on the build command for your build system. By default, it is off and remains off unless you define this, even in debug mode. The same goes for ``#define SOL_SAFE_USERTYPE``.
-
-Note that you can obtain safety with regards to functions you bind by using the :doc:`protect<api/protect>` wrapper around function/variable bindings you set into Lua. Additionally, you can have basic boolean checks when using the API by just converting to a :doc:`sol::optional\<T><api/optional>` when necessary for getting things out of Lua and for function arguments.
-
-``SOL_SAFE_USERTYPE`` triggers the following change:
- * If the userdata to a usertype function is nil, will trigger an error instead of letting things go through and letting the system segfault.
-
-``SOL_CHECK_ARGUMENTS`` triggers the following changes:
- * ``sol::stack::get`` (used everywhere) defaults to using ``sol::stack::check_get`` and dereferencing the argument. It uses ``sol::type_panic`` as the handler if something goes wrong.
- * ``sol::stack::call`` and its variants will, if no templated boolean is specified, check all of the arguments for a function call.
- * If ``SOL_SAFE_USERTYPE`` is not defined, it gets defined to turn being on.
-
-Tests are compiled with this on to ensure everything is going as expected. Remember that if you want these features, you must explicitly turn them on.
-
-Finally, some warnings that may help with errors when working with Sol:
-
-.. warning::
-
- Do NOT save the return type of a :ref:`function_result<function-result>` with ``auto``, as in ``auto numwoof = woof(20);``, and do NOT store it anywhere. See :ref:`here<function-result-warning>`. \ No newline at end of file
diff --git a/3rdparty/sol2/docs/source/sol.png b/3rdparty/sol2/docs/source/sol.png
deleted file mode 100644
index eedee2ed3d0..00000000000
--- a/3rdparty/sol2/docs/source/sol.png
+++ /dev/null
Binary files differ
diff --git a/3rdparty/sol2/docs/source/sol.psd b/3rdparty/sol2/docs/source/sol.psd
deleted file mode 100644
index 84865d5198b..00000000000
--- a/3rdparty/sol2/docs/source/sol.psd
+++ /dev/null
Binary files differ
diff --git a/3rdparty/sol2/docs/source/traits.rst b/3rdparty/sol2/docs/source/traits.rst
deleted file mode 100644
index b064223be08..00000000000
--- a/3rdparty/sol2/docs/source/traits.rst
+++ /dev/null
@@ -1,15 +0,0 @@
-customization traits
-====================
-
-These are customization points within the library to help you make sol2 work for the types in your framework and types.
-
-To learn more about various customizable traits, visit:
-
-* :ref:`containers detection trait<container-detection>`
- - This is how to work with containers when you have an compiler error when serializing a type that has ``begin`` and ``end`` functions but isn't exactly a container.
-* :doc:`unique usertype (custom pointer) traits<api/unique_usertype_traits>`
- - This is how to deal with unique usertypes, e.g. ``boost::shared_ptr``, reference-counted pointers, etc.
- - Useful for custom pointers from all sorts of frameworks or handle types that employ very specific kinds of destruction semantics and access.
-* :doc:`customization point tutorial<tutorial/customization>`
- - This is how to customize a type to work with sol2.
- - Can be used for specializations to push strings and other class types that are not natively ``std::string`` or ``const char*``.
diff --git a/3rdparty/sol2/docs/source/tutorial/all-the-things.rst b/3rdparty/sol2/docs/source/tutorial/all-the-things.rst
deleted file mode 100644
index 3b764b8d2e9..00000000000
--- a/3rdparty/sol2/docs/source/tutorial/all-the-things.rst
+++ /dev/null
@@ -1,628 +0,0 @@
-tutorial: quick 'n' dirty
-=========================
-
-These are all the things. Use your browser's search to find things you want.
-
-You'll need to ``#include <sol.hpp>``/``#include "sol.hpp"`` somewhere in your code. Sol is header-only, so you don't need to compile anything.
-
-opening a state
----------------
-
-.. code-block:: cpp
-
- int main (int argc, char* argv[]) {
- sol::state lua;
- // open some common libraries
- lua.open_libraries(sol::lib::base, sol::lib::package);
- lua.script( "print('bark bark bark!')" );
- }
-
-
-sol::state on lua_State*
-------------------------
-
-For your system/game that already has lua, but you'd like something nice:
-
-.. code-block:: cpp
-
- int pre_existing_system( lua_State* L ) {
- sol::state_view lua(L);
- lua.script( "print('bark bark bark!')" );
- return 0;
- }
-
-
-running lua code
-----------------
-
-.. code-block:: cpp
-
- sol::state lua;
- // load and execute from string
- lua.script("a = 'test'");
- // load and execute from file
- lua.script_file("path/to/luascript.lua");
-
- // run a script, get the result
- int value = lua.script("return 54");
- // value == 54
-
-To check the success of a loading operation:
-
-.. code-block:: cpp
-
- // load file without execute
- sol::load_result script1 = lua.load_file("path/to/luascript.lua");
- script1(); //execute
- // load string without execute
- sol::load_result script2 = lua.load("a = 'test'");
- script2(); //execute
-
- sol::load_result script3 = lua.load("return 24");
- int value2 = script3(); // execute, get return value
- // value2 == 24
-
-
-To check whether a script was successfully run or not (after loading is assumed to be successful):
-
-.. code-block:: cpp
-
- // execute and return result
- sol::protected_function_result result1 = lua.do_string("return 24");
- if (result1.valid()) {
- int value = result1;
- // value == 24
- // yay!
- }
- else {
- // ahhh :c
- }
-
-
-There is also ``lua.do_file("path/to/luascript.lua");``.
-
-set and get variables
----------------------
-
-You can set/get everything.
-
-.. code-block:: cpp
-
- sol::lua_state lua;
-
- lua.open_libraries(sol::lib::base);
-
- // integer types
- lua.set("number", 24);
-
- // floating point numbers
- lua["number2"] = 24.5;
-
- // string types
- lua["important_string"] = "woof woof";
-
- // non-recognized types is stored as userdata
- // is callable, therefore gets stored as a function
- lua["a_function"] = [](){ return 100; };
-
- // make a table
- lua["some_table"] = lua.create_table_wth("value", 24);
-
-
-Equivalent to loading a lua file with:
-
-.. code-block:: lua
-
- number = 24
- number2 = 24.5
- important_string = "woof woof"
- a_function = function () return 100 end
- some_table = { value = 24 }
-
-Retrieve these variables using this syntax:
-
-.. code-block:: cpp
-
- // implicit conversion
- int number = lua["number"];
-
- // explicit get
- auto number2 = lua.get<double>("number2");
-
- // strings too
- std::string important_string = lua["important_string"];
-
- // dig into a table
- int value = lua["some_table"]["value"];
-
- // get a function
- sol::function a_function = lua["a_function"];
- int value_is_100 = a_function();
-
- // get a std::function
- std::function<int()> a_std_function = lua["a_function"];
- int value_is_still_100 = a_std_function();
-
-Retrieve Lua types using ``object`` and other ``sol::`` types.
-
-.. code-block:: cpp
-
- sol::state lua;
-
- // ... everything from before
-
- sol::object number_obj = lua.get<sol::object>( "number" );
- // sol::type::number
- sol::type t1 = number_obj.get_type();
-
- sol::object function_obj = lua[ "a_function" ];
- // sol::type::function
- sol::type t2 = function_obj.get_type();
- bool is_it_really = function_obj.is<std::function<int()>>(); // true
-
- // will not contain data
- sol::optional<int> check_for_me = lua["a_function"];
-
-
-You can erase things by setting it to ``nullptr`` or ``sol::nil``.
-
-.. code-block:: cpp
-
- sol::state lua;
-
- lua.script("exists = 250");
-
- int first_try = lua.get_or( "exists", 322 );
- // first_try == 250
-
- lua.set("exists", sol::nil);
- int second_try = lua.get_or( "exists", 322 );
- // second_try == 322
-
-
-Note that if its a :doc:`userdata/usertype<../api/usertype>` for a C++ type, the destructor will run only when the garbage collector deems it appropriate to destroy the memory. If you are relying on the destructor being run when its set to ``sol::nil``, you're probably committing a mistake.
-
-tables
-------
-
-:doc:`sol::state<../api/state>` is a table too.
-
-.. code-block:: cpp
-
- sol::state lua;
-
- // Raw string literal for easy multiline
- lua.script( R"(
- abc = { [0] = 24 }
- def = {
- ghi = {
- bark = 50,
- woof = abc
- }
- }
- )"
- );
-
- sol::table abc = lua["abc"];
- sol::table def = lua["def"];
- sol::table ghi = lua["def"]["ghi"];
-
- int bark1 = def["ghi"]["bark"];
- int bark2 = lua["def"]["ghi"]["bark"];
- // bark1 == bark2 == 50
-
- int abcval1 = abc[0];
- int abcval2 = ghi["woof"][0];
- // abcval1 == abcval2 == 24
-
-If you're going deep, be safe:
-
-.. code-block:: cpp
-
- sol::state lua;
-
- sol::optional<int> will_not_error = lua["abc"]["DOESNOTEXIST"]["ghi"];
- // will_not_error == sol::nullopt
- int also_will_not_error = lua["abc"]["def"]["ghi"]["jklm"].get_or(25);
- // is 25
-
- // if you don't go safe,
- // will throw (or do at_panic if no exceptions)
- int aaaahhh = lua["boom"]["the_dynamite"];
-
-
-make tables
------------
-
-Make some:
-
-.. code-block:: cpp
-
- sol::state lua;
-
- lua["abc"] = lua.create_table_with(
- 0, 24
- );
-
- lua.create_named_table("def",
- "ghi", lua.create_table_with(
- "bark", 50,
- // can reference other existing stuff too
- "woof", lua["abc"]
- )
- );
-
-Equivalent Lua code:
-
-.. code-block:: lua
-
- abc = { [0] = 24 }
- def = {
- ghi = {
- bark = 50,
- woof = abc
- }
- }
-
-
-You can put anything you want in tables as values or keys, including strings, numbers, functions, other tables.
-
-Note that this idea that things can be nested is important and will help later when you get into :ref:`namespacing<namespacing>`.
-
-
-functions
----------
-
-They're great. Use them:
-
-.. code-block:: cpp
-
- sol::state lua;
-
- lua.script("function f (a, b, c, d) return 1 end");
- lua.script("function g (a, b) return a + b end");
-
- // fixed signature std::function<...>
- std::function<int(int, double, int, std::string)> stdfx = lua["f"];
- // sol::function is often easier:
- // takes a variable number/types of arguments...
- sol::function fx = lua["f"];
-
- int is_one = stdfx(1, 34.5, 3, "bark");
- int is_also_one = fx(1, "boop", 3, "bark");
-
- // call through operator[]
- int is_three = lua["g"](1, 2);
- // is_three == 3
- double is_4_8 = lua["g"](2.4, 2.4);
- // is_4_8 == 4.8
-
-If you need to protect against errors and parser problems and you're not ready to deal with Lua's `longjmp` problems (if you compiled with C), use :doc:`sol::protected_function<../api/protected_function>`.
-
-You can bind member variables as functions too, as well as all KINDS of function-like things:
-
-.. code-block:: cpp
-
- void some_function () {
- std::cout << "some function!" << std::endl;
- }
-
- void some_other_function () {
- std::cout << "some other function!" << std::endl;
- }
-
- struct some_class {
- int variable = 30;
-
- double member_function () {
- return 24.5;
- }
- };
-
- sol::state lua;
- lua.open_libraries(sol::lib::base);
-
- // put an instance of "some_class" into lua
- // (we'll go into more detail about this later
- // just know here that it works and is
- // put into lua as a userdata
- lua.set("sc", some_class());
-
- // binds a plain function
- lua["f1"] = some_function;
- lua.set_function("f2", &some_other_function);
-
- // binds just the member function
- lua["m1"] = &some_class::member_function;
-
- // binds the class to the type
- lua.set_function("m2", &some_class::member_function, some_class{});
-
- // binds just the member variable as a function
- lua["v1"] = &some_class::variable;
-
- // binds class with member variable as function
- lua.set_function("v2", &some_class::variable, some_class{});
-
-The lua code to call these things is:
-
-.. code-block:: lua
-
- f1() -- some function!
- f2() -- some other function!
-
- -- need class instance if you don't bind it with the function
- print(m1(sc)) -- 24.5
- -- does not need class instance: was bound to lua with one
- print(m2()) -- 24.5
-
- -- need class instance if you
- -- don't bind it with the function
- print(v1(sc)) -- 30
- -- does not need class instance:
- -- it was bound with one
- print(v2()) -- 30
-
- -- can set, still
- -- requires instance
- v1(sc, 212)
- -- can set, does not need
- -- class instance: was bound with one
- v2(254)
-
- print(v1(sc)) -- 212
- print(v2()) -- 254
-
-Can use ``sol::readonly( &some_class::variable )`` to make a variable readonly and error if someone tries to write to it.
-
-
-self call
----------
-
-You can pass the 'self' argument through C++ to emulate 'member function' calls in Lua.
-
-.. code-block:: cpp
-
- sol::state lua;
-
- lua.open_libraries(sol::lib::base, sol::lib::package, sol::lib::table);
-
- // a small script using 'self' syntax
- lua.script(R"(
- some_table = { some_val = 100 }
-
- function some_table:add_to_some_val(value)
- self.some_val = self.some_val + value
- end
-
- function print_some_val()
- print("some_table.some_val = " .. some_table.some_val)
- end
- )");
-
- // do some printing
- lua["print_some_val"]();
- // 100
-
- sol::table self = lua["some_table"];
- self["add_to_some_val"](self, 10);
- lua["print_some_val"]();
-
-
-
-multiple returns from lua
--------------------------
-
-.. code-block:: cpp
-
- sol::state lua;
-
- lua.script("function f (a, b, c) return a, b, c end");
-
- std::tuple<int, int, int> result;
- result = lua["f"](100, 200, 300);
- // result == { 100, 200, 300 }
- int a;
- int b;
- std::string c;
- sol::tie( a, b, c ) = lua["f"](100, 200, "bark");
- // a == 100
- // b == 200
- // c == "bark"
-
-
-multiple returns to lua
------------------------
-
-.. code-block:: cpp
-
- sol::state lua;
-
- lua["f"] = [](int a, int b, sol::object c) {
- // sol::object can be anything here: just pass it through
- return std::make_tuple( a, b, c );
- };
-
- std::tuple<int, int, int> result = lua["f"](100, 200, 300);
- // result == { 100, 200, 300 }
-
- std::tuple<int, int, std::string> result2;
- result2 = lua["f"](100, 200, "BARK BARK BARK!");
- // result2 == { 100, 200, "BARK BARK BARK!" }
-
- int a, int b;
- std::string c;
- sol::tie( a, b, c ) = lua["f"](100, 200, "bark");
- // a == 100
- // b == 200
- // c == "bark"
-
-
-C++ classes from C++
---------------------
-
-Everything that is not a:
-
- * primitive type: ``bool``, ``char/short/int/long/long long``, ``float/double``
- * string type: ``std::string``, ``const char*``
- * function type: function pointers, ``lua_CFunction``, ``std::function``, :doc:`sol::function/sol::protected_function<../api/function>`, :doc:`sol::coroutine<../api/coroutine>`, member variable, member function
- * designated sol type: :doc:`sol::table<../api/table>`, :doc:`sol::thread<../api/thread>`, :doc:`sol::error<../api/error>`, :doc:`sol::object<../api/object>`
- * transparent argument type: :doc:`sol::variadic_arg<../api/variadic_args>`, :doc:`sol::this_state<../api/this_state>`
- * usertype<T> class: :doc:`sol::usertype<../api/usertype>`
-
-Is set as a :doc:`userdata + usertype<../api/usertype>`.
-
-.. code-block:: cpp
-
- struct Doge {
- int tailwag = 50;
- };
-
- Doge dog{};
-
- // Copy into lua: destroyed by Lua VM during garbage collection
- lua["dog"] = dog;
- // OR: move semantics - will call move constructor if present instead
- // Again, owned by Lua
- lua["dog"] = std::move( dog );
- lua["dog"] = Doge{};
- lua["dog"] = std::make_unique<Doge>();
- lua["dog"] = std::make_shared<Doge>();
- // Identical to above
-
- Doge dog2{};
-
- lua.set("dog", dog2);
- lua.set("dog", std::move(dog2));
- lua.set("dog", Doge{});
- lua.set("dog", std::unique_ptr<Doge>(new Doge()));
- lua.set("dog", std::shared_ptr<Doge>(new Doge()));
-
-``std::unique_ptr``/``std::shared_ptr``'s reference counts / deleters will :doc:`be respected<../api/unique_usertype_traits>`. If you want it to refer to something, whose memory you know won't die in C++, do the following:
-
-.. code-block:: cpp
-
- struct Doge {
- int tailwag = 50;
- };
-
- sol::state lua;
- lua.open_libraries(sol::lib::base);
-
- Doge dog{}; // Kept alive somehow
-
- // Later...
- // The following stores a reference, and does not copy/move
- // lifetime is same as dog in C++
- // (access after it is destroyed is bad)
- lua["dog"] = &dog;
- // Same as above: respects std::reference_wrapper
- lua["dog"] = std::ref(dog);
- // These two are identical to above
- lua.set( "dog", &dog );
- lua.set( "dog", std::ref( dog ) );
-
-Get userdata in the same way as everything else:
-
-.. code-block:: cpp
-
- struct Doge {
- int tailwag = 50;
- };
-
- sol::state lua;
- lua.open_libraries(sol::lib::base);
-
- Doge& dog = lua["dog"]; // References Lua memory
- Doge* dog_pointer = lua["dog"]; // References Lua memory
- Doge dog_copy = lua["dog"]; // Copies, will not affect lua
-
-Note that you can change the data of usertype variables and it will affect things in lua if you get a pointer or a reference from Sol:
-
-.. code-block:: cpp
-
- struct Doge {
- int tailwag = 50;
- };
-
- sol::state lua;
- lua.open_libraries(sol::lib::base);
-
- Doge& dog = lua["dog"]; // References Lua memory
- Doge* dog_pointer = lua["dog"]; // References Lua memory
- Doge dog_copy = lua["dog"]; // Copies, will not affect lua
-
- dog_copy.tailwag = 525;
- // Still 50
- lua.script("assert(dog.tailwag == 50)");
-
- dog.tailwag = 100;
- // Now 100
- lua.script("assert(dog.tailwag == 100)");
-
-
-C++ classes put into Lua
-------------------------
-
-See this :doc:`section here<cxx-in-lua>` and after perhaps see if :doc:`simple usertypes suit your needs<../api/simple_usertype>`. Also check out some `a basic example`_, `special functions`_ and `initializers`_,
-
-
-.. _namespacing:
-
-namespacing
------------
-
-You can emulate namespacing by having a table and giving it the namespace names you want before registering enums or usertypes:
-
-.. code-block:: cpp
-
- struct my_class {
- int b = 24;
-
- int f () const {
- return 24;
- }
-
- void g () {
- ++b;
- }
- };
-
- sol::state lua;
- lua.open_libraries();
-
- // set up table
- sol::table bark = lua.create_named_table("bark");
-
- bark.new_usertype<my_class>( "my_class",
- "f", &my_class::f,
- "g", &my_class::g
- ); // the usual
-
- // 'bark' namespace
- lua.script("obj = bark.my_class.new()" );
- lua.script("obj:g()");
- my_class& obj = lua["obj"];
- // obj.b == 25
-
-
-This technique can be used to register namespace-like functions and classes. It can be as deep as you want. Just make a table and name it appropriately, in either Lua script or using the equivalent Sol code. As long as the table FIRST exists (e.g., make it using a script or with one of Sol's methods or whatever you like), you can put anything you want specifically into that table using :doc:`sol::table's<../api/table>` abstractions.
-
-advanced
---------
-
-Some more advanced things you can do/read about:
- * :doc:`metatable manipulations<../api/metatable_key>` allow a user to change how indexing, function calls, and other things work on a single type.
- * :doc:`ownership semantics<ownership>` are described for how lua deals with (raw) pointers.
- * :doc:`stack manipulation<../api/stack>` to safely play with the stack. You can also define customization points for ``stack::get``/``stack::check``/``stack::push`` for your type.
- * :doc:`make_reference/make_object convenience function<../api/make_reference>` to get the same benefits and conveniences as the low-level stack API but put into objects you can specify.
- * :doc:`stack references<../api/stack_reference>` to have zero-overhead Sol abstractions while not copying to the Lua registry.
- * :doc:`unique usertype traits<../api/unique_usertype_traits>` allows you to specialize handle/RAII types from other frameworks, like boost, and Unreal, to work with Sol.
- * :doc:`variadic arguments<../api/variadic_args>` in functions with ``sol::variadic_args``.
- * :doc:`this_state<../api/this_state>` to get the current ``lua_State*``.
- * :doc:`resolve<../api/resolve>` overloads in case you have overloaded functions; a cleaner casting utility.
-
-.. _a basic example: https://github.com/ThePhD/sol2/blob/develop/examples/usertype.cpp
-.. _special functions: https://github.com/ThePhD/sol2/blob/develop/examples/usertype_special_functions.cpp
-.. _initializers: https://github.com/ThePhD/sol2/blob/develop/examples/usertype_initializers.cpp
-
diff --git a/3rdparty/sol2/docs/source/tutorial/customization.rst b/3rdparty/sol2/docs/source/tutorial/customization.rst
deleted file mode 100644
index 5479c804115..00000000000
--- a/3rdparty/sol2/docs/source/tutorial/customization.rst
+++ /dev/null
@@ -1,117 +0,0 @@
-adding your own types
-=====================
-
-Sometimes, overriding Sol to make it handle certain ``struct``'s and ``class``'es as something other than just userdata is desirable. The way to do this is to take advantage of the 4 customization points for Sol. These are ``sol::lua_size<T>``, ``sol::stack::pusher<T, C>``, ``sol::stack::getter<T, C>``, ``sol::stack::checker<T, sol::type t, C>``.
-
-These are template class/structs, so you'll override them using a technique C++ calls *class/struct specialization*. Below is an example of a struct that gets broken apart into 2 pieces when going in the C++ --> Lua direction, and then pulled back into a struct when going in the Lua --> C++:
-
-.. code-block:: cpp
- :caption: two_things.hpp
- :name: customization-overriding
-
- #include <sol.hpp>
-
- struct two_things {
- int a;
- bool b;
- };
-
- namespace sol {
-
- // First, the expected size
- // Specialization of a struct
- // We expect 2, so use 2
- template <>
- struct lua_size<two_things> : std::integral_constant<int, 2> {};
-
- // Now, specialize various stack structures
- namespace stack {
-
- template <>
- struct checker<two_things> {
- template <typename Handler>
- static bool check(lua_State* L, int index, Handler&& handler, record& tracking) {
- // indices can be negative to count backwards from the top of the stack,
- // rather than the bottom up
- // to deal with this, we adjust the index to
- // its absolute position using the lua_absindex function
- int absolute_index = lua_absindex(L, index);
- // Check first and second second index for being the proper types
- bool success = stack::check<int>(L, absolute_index - 1, handler)
- && stack::check<bool>(L, absolute_index, handler);
- tracking.use(2);
- return success;
- }
- };
-
- template <>
- struct getter<two_things> {
- static two_things get(lua_State* L, int index, record& tracking) {
- int absolute_index = lua_absindex(L, index);
- // Get the first element
- int a = stack::get<int>(L, absolute_index - 1);
- // Get the second element,
- // in the +1 position from the first
- bool b = stack::get<bool>(L, absolute_index);
- // we use 2 slots, each of the previous takes 1
- tracking.use(2);
- return two_things{ a, b };
- }
- };
-
- template <>
- struct pusher<two_things> {
- static int push(lua_State* L, const two_things& things) {
- int amount = stack::push(L, things.a);
- // amount will be 1: int pushes 1 item
- amount += stack::push(L, things.b);
- // amount 2 now, since bool pushes a single item
- // Return 2 things
- return amount;
- }
- };
-
- }
- }
-
-
-This is the base formula that you can follow to extend to your own classes. Using it in the rest of the library should then be seamless:
-
-.. code-block:: cpp
- :caption: customization: using it
- :name: customization-using
-
- #include <sol.hpp>
- #include <two_things.hpp>
-
- int main () {
-
- sol::state lua;
-
- // Create a pass-through style of function
- lua.script("function f ( a, b ) return a, b end");
-
- // get the function out of Lua
- sol::function f = lua["f"];
-
- two_things things = f(two_things{24, true});
- // things.a == 24
- // things.b == true
-
- return 0;
- }
-
-
-And that's it!
-
-A few things of note about the implementation: First, there's an auxiliary parameter of type :doc:`sol::stack::record<../api/stack>` for the getters and checkers. This keeps track of what the last complete operation performed. Since we retrieved 2 members, we use ``tracking.use(2);`` to indicate that we used 2 stack positions (one for ``bool``, one for ``int``). The second thing to note here is that we made sure to use the ``index`` parameter, and then proceeded to add 1 to it for the next one.
-
-You can make something pushable into Lua, but not get-able in the same way if you only specialize one part of the system. If you need to retrieve it (as a return using one or multiple values from Lua), you should specialize the ``sol::stack::getter`` template class and the ``sol::stack::checker`` template class. If you need to push it into Lua at some point, then you'll want to specialize the ``sol::stack::pusher`` template class. The ``sol::lua_size`` template class trait needs to be specialized for both cases, unless it only pushes 1 item, in which case the default implementation will assume 1.
-
-.. note::
-
- It is important to note here that the ``getter``, ``pusher`` and ``checker`` differentiate between a type ``T`` and a pointer to a type ``T*``. This means that if you want to work purely with, say, a ``T*`` handle that does not have the same semantics as just ``T``, you may need to specify checkers/getters/pushers for both ``T*`` and ``T``. The checkers for ``T*`` forward to the checkers for ``T``, but the getter for ``T*`` does not forward to the getter for ``T`` (e.g., because of ``int*`` not being quite the same as ``int``).
-
-In general, this is fine since most getters/checkers only use 1 stack point. But, if you're doing more complex nested classes, it would be useful to use ``tracking.last`` to understand how many stack indices the last getter/checker operation did and increment it by ``index + tracking.last`` after using a ``stack::check<..>( L, index, tracking)`` call.
-
-You can read more about the structs themselves :ref:`over on the API page for stack<extension_points>`, and if there's something that goes wrong or you have anymore questions, please feel free to drop a line on the Github Issues page or send an e-mail! \ No newline at end of file
diff --git a/3rdparty/sol2/docs/source/tutorial/cxx-in-lua.rst b/3rdparty/sol2/docs/source/tutorial/cxx-in-lua.rst
deleted file mode 100644
index dac47dfb228..00000000000
--- a/3rdparty/sol2/docs/source/tutorial/cxx-in-lua.rst
+++ /dev/null
@@ -1,138 +0,0 @@
-C++ in Lua
-==========
-
-Using user defined types ("usertype"s, or just "udt"s) is simple with Sol. If you don't call any member variables or functions, then you don't even have to 'register' the usertype at all: just pass it through. But if you want variables and functions on your usertype inside of Lua, you need to register it. We're going to give a short example here that includes a bunch of information on how to work with things.
-
-Take this ``player`` struct in C++ in a header file:
-
-.. code-block:: cpp
- :caption: test_player.hpp
-
- struct player {
- public:
- int bullets;
- int speed;
-
- player()
- : player(3, 100) {
-
- }
-
- player(int ammo)
- : player(ammo, 100) {
-
- }
-
- player(int ammo, int hitpoints)
- : bullets(ammo), hp(hitpoints) {
-
- }
-
- void boost () {
- speed += 10;
- }
-
- bool shoot () {
- if (bullets < 1)
- return false;
- --bullets;
- return true;
- }
-
- void set_hp(int value) {
- hp = value;
- }
-
- int get_hp() const {
- return hp;
- }
-
- private:
- int hp;
- };
-
-
-It's a fairly minimal class, but we don't want to have to rewrite this with metatables in Lua. We want this to be part of Lua easily. The following is the Lua code that we'd like to have work properly:
-
-.. code-block:: lua
- :caption: player_script.lua
-
- -- call single argument integer constructor
- p1 = player.new(2)
-
- -- p2 is still here from being
- -- set with lua["p2"] = player(0);
- -- in cpp file
- local p2shoots = p2:shoot()
- assert(not p2shoots)
- -- had 0 ammo
-
- -- set variable property setter
- p1.hp = 545;
- -- get variable through property getter
- print(p1.hp);
-
- local did_shoot_1 = p1:shoot()
- print(did_shoot_1)
- print(p1.bullets)
- local did_shoot_2 = p1:shoot()
- print(did_shoot_2)
- print(p1.bullets)
- local did_shoot_3 = p1:shoot()
- print(did_shoot_3)
-
- -- can read
- print(p1.bullets)
- -- would error: is a readonly variable, cannot write
- -- p1.bullets = 20
-
- p1:boost()
-
-To do this, you bind things using the ``new_usertype`` and ``set_usertype`` methods as shown below. These methods are on both :doc:`table<../api/table>` and :doc:`state(_view)<../api/state>`, but we're going to just use it on ``state``:
-
-.. code-block:: cpp
- :caption: player_script.cpp
-
- #include <sol.hpp>
-
- int main () {
- sol::state lua;
-
- // note that you can set a
- // userdata before you register a usertype,
- // and it will still carry
- // the right metatable if you register it later
-
- // set a variable "p2" of type "player" with 0 ammo
- lua["p2"] = player(0);
-
- // make usertype metatable
- lua.new_usertype<player>( "player",
-
- // 3 constructors
- sol::constructors<sol::types<>, sol::types<int>, sol::types<int, int>>(),
-
- // typical member function that returns a variable
- "shoot", &player::shoot,
- // typical member function
- "boost", &player::boost,
-
- // gets or set the value using member variable syntax
- "hp", sol::property(&player::get_hp, &player::set_hp),
-
- // read and write variable
- "speed", &player::speed,
- // can only read from, not write to
- "bullets", sol::readonly( &player::bullets )
- );
-
- lua.script_file("player_script.lua");
- }
-
-That script should run fine now, and you can observe and play around with the values. Even more stuff :doc:`you can do<../api/usertype>` is described elsewhere, like initializer functions (private constructors / destructors support), "static" functions callable with ``name.my_function( ... )``, and overloaded member functions. You can even bind global variables (even by reference with ``std::ref``) with ``sol::var``. There's a lot to try out!
-
-This is a powerful way to allow reuse of C++ code from Lua beyond just registering functions, and should get you on your way to having more complex classes and data structures! In the case that you need more customization than just usertypes, however, you can customize Sol to behave more fit to your desires by using the desired :doc:`customization and extension structures<customization>`.
-
-You can check out this code and more complicated code at the `examples directory`_ by looking at the ``usertype_``-prefixed examples.
-
-.. _examples directory: https://github.com/ThePhD/sol2/tree/develop/examples \ No newline at end of file
diff --git a/3rdparty/sol2/docs/source/tutorial/existing.rst b/3rdparty/sol2/docs/source/tutorial/existing.rst
deleted file mode 100644
index 89a83f8078d..00000000000
--- a/3rdparty/sol2/docs/source/tutorial/existing.rst
+++ /dev/null
@@ -1,27 +0,0 @@
-integrating into existing code
-==============================
-
-If you're already using lua and you just want to use ``sol`` in some places, you can use ``state_view``:
-
-.. code-block:: cpp
- :linenos:
- :caption: using state_view
- :name: state-view-snippet
-
- void something_in_my_system (lua_State* L) {
- // start using Sol with a pre-existing system
- sol::state_view lua(L); // non-owning
-
- lua.script("print('bark bark bark!')");
-
- sol::table expected_table(L); // get the table off the top of the stack
- // start using it...
- }
-
-:doc:`sol::state_view<../api/state>` is exactly like ``sol::state``, but it doesn't manage the lifetime of a ``lua_State*``. Therefore, you get all the goodies that come with a ``sol::state`` without any of the ownership implications. Sol has no initialization components that need to deliberately remain alive for the duration of the program. It's entirely self-containing and uses lua's garbage collectors and various implementation techniques to require no state C++-side. After you do that, all of the power of `Sol` is available to you, and then some!
-
-You may also want to call ``require`` and supply a string of a script file or something that returns an object that you set equal to something in C++. For that, you can use the :ref:`require functionality<state-require-function>`.
-
-Remember that Sol can be as lightweight as you want it: almost all of Sol's types take the ``lua_State*`` argument and then a second ``int index`` stack index argument, meaning you can use :doc:`tables<../api/table>`, :doc:`lua functions<../api/function>`, :doc:`coroutines<../api/coroutine>`, and other reference-derived objects that expose the proper constructor for your use. You can also set :doc:`usertypes<../api/usertype>` and other things you need without changing your entire architecture.
-
-Note that you can also make non-standard pointer and reference types with custom reference counting and such also play nice with the system. See :doc:`unique_usertype_traits\<T><../api/unique_usertype_traits>` to see how! Custom types is also mentioned in the :doc:`customization tutorial<customization>`. \ No newline at end of file
diff --git a/3rdparty/sol2/docs/source/tutorial/functions.rst b/3rdparty/sol2/docs/source/tutorial/functions.rst
deleted file mode 100644
index 5fa8d823fd3..00000000000
--- a/3rdparty/sol2/docs/source/tutorial/functions.rst
+++ /dev/null
@@ -1,341 +0,0 @@
-functions and You
-=================
-
-Sol can register all kinds of functions. Many are shown in the :doc:`quick 'n' dirty<all-the-things>`, but here we will discuss many of the additional ways you can register functions into a sol-wrapped Lua system.
-
-Setting a new function
-----------------------
-
-Given a C++ function, you can drop it into Sol in several equivalent ways, working similar to how :ref:`setting variables<writing-main-cpp>` works:
-
-.. code-block:: cpp
- :linenos:
- :caption: Registering C++ functions
- :name: writing-functions
-
- #include <sol.hpp>
-
- std::string my_function( int a, std::string b ) {
- // Create a string with the letter 'D' "a" times,
- // append it to 'b'
- return b + std::string( 'D', a );
- }
-
- int main () {
-
- sol::state lua;
-
- lua["my_func"] = my_function; // way 1
- lua.set("my_func", my_function); // way 2
- lua.set_function("my_func", my_function); // way 3
-
- // This function is now accessible as 'my_func' in
- // lua scripts / code run on this state:
- lua.script("some_str = my_func(1, "Da");
-
- // Read out the global variable we stored in 'some_str' in the
- // quick lua code we just executed
- std::string some_str = lua["some_str"];
- // some_str == "DaD"
- }
-
-The same code works with all sorts of functions, from member function/variable pointers you have on a class as well as lambdas:
-
-.. code-block:: cpp
- :linenos:
- :caption: Registering C++ member functions
- :name: writing-member-functions
-
- struct my_class {
- int a = 0;
-
- my_class(int x) : a(x) {
-
- }
-
- int func() {
- ++a; // increment a by 1
- return a;
- }
- };
-
- int main () {
-
- sol::state lua;
-
- // Here, we are binding the member function and a class instance: it will call the function on
- // the given class instance
- lua.set_function("my_class_func", &my_class::func, my_class());
-
- // We do not pass a class instance here:
- // the function will need you to pass an instance of "my_class" to it
- // in lua to work, as shown below
- lua.set_function("my_class_func_2", &my_class::func);
-
- // With a pre-bound instance:
- lua.script(R"(
- first_value = my_class_func()
- second_value = my_class_func()
- )");
- // first_value == 1
- // second_value == 2
-
- // With no bound instance:
- lua.set("obj", my_class(24));
- // Calls "func" on the class instance
- // referenced by "obj" in Lua
- lua.script(R"(
- third_value = my_class_func_2(obj)
- fourth_value = my_class_func_2(obj)
- )");
- // first_value == 25
- // second_value == 26
- }
-
-Member class functions and member class variables will both be turned into functions when set in this manner. You can get intuitive variable with the ``obj.a = value`` access after this section when you learn about :doc:`usertypes to have C++ in Lua<cxx-in-lua>`, but for now we're just dealing with functions!
-
-
-Another question a lot of people have is about function templates. Function templates -- member functions or free functions -- cannot be registered because they do not exist until you instantiate them in C++. Therefore, given a templated function such as:
-
-.. code-block:: cpp
- :linenos:
- :caption: A C++ templated function
- :name: writing-templated-functions-the-func
-
- template <typename A, typename B>
- auto my_add( A a, B b ) {
- return a + b;
- }
-
-
-You must specify all the template arguments in order to bind and use it, like so:
-
-.. code-block:: cpp
- :linenos:
- :caption: Registering function template instantiations
- :name: writing-templated-functions
-
-
- int main () {
-
- sol::state lua;
-
- // adds 2 integers
- lua["my_int_add"] = my_add<int, int>;
-
- // concatenates 2 strings
- lua["my_string_combine"] = my_add<std::string, std::string>;
-
- lua.script("my_num = my_int_add(1, 2)");
- int my_num = lua["my_num"];
- // my_num == 3
-
- lua.script("my_str = my_string_combine('bark bark', ' woof woof')");
- std::string my_str = lua["my_str"];
- // my_str == "bark bark woof woof"
- }
-
-Notice here that we bind two separate functions. What if we wanted to bind only one function, but have it behave differently based on what arguments it is called with? This is called Overloading, and it can be done with :doc:`sol::overload<../api/overload>` like so:
-
-.. code-block:: cpp
- :linenos:
- :caption: Registering C++ function template instantiations
- :name: writing-templated-functions-overloaded
-
-
- int main () {
-
- sol::state lua;
-
- // adds 2 integers
- lua["my_combine"] = sol::overload( my_add<int, int>, my_add<std::string, std::string> );
-
- lua.script("my_num = my_combine(1, 2)");
- lua.script("my_str = my_combine('bark bark', ' woof woof')");
- int my_num = lua["my_num"];
- std::string my_str = lua["my_str"];
- // my_num == 3
- // my_str == "bark bark woof woof"
- }
-
-This is useful for functions which can take multiple types and need to behave differently based on those types. You can set as many overloads as you want, and they can be of many different types.
-
-.. note::
-
- Function object ``obj`` -- a struct with a ``return_type operator()( ... )`` member defined on them, like all C++ lambdas -- are not interpreted as functions when you use ``set`` for ``mytable.set( key, value )``. This only happens automagically with ``mytable[key] = obj``. To be explicit about wanting a struct to be interpreted as a function, use ``mytable.set_function( key, func_value );``. You can be explicit about wanting a function as well by using the :doc:`sol::as_function<../api/as_function>` call.
-
-
-Getting a function from Lua
----------------------------
-
-There are 2 ways to get a function from Lua. One is with :doc:`sol::function<../api/function>` and the other is a more advanced wrapper with :doc:`sol::protected_function<../api/protected_function>`. Use them to retrieve callables from Lua and call the underlying function, in two ways:
-
-.. code-block:: cpp
- :linenos:
- :caption: Retrieving a sol::function
- :name: reading-functions
-
- int main () {
-
- sol::state lua;
-
- lua.script(R"(
- function f (a)
- return a + 5
- end
- )");
-
- // Get and immediately call
- int x = lua["f"](30);
- // x == 35
-
- // Store it into a variable first, then call
- sol::function f = lua["f"];
- int y = f(20);
- // y == 25
- }
-
-You can get anything that's a callable in Lua, including C++ functions you bind using ``set_function`` or similar. ``sol::protected_function`` behaves similarly to ``sol::function``, but has a :ref:`error_handler<protected-function-error-handler>` variable you can set to a Lua function. This catches all errors and runs them through the error-handling function:
-
-
-.. code-block:: cpp
- :linenos:
- :caption: Retrieving a sol::protected_function
- :name: reading-protected-functions
-
- int main () {
- sol::state lua;
-
- lua.script(R"(
- function handler (message)
- return "Handled this message: " .. message
- end
-
- function f (a)
- if a < 0 then
- error("negative number detected")
- end
- return a + 5
- end
- )");
-
- sol::protected_function f = lua["f"];
- f.error_handler = lua["handler"];
-
- sol::protected_function_result result = f(-500);
- if (result.valid()) {
- // Call succeeded
- int x = result;
- }
- else {
- // Call failed
- sol::error err = result;
- std::string what = err.what();
- // 'what' Should read
- // "Handled this message: negative number detected"
- }
- }
-
-
-Multiple returns to and from Lua
---------------------------------
-
-You can return multiple items to and from Lua using ``std::tuple``/``std::pair`` classes provided by C++. These enable you to also use :doc:`sol::tie<../api/tie>` to set return values into pre-declared items. To recieve multiple returns, just ask for a ``std::tuple`` type from the result of a function's computation, or ``sol::tie`` a bunch of pre-declared variables together and set the result equal to that:
-
-.. code-block:: cpp
- :linenos:
- :caption: Multiple returns from Lua
- :name: multi-return-lua-functions
-
- int main () {
- sol::state lua;
-
- lua.script("function f (a, b, c) return a, b, c end");
-
- std::tuple<int, int, int> result;
- result = lua["f"](1, 2, 3);
- // result == { 1, 2, 3 }
- int a, int b;
- std::string c;
- sol::tie( a, b, c ) = lua["f"](1, 2, "bark");
- // a == 1
- // b == 2
- // c == "bark"
- }
-
-You can also return mutiple items yourself from a C++-bound function. Here, we're going to bind a C++ lambda into Lua, and then call it through Lua and get a ``std::tuple`` out on the other side:
-
-.. code-block:: cpp
- :linenos:
- :caption: Multiple returns into Lua
- :name: multi-return-cxx-functions
-
- int main () {
- sol::state lua;
-
- lua["f"] = [](int a, int b, sol::object c) {
- // sol::object can be anything here: just pass it through
- return std::make_tuple( a, b, c );
- };
-
- std::tuple<int, int, int> result = lua["f"](1, 2, 3);
- // result == { 1, 2, 3 }
-
- std::tuple<int, int, std::string> result2;
- result2 = lua["f"](1, 2, "Arf?")
- // result2 == { 1, 2, "Arf?" }
-
- int a, int b;
- std::string c;
- sol::tie( a, b, c ) = lua["f"](1, 2, "meow");
- // a == 1
- // b == 2
- // c == "meow"
- }
-
-
-Note here that we use :doc:`sol::object<../api/object>` to transport through "any value" that can come from Lua. You can also use ``sol::make_object`` to create an object from some value, so that it can be returned into Lua as well.
-
-
-Any return to and from Lua
---------------------------
-
-It was hinted at in the previous code example, but ``sol::object`` is a good way to pass "any type" back into Lua (while we all wait for ``std::variant<...>`` to get implemented and shipped by C++ compiler/library implementers).
-
-It can be used like so, inconjunction with ``sol::this_state``:
-
-.. code-block:: cpp
- :linenos:
- :caption: Return anything into Lua
- :name: object-return-cxx-functions
-
- sol::object fancy_func (sol::object a, sol::object b, sol::this_state s) {
- sol::state_view lua(s);
- if (a.is<int>() && b.is<int>()) {
- return sol::make_object(lua, a.as<int>() + b.as<int>());
- }
- else if (a.is<bool>()) {
- bool do_triple = a.as<bool>();
- return sol::make_object(lua, b.as<double>() * ( do_triple ? 3 : 1 ) );
- }
- return sol::make_object(lua, sol::nil);
- }
-
- int main () {
- sol::state lua;
-
- lua["f"] = fancy_func;
-
- int result = lua["f"](1, 2);
- // result == 3
- double result2 = lua["f"](false, 2.5);
- // result2 == 2.5
-
- // call in Lua, get result
- lua.script("result3 = f(true, 5.5)");
- double result3 = lua["result3"];
- // result3 == 16.5
- }
-
-
-This covers almost everything you need to know about Functions and how they interact with Sol. For some advanced tricks and neat things, check out :doc:`sol::this_state<../api/this_state>` and :doc:`sol::variadic_args<../api/variadic_args>`. The next stop in this tutorial is about :doc:`C++ types (usertypes) in Lua<cxx-in-lua>`! If you need a bit more information about functions in the C++ side and how to best utilize arguments from C++, see :ref:`this note<function-argument-handling>`. \ No newline at end of file
diff --git a/3rdparty/sol2/docs/source/tutorial/getting-started.rst b/3rdparty/sol2/docs/source/tutorial/getting-started.rst
deleted file mode 100644
index 02fc2daadf0..00000000000
--- a/3rdparty/sol2/docs/source/tutorial/getting-started.rst
+++ /dev/null
@@ -1,79 +0,0 @@
-getting started
-===============
-
-Let's get you going with Sol! To start, you'll need to use a lua distribution of some sort. Sol doesn't provide that: it only wraps the API that comes with it, so you can pick whatever distribution you like for your application. There are lots, but the two popular ones are `vanilla Lua`_ and speedy `LuaJIT`_ . We recommend vanilla Lua if you're getting started, LuaJIT if you need speed and can handle some caveats: the interface for Sol doesn't change no matter what Lua version you're using.
-
-If you need help getting or building Lua, check out the `Lua page on getting started`_. Note that for Visual Studio, one can simply download the sources, include all the Lua library files in that project, and then build for debug/release, x86/x64/ARM rather easily and with minimal interference. Just make sure to adjust the Project Property page to build as a static library (or a DLL with the proper define set in the ``Preprocessor`` step).
-
-After that, make sure you grab either the `single header file release`_, or just perform a clone of the `github repository here`_ and set your include paths up so that you can get at ``sol.hpp`` somehow. Note that we also have the latest version of the single header file with all dependencies included kept in the `repository as well`_. We recommend the single-header-file release, since it's easier to move around, manage and update if you commit it with some form of version control. You can also clone/submodule the repository and then point at the `single/sol/sol.hpp`_ on your include files path. Clone with:
-
->>> git clone https://github.com/ThePhD/sol2.git
-
-When you're ready, try compiling this short snippet:
-
-.. code-block:: cpp
- :linenos:
- :caption: test.cpp: the first snippet
- :name: the-first-snippet
-
- #include <sol.hpp> // or #include "sol.hpp", whichever suits your needs
-
- int main (int argc, char* argv[]) {
-
- sol::state lua;
- lua.open_libraries( sol::lib::base );
-
- lua.script( "print('bark bark bark!')" );
-
- return 0;
- }
-
-Using this simple command line:
-
->>> g++ -std=c++14 test.cpp -I"path/to/lua/include" -L"path/to/lua/lib" -llua
-
-Or using your favorite IDE / tool after setting up your include paths and library paths to Lua according to the documentation of the Lua distribution you got. Remember your linked lua library (``-llua``) and include / library paths will depend on your OS, file system, Lua distribution and your installation / compilation method of your Lua distribution.
-
-.. note::
-
- If you get an avalanche of errors (particularly referring to ``auto``), you may not have enabled C++14 / C++17 mode for your compiler. Add one of ``std=c++14``, ``std=c++1z`` OR ``std=c++1y`` to your compiler options. By default, this is always-on for VC++ compilers in Visual Studio and friends, but g++ and clang++ require a flag (unless you're on `GCC 6.0`_).
-
-If this works, you're ready to start! The first line creates the ``lua_State`` and will hold onto it for the duration of the scope its declared in (e.g., from the opening ``{`` to the closing ``}``). It will automatically close / cleanup that lua state when it gets destructed. The second line opens a single lua-provided library, "base". There are several other libraries that come with lua that you can open by default, and those are included in the :ref:`sol::lib<lib-enum>` enumeration. You can open multiple base libraries by specifying multiple ``sol::lib`` arguments:
-
-.. code-block:: cpp
- :linenos:
- :caption: test.cpp: the first snippet
- :name: the-second-snippet
-
- #include <sol.hpp>
-
- int main (int argc, char* argv[]) {
-
- sol::state lua;
- lua.open_libraries( sol::lib::base, sol::lib::coroutine, sol::lib::string, sol::lib::io );
-
- lua.script( "print('bark bark bark!')" );
-
- return 0;
- }
-
-If you're interested in integrating Sol with a project that already uses some other library or Lua in the codebase, check out the :doc:`existing example<existing>` to see how to work with Sol when you add it to a project (the existing example covers ``require`` as well)!
-
-Next, let's start :doc:`reading/writing some variables<variables>` from Lua into C++, and vice-versa!
-
-
-.. _vanilla Lua: https://www.lua.org/
-
-.. _LuaJIT: http://luajit.org/
-
-.. _GCC 6.0: https://gcc.gnu.org/gcc-6/changes.html
-
-.. _single header file release: https://github.com/ThePhD/sol2/releases
-
-.. _repository as well: https://github.com/ThePhD/sol2/blob/develop/single/sol/sol.hpp
-
-.. _single/sol/sol.hpp: https://github.com/ThePhD/sol2/blob/develop/single/sol/sol.hpp
-
-.. _github repository here: https://github.com/ThePhD/sol2
-
-.. _Lua page on getting started: https://www.lua.org/start.html \ No newline at end of file
diff --git a/3rdparty/sol2/docs/source/tutorial/ownership.rst b/3rdparty/sol2/docs/source/tutorial/ownership.rst
deleted file mode 100644
index 96eb350da78..00000000000
--- a/3rdparty/sol2/docs/source/tutorial/ownership.rst
+++ /dev/null
@@ -1,94 +0,0 @@
-ownership
-=========
-
-Sol will not take ownership of raw pointers: raw pointers do not own anything.
-
-.. code-block:: cpp
-
- struct my_type {
- void stuff () {}
- };
-
- sol::state lua;
-
- // AAAHHH BAD
- // dangling pointer!
- lua["my_func"] = []() -> my_type* {
- return new my_type();
- };
-
- // AAAHHH!
- lua.set("something", new my_type());
-
- // AAAAAAHHH!!!
- lua["something_else"] = new my_type();
-
-Use/return a ``unique_ptr`` or ``shared_ptr`` instead or just return a value:
-
-.. code-block:: cpp
-
- // :ok:
- lua["my_func"] = []() -> std::unique_ptr<my_type> {
- return std::make_unique<my_type>();
- };
-
- // :ok:
- lua["my_func"] = []() -> std::shared_ptr<my_type> {
- return std::make_shared<my_type>();
- };
-
- // :ok:
- lua["my_func"] = []() -> my_type {
- return my_type();
- };
-
- // :ok:
- lua.set("something", std::unique_ptr<my_type>(new my_type()));
-
- std::shared_ptr<my_type> my_shared = std::make_shared<my_type>();
- // :ok:
- lua.set("something_else", my_shared);
-
- auto my_unique = std::make_unique<my_type>();
- lua["other_thing"] = std::move(my_unique);
-
-If you have something you know is going to last and you just want to give it to Lua as a reference, then it's fine too:
-
-.. code-block:: cpp
-
- // :ok:
- lua["my_func"] = []() -> my_type* {
- static my_type mt;
- return &mt;
- };
-
-
-Sol can detect ``nullptr``, so if you happen to return it there won't be any dangling because a ``sol::nil`` will be pushed.
-
-.. code-block:: cpp
-
- struct my_type {
- void stuff () {}
- };
-
- sol::state lua;
-
- // BUT THIS IS STILL BAD DON'T DO IT AAAHHH BAD
- // return a unique_ptr still or something!
- lua["my_func"] = []() -> my_type* {
- return nullptr;
- };
-
- lua["my_func_2"] = [] () -> std::unique_ptr<my_type> {
- // default-constructs as a nullptr,
- // gets pushed as nil to Lua
- return std::unique_ptr<my_type>();
- // same happens for std::shared_ptr
- }
-
- // Acceptable, it will set 'something' to nil
- // (and delete it on next GC if there's no more references)
- lua.set("something", nullptr);
-
- // Also fine
- lua["something_else"] = nullptr;
diff --git a/3rdparty/sol2/docs/source/tutorial/tutorial-top.rst b/3rdparty/sol2/docs/source/tutorial/tutorial-top.rst
deleted file mode 100644
index 730423fdb5a..00000000000
--- a/3rdparty/sol2/docs/source/tutorial/tutorial-top.rst
+++ /dev/null
@@ -1,21 +0,0 @@
-tutorial
-========
-
-Take some time to learn the framework with thse tutorials. But, if you need to get going FAST, try using the :doc:`quick 'n' dirty<all-the-things>` approach and your browser's / editors search function. It will also serve you well to look at all the `examples`_, which have recently gotten a bit of an overhaul to contain more relevant working examples.
-
-
-.. toctree::
- :caption: Sol Tutorial
- :name: tutorialtoc
- :maxdepth: 2
-
- all-the-things
- getting-started
- existing
- variables
- functions
- cxx-in-lua
- ownership
- customization
-
-.. _examples: https://github.com/ThePhD/sol2/tree/develop/examples
diff --git a/3rdparty/sol2/docs/source/tutorial/variables.rst b/3rdparty/sol2/docs/source/tutorial/variables.rst
deleted file mode 100644
index a911fcefdb4..00000000000
--- a/3rdparty/sol2/docs/source/tutorial/variables.rst
+++ /dev/null
@@ -1,202 +0,0 @@
-variables
-=========
-
-Working with variables is easy with Sol, and behaves pretty much like any associative array / map structure you've dealt with previously. Given this lua file that gets loaded into Sol:
-
-reading
--------
-
-.. code-block:: lua
- :caption: variables.lua
-
- config = {
- fullscreen = false,
- resolution = { x = 1024, y = 768 }
- }
-
-.. code-block:: cpp
- :caption: main.cpp
- :name: variables-main-cpp
-
- #include <sol.hpp>
-
- int main () {
-
- sol::state lua;
- lua.script_file( variables.lua );
-
- return 0;
- }
-
-You can interact with the variables like this:
-
-.. code-block:: cpp
- :caption: main.cpp extended
- :name: extended-variables-main-cpp
-
- #include <sol.hpp>
- #include <tuple>
- #include <utility> // for std::pair
-
- int main () {
-
- sol::state lua;
- lua.script_file( variables.lua );
-
- // the type "state" behaves exactly like a table!
- bool isfullscreen = lua["config"]["fullscreen"]; // can get nested variables
- sol::table config = lua["config"];
-
- // can also get it using the "get" member function
- // auto replaces the unqualified type name
- auto resolution = config.get<sol::table>( "config" );
-
- // table and state can have multiple things pulled out of it too
- std::pair<int, int> xyresolution = resolution.get<int, int>( "x", "y" );
- // As an example, you can also pull out a tuple as well
- std::tuple<int, int> xyresolutiontuple = resolution.get<int, int>( "x", "y" );
-
-
- return 0;
- }
-
-From this example, you can see that there's many ways to pull out the varaibles you want. For example, to determine if a nested variable exists or not, you can use ``auto`` to capture the value of a ``table[key]`` lookup, and then use the ``.valid()`` method:
-
-.. code-block:: cpp
- :caption: safe lookup
-
- auto bark = lua["config"]["bark"];
- if (bark.valid()) {
- // branch not taken: config / bark is not a variable
- }
- else {
- // Branch taken: config is a not a variable
- }
-
-This comes in handy when you want to check if a nested variable exists. You can also check if a toplevel variable is present or not by using ``sol::optional``, which also checks if A) the keys you're going into exist and B) the type you're trying to get is of a specific type:
-
-.. code-block:: cpp
- :caption: optional lookup
-
- sol::optional<int> not_an_integer = lua["config"]["fullscreen"];
- if (not_an_integer) {
- // Branch not taken: value is not an integer
- }
-
- sol::optional<bool> is_a_boolean = lua["config"]["fullscreen"];
- if (is_a_boolean) {
- // Branch taken: the value is a boolean
- }
-
- sol::optional<double> does_not_exist = lua["not_a_variable"];
- if (does_not_exist) {
- // Branch not taken: that variable is not present
- }
-
-This can come in handy when, even in optimized or release modes, you still want the safety of checking. You can also use the `get_or` methods to, if a certain value may be present but you just want to default the value to something else:
-
-.. code-block:: cpp
- :caption: get_or lookup
-
- // this will result in a value of '24'
- int is_defaulted = lua["config"]["fullscreen"].get_or( 24 );
-
- // This will result in the value of the config, which is 'false'
- bool is_not_defaulted = lua["config"]["fullscreen"];
-
-That's all it takes to read variables!
-
-
-writing
--------
-
-Writing gets a lot simpler. Even without scripting a file or a string, you can read and write variables into lua as you please:
-
-.. code-block:: cpp
- :caption: main.cpp
- :name: writing-main-cpp
-
- #include <sol.hpp>
- #include <iostream>
-
- int main () {
-
- sol::state lua;
-
- // open those basic lua libraries again, like print() etc.
- lua.open_libraries( sol::lib::base );
-
- // value in the global table
- lua["bark"] = 50;
-
- // a table being created in the global table
- lua["some_table"] = lua.create_table_with(
- "key0", 24,
- "key1", 25,
- lua["bark"], "the key is 50 and this string is its value!"
- );
-
- // Run a plain ol' string of lua code
- // Note you can interact with things set through Sol in C++ with lua!
- // Using a "Raw String Literal" to have multi-line goodness: http://en.cppreference.com/w/cpp/language/string_literal
- lua.script(R"(
-
- print(some_table[50])
- print(some_table["key0"])
- print(some_table["key1"])
-
- -- a lua comment: access a global in a lua script with the _G table
- print(_G["bark"])
-
- )");
-
- return 0;
- }
-
-This example pretty much sums up what can be done. Note that the syntax ``lua["non_existing_key_1"] = 1`` will make that variable, but if you tunnel too deep without first creating a table, the Lua API will panic (e.g., ``lua["does_not_exist"]["b"] = 20`` will trigger a panic). You can also be lazy with reading / writing values:
-
-.. code-block:: cpp
- :caption: main.cpp
- :name: lazy-main-cpp
-
- #include <sol.hpp>
- #include <iostream>
-
- int main () {
-
- sol::state lua;
-
- auto barkkey = lua["bark"];
- if (barkkey.valid()) {
- // Branch not taken: doesn't exist yet
- std::cout << "How did you get in here, arf?!" << std::endl;
- }
-
- barkkey = 50;
- if (barkkey.valid()) {
- // Branch taken: value exists!
- std::cout << "Bark Bjork Wan Wan Wan" << std::endl;
- }
- }
-
-Finally, it's possible to erase a reference/variable by setting it to ``nil``, using the constant ``sol::nil`` in C++:
-
-.. code-block:: cpp
- :caption: main.cpp
- :name: erase-main-cpp
-
- #include <sol.hpp>
-
- int main () {
-
- sol::state lua;
- lua["bark"] = 50;
- sol::optional<int> x = lua["bark"];
- // x will have a value
-
- lua["bark"] = sol::nil;
- sol::optional<int> y = lua["bark"];
- // y will not have a value
- }
-
-It's easy to see that there's a lot of options to do what you want here. But, these are just traditional numbers and strings. What if we want more power, more capabilities than what these limited types can offer us? Let's throw some :doc:`functions in there<functions>` :doc:`C++ classes into the mix<cxx-in-lua>`!
diff --git a/3rdparty/sol2/docs/source/usertypes.rst b/3rdparty/sol2/docs/source/usertypes.rst
deleted file mode 100644
index 081be5ed6eb..00000000000
--- a/3rdparty/sol2/docs/source/usertypes.rst
+++ /dev/null
@@ -1,29 +0,0 @@
-usertypes
-=========
-
-Perhaps the most powerful feature of sol2, ``usertypes`` are the way sol2 and C++ communicate your classes to the Lua runtime and bind things between both tables and to specific blocks of C++ memory, allowing you to treat Lua userdata and other things like classes.
-
-To learn more about usertypes, visit:
-
-* :doc:`the basic tutorial<tutorial/cxx-in-lua>`
-* :doc:`customization point tutorial<tutorial/customization>`
-* :doc:`api documentation<api/usertype>`
-* :doc:`memory documentation<api/usertype_memory>`
-
-The examples folder also has a number of really great examples for you to see. There are also some notes about guarantees you can find about usertypes, and their associated userdata, below:
-
-* You can push types classified as userdata before you register a usertype.
- - You can register a usertype with the Lua runtime at any time sol2
- - You can retrieve them from the Lua runtime as well through sol2
- - Methods and properties will be added to the type only after you register it in the Lua runtime
-* Types either copy once or move once into the memory location, if it is a value type. If it is a pointer, we store only the reference.
- - This means take arguments of class types (not primitive types like strings or integers) by ``T&`` or ``T*`` to modify the data in Lua directly, or by plain ``T`` to get a copy
- - Return types and passing arguments to ``sol::function`` use perfect forwarding and reference semantics, which means no copies happen unless you specify a value explicitly. See :ref:`this note for details<function-argument-handling>`.
-* The first ``sizeof( void* )`` bytes is always a pointer to the typed C++ memory. What comes after is based on what you've pushed into the system according to :doc:`the memory specification for usertypes<api/usertype_memory>`. This is compatible with a number of systems.
-* Member methods, properties, variables and functions taking ``self&`` arguments modify data directly
- - Work on a copy by taking or returning a copy by value.
-* The actual metatable associated with the usertype has a long name and is defined to be opaque by the Sol implementation.
-* Containers get pushed as special usertypes, but can be disabled if problems arising as detailed :doc:`here<api/containers>`.
-* You can use bitfields but it requires some finesse on your part. We have an example to help you get started `here that uses a few tricks`_.
-
-.. _here that uses a few tricks: https://github.com/ThePhD/sol2/blob/develop/examples/usertype_bitfields.cpp