Add files using upload-large-folder tool

third_party/CityFlow/docs/source/introduction.rst

@@ -1,21 +1,21 @@
-Introduction
-============
-
-CityFlow is a multi-agent reinforcement learning environment for large scale city traffic scenario. 
-
-Checkout these features!
-
-- a microscopic traffic simulator which simulates the behavior of each vehicle, providing highest level detail of traffic evolution.
-- support flexible definitions for road network and traffic flow
-- provides friendly python interface for reinforcement learning
-- **Fast!** Elaborately designed data structure and simulation algorithm with multithreading. Capable of simulating city-wide traffic. See the performance comparison with SUMO [#sumo]_.
-
-.. figure:: https://github.com/cityflow-project/data/raw/master/docs/images/performance.png
-    :align: center
-
-    Performance comparison between CityFlow with different number of threads (1, 2, 4, 8) and SUMO. From small 1x1 grid roadnet to city-level 30x30 roadnet. Even faster when you need to interact with the simulator through python API.
-
-See :ref:`start` to get started.
-
-.. [#paper] `WWW 2019 Demo Paper <https://arxiv.org/abs/1905.05217>`_
+Introduction
+============
+
+CityFlow is a multi-agent reinforcement learning environment for large scale city traffic scenario. 
+
+Checkout these features!
+
+- a microscopic traffic simulator which simulates the behavior of each vehicle, providing highest level detail of traffic evolution.
+- support flexible definitions for road network and traffic flow
+- provides friendly python interface for reinforcement learning
+- **Fast!** Elaborately designed data structure and simulation algorithm with multithreading. Capable of simulating city-wide traffic. See the performance comparison with SUMO [#sumo]_.
+
+.. figure:: https://github.com/cityflow-project/data/raw/master/docs/images/performance.png
+    :align: center
+
+    Performance comparison between CityFlow with different number of threads (1, 2, 4, 8) and SUMO. From small 1x1 grid roadnet to city-level 30x30 roadnet. Even faster when you need to interact with the simulator through python API.
+
+See :ref:`start` to get started.
+
+.. [#paper] `WWW 2019 Demo Paper <https://arxiv.org/abs/1905.05217>`_
 .. [#sumo] `SUMO home page <https://sumo.dlr.de/index.html>`_

third_party/CityFlow/docs/source/replay.rst

@@ -1,69 +1,69 @@
-.. _replay:
-
-Replay
-======
-
-Start
-------
-
-1. enter the ``frontend`` folder and open ``index.html`` in your browser.
-
-2. choose the roadnet log file (as defined by ``roadnetLogFile`` field in the config file, **not 'roadnetFile'**) and wait for it to be loaded. When it has finished loading, there will be a message shown in the info box.
-
-3. choose the replay file (as defined by ``replayLogFile`` field in the config file) .
-
-4. choose the chart data file (optional, see section *Chart* below).
-
-5. press ``Start`` button to start the replay.
-
-Control
--------
-
-- Use the mouse to navigate. Dragging and mouse wheel zooming are supported.
-
-- Move the slider in Control Box to adjust the replay speed. You can also press ``1`` on keyboard to slow down or ``2`` to speed up.
-
-- Press ``Pause`` button in Control Box to pause/resume. You can also double-click on the map to pause and resume.
-
-- Press ``[`` or ``]`` on keyboard to take a step backward or forward.
-
-- To restart the replay, just press ``Start`` button again.
-
-- The ``debug`` option enables displaying the ID of vehicles, roads and intersections during a mouse hover. **This will cause a slower replaying**, so we suggest using it only for debugging purposes.
-
-Chart
-------
-
-The player supports showing the change of different metrics in a chart simultaneously with the replay process.
-
-To provide required data, a log file in a format as shown below is needed:
-
-.. code-block::
-
-  title
-  0.3            0.4              0.1          ...(step1)
-  0.5            0.2              0.2          ...(step2)
-  ...(metric1)   ...(metric2)     ...(metric3)
-
-The first line is the title of the chart.
-
-Each row stands for a time step and each column stands for a specific metric.
-For example, to track vehicle numbers of three crossroads respectively, we need three columns and each column stands for the vehicle number of a certain crossroads.
-
-In one row, numbers are separated by one or more spaces or tabs.
-
-The numbers in one column will be shown as points connected by one line in the chart.
-
-.. note::
-  Make sure that each row is corresponding with the right time step.
-
-Notes
-------
-
-- To get the example replay files, run ``download_replay.py`` under ``frontend`` folder.
-
-- If you create a new Engine object with same ``replayLogFile``, it will clear the old replay file first
-
-- Using ``eng.reset()`` won't clear old replays, it will append newly generated replay to the end of ``replayLogFile``
-
-- You can change ``replayLogFile`` during runtime using ``set_replay_file``, see :ref:`set-replay-file`
+.. _replay:
+
+Replay
+======
+
+Start
+------
+
+1. enter the ``frontend`` folder and open ``index.html`` in your browser.
+
+2. choose the roadnet log file (as defined by ``roadnetLogFile`` field in the config file, **not 'roadnetFile'**) and wait for it to be loaded. When it has finished loading, there will be a message shown in the info box.
+
+3. choose the replay file (as defined by ``replayLogFile`` field in the config file) .
+
+4. choose the chart data file (optional, see section *Chart* below).
+
+5. press ``Start`` button to start the replay.
+
+Control
+-------
+
+- Use the mouse to navigate. Dragging and mouse wheel zooming are supported.
+
+- Move the slider in Control Box to adjust the replay speed. You can also press ``1`` on keyboard to slow down or ``2`` to speed up.
+
+- Press ``Pause`` button in Control Box to pause/resume. You can also double-click on the map to pause and resume.
+
+- Press ``[`` or ``]`` on keyboard to take a step backward or forward.
+
+- To restart the replay, just press ``Start`` button again.
+
+- The ``debug`` option enables displaying the ID of vehicles, roads and intersections during a mouse hover. **This will cause a slower replaying**, so we suggest using it only for debugging purposes.
+
+Chart
+------
+
+The player supports showing the change of different metrics in a chart simultaneously with the replay process.
+
+To provide required data, a log file in a format as shown below is needed:
+
+.. code-block::
+
+  title
+  0.3            0.4              0.1          ...(step1)
+  0.5            0.2              0.2          ...(step2)
+  ...(metric1)   ...(metric2)     ...(metric3)
+
+The first line is the title of the chart.
+
+Each row stands for a time step and each column stands for a specific metric.
+For example, to track vehicle numbers of three crossroads respectively, we need three columns and each column stands for the vehicle number of a certain crossroads.
+
+In one row, numbers are separated by one or more spaces or tabs.
+
+The numbers in one column will be shown as points connected by one line in the chart.
+
+.. note::
+  Make sure that each row is corresponding with the right time step.
+
+Notes
+------
+
+- To get the example replay files, run ``download_replay.py`` under ``frontend`` folder.
+
+- If you create a new Engine object with same ``replayLogFile``, it will clear the old replay file first
+
+- Using ``eng.reset()`` won't clear old replays, it will append newly generated replay to the end of ``replayLogFile``
+
+- You can change ``replayLogFile`` during runtime using ``set_replay_file``, see :ref:`set-replay-file`

third_party/CityFlow/docs/source/roadnet.rst

@@ -1,129 +1,129 @@
-.. _roadnet:
-
-Roadnet File Format
-===================
-
-Roadnet file defines the roadnet structure. CityFlow's roadnet mainly consists of intersections and roads (see them as nodes and edges of a graph). 
-
-- *Road* represents a directional road from one *intersection* to another *intersection* with road-specific properties. A *road* may contain multiple *lanes*. 
-- *Intersection* is where roads intersects. An *intersection* contains several *roadlinks*. Each *roadlink* connects two roads of the intersection and can be controlled by traffic signals. 
-- A *roadlink* may contain several *lanelinks*. Each lanelink represents a specific path from one lane of incoming road to one lane of outgoing road. 
-
-Now let's see a sample roadnet file and we'll explain the meaning of each components. Relax, the definition of field is quite straight forward, if you are familiar with modern road networks. For the following json file, ``[]`` means this field is an array, but we will only show one object for demonstration. 
-
-.. note::
-  Runnable sample roadnet files can be found in ``examples`` folder.
-
-Sample ``roadnet.json`` with explanation.
-
-.. code-block:: js
-
-  {
-    "intersections": [
-      {
-        // id of the intersection
-        "id": "intersection_1_0",
-        // coordinate of center of intersection
-        "point": { 
-          "x": 0,
-          "y": 0
-        },
-        // width of the intersection
-        "width": 10,
-        // roads connected to the intersection
-        "roads": [
-          "road_1",
-          "road_2"
-        ],
-        // roadLinks of the intersection
-        "roadLinks": [
-          {
-            // 'turn_left', 'turn_right', 'go_straight'
-            "type": "go_straight",
-            // id of starting road
-            "startRoad": "road_1",
-            // id of ending road
-            "endRoad": "road_2",
-            // lanelinks of roadlink
-            "laneLinks": [ 
-              {
-                // from startRoad's startLaneIndex lane to endRoad's endLaneIndex lane
-                "startLaneIndex": 0, 
-                "endLaneIndex": 1,
-                // points along the laneLink which describe the shape of laneLink
-                "points": [
-                  {
-                    "x": -10,
-                    "y": 2
-                  },
-                  {
-                    "x": 10,
-                    "y": -2
-                  }
-                ]
-              }
-            ]
-          }
-        ],
-        // traffic light plan of the intersection
-        "trafficLight": {
-          "lightphases": [
-            {
-              // default duration of the phase
-              "time": 30,
-              // available roadLinks of current phase, index is the no. of roadlinks defined above.
-              "availableRoadLinks": [
-                0,
-                2
-              ]
-            }
-          ]
-        },
-        // true if it's a peripheral intersection (if it only connects to one road)
-        "virtual": false
-      }
-    ],
-    "roads": [
-      {
-        // id of road
-        "id": "road_1",
-        // id of start intersection
-        "startIntersection": "intersection_1",
-        // id of end intersection
-        "endIntersection": "intersection_2",
-        // points along the road which describe the shape of the road
-        "points": [
-          {
-            "x": -200,
-            "y": 0
-          },
-          {
-            "x": 0,
-            "y": 0
-          }
-        ],
-        // property of each lane
-        "lanes": [
-          {
-            "width": 4,
-            "maxSpeed": 16.67
-          }
-        ]
-      }
-    ]
-  }
-
-
-.. figure:: https://github.com/cityflow-project/data/raw/master/docs/images/roadnet.jpg
-    :align: center
-
-    Illustration of a 1x2 grid roadnet.
-
-
-You can convert SUMO roadnet files into CityFlow format using tools/Converter/converter.py
-
-For example, the following code converts a sumo roadnet file, atlanta.net.xml, to CityFlow format.
-
-.. code-block:: shell
-
-    python converter.py --sumonet atlanta_sumo.net.xml --cityflownet atlanta_cityflow.json
+.. _roadnet:
+
+Roadnet File Format
+===================
+
+Roadnet file defines the roadnet structure. CityFlow's roadnet mainly consists of intersections and roads (see them as nodes and edges of a graph). 
+
+- *Road* represents a directional road from one *intersection* to another *intersection* with road-specific properties. A *road* may contain multiple *lanes*. 
+- *Intersection* is where roads intersects. An *intersection* contains several *roadlinks*. Each *roadlink* connects two roads of the intersection and can be controlled by traffic signals. 
+- A *roadlink* may contain several *lanelinks*. Each lanelink represents a specific path from one lane of incoming road to one lane of outgoing road. 
+
+Now let's see a sample roadnet file and we'll explain the meaning of each components. Relax, the definition of field is quite straight forward, if you are familiar with modern road networks. For the following json file, ``[]`` means this field is an array, but we will only show one object for demonstration. 
+
+.. note::
+  Runnable sample roadnet files can be found in ``examples`` folder.
+
+Sample ``roadnet.json`` with explanation.
+
+.. code-block:: js
+
+  {
+    "intersections": [
+      {
+        // id of the intersection
+        "id": "intersection_1_0",
+        // coordinate of center of intersection
+        "point": { 
+          "x": 0,
+          "y": 0
+        },
+        // width of the intersection
+        "width": 10,
+        // roads connected to the intersection
+        "roads": [
+          "road_1",
+          "road_2"
+        ],
+        // roadLinks of the intersection
+        "roadLinks": [
+          {
+            // 'turn_left', 'turn_right', 'go_straight'
+            "type": "go_straight",
+            // id of starting road
+            "startRoad": "road_1",
+            // id of ending road
+            "endRoad": "road_2",
+            // lanelinks of roadlink
+            "laneLinks": [ 
+              {
+                // from startRoad's startLaneIndex lane to endRoad's endLaneIndex lane
+                "startLaneIndex": 0, 
+                "endLaneIndex": 1,
+                // points along the laneLink which describe the shape of laneLink
+                "points": [
+                  {
+                    "x": -10,
+                    "y": 2
+                  },
+                  {
+                    "x": 10,
+                    "y": -2
+                  }
+                ]
+              }
+            ]
+          }
+        ],
+        // traffic light plan of the intersection
+        "trafficLight": {
+          "lightphases": [
+            {
+              // default duration of the phase
+              "time": 30,
+              // available roadLinks of current phase, index is the no. of roadlinks defined above.
+              "availableRoadLinks": [
+                0,
+                2
+              ]
+            }
+          ]
+        },
+        // true if it's a peripheral intersection (if it only connects to one road)
+        "virtual": false
+      }
+    ],
+    "roads": [
+      {
+        // id of road
+        "id": "road_1",
+        // id of start intersection
+        "startIntersection": "intersection_1",
+        // id of end intersection
+        "endIntersection": "intersection_2",
+        // points along the road which describe the shape of the road
+        "points": [
+          {
+            "x": -200,
+            "y": 0
+          },
+          {
+            "x": 0,
+            "y": 0
+          }
+        ],
+        // property of each lane
+        "lanes": [
+          {
+            "width": 4,
+            "maxSpeed": 16.67
+          }
+        ]
+      }
+    ]
+  }
+
+
+.. figure:: https://github.com/cityflow-project/data/raw/master/docs/images/roadnet.jpg
+    :align: center
+
+    Illustration of a 1x2 grid roadnet.
+
+
+You can convert SUMO roadnet files into CityFlow format using tools/Converter/converter.py
+
+For example, the following code converts a sumo roadnet file, atlanta.net.xml, to CityFlow format.
+
+.. code-block:: shell
+
+    python converter.py --sumonet atlanta_sumo.net.xml --cityflownet atlanta_cityflow.json

third_party/CityFlow/docs/source/start.rst

@@ -1,229 +1,229 @@
-.. _start:
-
-Quick Start
-===========
-
-Installation
-------------
-
-If you have not installed CityFlow yet, :ref:`install` is a simple guide for installation.
-
-
-Create Engine
--------------
-
-.. code-block:: python
-    
-    import cityflow
-    eng = cityflow.Engine(config_path, thread_num=1)
-
-
-- ``config_path``: path for config file.
-- ``thread_num``: number of threads.
-
-Arguments In Config File
-^^^^^^^^^^^^^^^^^^^^^^^^
-- ``interval``: time of each simulation step (in seconds). An ``interval`` of 0.5 means for each simulation step, the system will move 0.5 seconds forward. For example, if a car is at location 0 with speed 10m/s, after one simulation step, it will move to location 10*0.5=5. 
-- ``seed``: random seed.
-- ``dir``: root directory, all file path will be relative to this directory.
-- ``roadnetFile``: path for roadnet file.
-- ``flowFile``: path for flow file.
-- ``rlTrafficLight``: whether to enable traffic light control through python API. If set to ``false``, default traffic light plan defined in ``roadnetFile`` will be used.
-- ``saveReplay``: whether to save simulation for replay. If set to ``true``, ``roadnetLogFile`` and ``replayLogFile`` are required.
-- ``roadnetLogFile``: path for roadnet replay file. This is a special roadnet file for replay, not the same as ``roadnetFile``.
-- ``replayLogFile``: path for replay. This file contains vehicle positions and traffic light situation of each simulation step.
-- ``laneChange``: whether to enable lane changing. The default value is 'false'.
-
-For format of ``roadnetFile`` and ``flowFile``, please see :ref:`roadnet`, :ref:`flow`
-
-.. note::
-    Runnable sample roadnet and flow files can be found in ``examples`` folder.
-
-You can generate grid roadnet and flow files using `tools/generate_grid_scenario.py`
-
-For example, you can generate a 2x3 roadnet with predefined traffic light plan and a corresponding flow file with
-
-.. code-block:: shell
-
-    python generate_grid_scenario.py 2 3 --roadnetFile roadnet.json --flowFile flow.json --dir . --tlPlan
-
-Sample Config File
-^^^^^^^^^^^^^^^^^^^
-
-.. note::
-    Runnable sample config files can be found in ``examples`` folder.
-
-.. code-block:: json
-
-    {
-        "interval": 1.0,
-        "seed": 0,
-        "dir": "data/",
-        "roadnetFile": "roadnet/testcase_roadnet_3x3.json",
-        "flowFile": "flow/testcase_flow_3x3.json",
-        "rlTrafficLight": false,
-        "saveReplay": true,
-        "roadnetLogFile": "frontend/web/testcase_roadnet_3x3.json",
-        "replayLogFile": "frontend/web/testcase_replay_3x3.txt"
-    }
-
-Simulation
-----------
-
-To simulate one step, simply call ``eng.next_step()``
-
-.. code-block:: python
-
-    eng.next_step()
-
-Data Access API
----------------
-
-``get_vehicle_count()``:
-
-- Get number of total running vehicles.
-- Return an ``int``
-
-``get_vehicles(include_waiting=False)``:
-
-- Get all vehicle ids
-- Include vehicles in lane's waiting buffer if ``include_waiting=True``
-- Return an ``list`` of vehicle ids
-
-``get_lane_vehicle_count()``: 
-
-- Get number of running vehicles on each lane.
-- Return a ``dict`` with lane id as key and corresponding number as value.
-
-``get_lane_waiting_vehicle_count()``:
-
-- Get number of waiting vehicles on each lane. Currently, vehicles with speed less than 0.1m/s is considered as waiting.
-- Return a ``dict`` with lane id as key and corresponding number as value.
-
-``get_lane_vehicles()``:
-
-- Get vehicle ids on each lane.
-- Return a ``dict`` with lane id as key and list of vehicle id as value.
-
-``get_vehicle_info(vehicle_id)``:
-
-- Return a ``dict`` which contains information of the given vehicle.
-- The items include:
-
-    + ``running``: whether the vehicle is running.
-    + If the vehicle is running:
-
-        * ``speed``: The speed of the vehicle.
-        * ``distance``: The distance the vehicle has travelled on the current lane or lanelink.
-        * ``drivable``: The id of the current drivable(lane or lanelink)
-        * ``road``: The id of the current road if the vehicle is running on a lane.
-        * ``intersection``: The next intersection if the vehicle is running on a lane.
-        * ``route``: A string contains ids of following roads in the vehicle's route which are separated by ``' '``.
-
-- Note that all items are stored as ``str``.
-
-``get_vehicle_speed()``:
-
-- Get speed of each vehicle
-- Return a ``dict`` with vehicle id as key and corresponding speed as value.
-
-``get_vehicle_distance()``:
-
-- Get distance travelled on current lane of each vehicle.
-- Return a ``dict`` with vehicle id as key and corresponding distance as value.
-
-``get_leader(vehicle_id)``
-
-- Return the id of the vehicle in front of ``vehicle_id``.
-- Return an empty string ``""`` when ``vehicle_id`` does not have a leader
-
-``get_current_time()``:
-
-- Get simulation time (in seconds)
-- Return a ``double``
-
-``get_average_travel_time()``:
-
-- Get average travel time (in seconds)
-- Return a ``double``
-
-Control API
------------
-
-``set_tl_phase(intersection_id, phase_id)``: 
-
-- Set the phase of traffic light of ``intersection_id`` to ``phase_id``. Only works when ``rlTrafficLight`` is set to ``true``.
-- The ``intersection_id`` should be defined in ``roadnetFile``
-- ``phase_id`` is the index of phase in array ``"lightphases"``, defined in ``roadnetFile``.
-
-``set_vehicle_speed(vehicle_id, speed)``:
-
-- Set the speed of ``vehicle_id`` to ``speed``.
-- The vehicles have to obey fundamental rules to avoid collisions so the real speed might be different from ``speed``.
-
-``reset(seed=False)``: 
-
-- Reset the simulation (clear all vehicles and set simulation time back to zero)
-- Reset random seed if ``seed`` is set to ``True``
-- This does not clear old replays, instead, it appends new replays to ``replayLogFile``.
-
-``snapshot()``:
-
-- Take a snapshot of current simulation state
-- This will generate an ``Archive`` object which can be loaded later
-- You can save an ``Archive`` object to a file using its ``dump`` method.
-
-``load(archive)``:
-
-- Load an ``Archive`` object and restore simulation state
-
-``load_from_file(path)``
-
-- Load a snapshot file created by ``dump`` method and restore simulation state.
-- The whole process of saving and loading file is like:
-
-  .. code-block:: python
-
-      archive = eng.snapshot() # create an archive object
-      archive.dump("save.json") # if you want to save the snapshot to a file
-
-      # do something
-
-      eng.load(archive)
-      # load 'archive' and the simulation will start from the status when 'archive'is created
-
-      # or if you want to load from 'save.json'
-      eng.load_from_file("save.json")
-
-
-``set_random_seed(seed)``:
-
-- Set seed of random generator to ``seed``
-
-.. _set-replay-file:
-
-
-``set_vehicle_route(vehicle_id, route)``:
-
-- To change the route of a vehicle during its travelling.
-- `route` is a list of road ids (doesn't include the current road)
-- Return true if the route is available and can be connected.
-
-
-
-Other API
----------
-
-``set_replay_file(replay_file)``: 
-
-- ``replay_file`` should be a path related to ``dir`` in config file
-- Set ``replayLogFile`` to ``replay_file``, newly generated replays will be output into ``replay_file``
-- This is useful when you want to look at a specific episode for debugging purposes
-- This API works only when ``saveReplay`` is ``true`` in config json
-
-``set_save_replay(open)``:
-
-- Open or close replay saving
-- Set ``open`` to False to stop replay saving
-- Set ``open`` to True to start replay saving
+.. _start:
+
+Quick Start
+===========
+
+Installation
+------------
+
+If you have not installed CityFlow yet, :ref:`install` is a simple guide for installation.
+
+
+Create Engine
+-------------
+
+.. code-block:: python
+    
+    import cityflow
+    eng = cityflow.Engine(config_path, thread_num=1)
+
+
+- ``config_path``: path for config file.
+- ``thread_num``: number of threads.
+
+Arguments In Config File
+^^^^^^^^^^^^^^^^^^^^^^^^
+- ``interval``: time of each simulation step (in seconds). An ``interval`` of 0.5 means for each simulation step, the system will move 0.5 seconds forward. For example, if a car is at location 0 with speed 10m/s, after one simulation step, it will move to location 10*0.5=5. 
+- ``seed``: random seed.
+- ``dir``: root directory, all file path will be relative to this directory.
+- ``roadnetFile``: path for roadnet file.
+- ``flowFile``: path for flow file.
+- ``rlTrafficLight``: whether to enable traffic light control through python API. If set to ``false``, default traffic light plan defined in ``roadnetFile`` will be used.
+- ``saveReplay``: whether to save simulation for replay. If set to ``true``, ``roadnetLogFile`` and ``replayLogFile`` are required.
+- ``roadnetLogFile``: path for roadnet replay file. This is a special roadnet file for replay, not the same as ``roadnetFile``.
+- ``replayLogFile``: path for replay. This file contains vehicle positions and traffic light situation of each simulation step.
+- ``laneChange``: whether to enable lane changing. The default value is 'false'.
+
+For format of ``roadnetFile`` and ``flowFile``, please see :ref:`roadnet`, :ref:`flow`
+
+.. note::
+    Runnable sample roadnet and flow files can be found in ``examples`` folder.
+
+You can generate grid roadnet and flow files using `tools/generate_grid_scenario.py`
+
+For example, you can generate a 2x3 roadnet with predefined traffic light plan and a corresponding flow file with
+
+.. code-block:: shell
+
+    python generate_grid_scenario.py 2 3 --roadnetFile roadnet.json --flowFile flow.json --dir . --tlPlan
+
+Sample Config File
+^^^^^^^^^^^^^^^^^^^
+
+.. note::
+    Runnable sample config files can be found in ``examples`` folder.
+
+.. code-block:: json
+
+    {
+        "interval": 1.0,
+        "seed": 0,
+        "dir": "data/",
+        "roadnetFile": "roadnet/testcase_roadnet_3x3.json",
+        "flowFile": "flow/testcase_flow_3x3.json",
+        "rlTrafficLight": false,
+        "saveReplay": true,
+        "roadnetLogFile": "frontend/web/testcase_roadnet_3x3.json",
+        "replayLogFile": "frontend/web/testcase_replay_3x3.txt"
+    }
+
+Simulation
+----------
+
+To simulate one step, simply call ``eng.next_step()``
+
+.. code-block:: python
+
+    eng.next_step()
+
+Data Access API
+---------------
+
+``get_vehicle_count()``:
+
+- Get number of total running vehicles.
+- Return an ``int``
+
+``get_vehicles(include_waiting=False)``:
+
+- Get all vehicle ids
+- Include vehicles in lane's waiting buffer if ``include_waiting=True``
+- Return an ``list`` of vehicle ids
+
+``get_lane_vehicle_count()``: 
+
+- Get number of running vehicles on each lane.
+- Return a ``dict`` with lane id as key and corresponding number as value.
+
+``get_lane_waiting_vehicle_count()``:
+
+- Get number of waiting vehicles on each lane. Currently, vehicles with speed less than 0.1m/s is considered as waiting.
+- Return a ``dict`` with lane id as key and corresponding number as value.
+
+``get_lane_vehicles()``:
+
+- Get vehicle ids on each lane.
+- Return a ``dict`` with lane id as key and list of vehicle id as value.
+
+``get_vehicle_info(vehicle_id)``:
+
+- Return a ``dict`` which contains information of the given vehicle.
+- The items include:
+
+    + ``running``: whether the vehicle is running.
+    + If the vehicle is running:
+
+        * ``speed``: The speed of the vehicle.
+        * ``distance``: The distance the vehicle has travelled on the current lane or lanelink.
+        * ``drivable``: The id of the current drivable(lane or lanelink)
+        * ``road``: The id of the current road if the vehicle is running on a lane.
+        * ``intersection``: The next intersection if the vehicle is running on a lane.
+        * ``route``: A string contains ids of following roads in the vehicle's route which are separated by ``' '``.
+
+- Note that all items are stored as ``str``.
+
+``get_vehicle_speed()``:
+
+- Get speed of each vehicle
+- Return a ``dict`` with vehicle id as key and corresponding speed as value.
+
+``get_vehicle_distance()``:
+
+- Get distance travelled on current lane of each vehicle.
+- Return a ``dict`` with vehicle id as key and corresponding distance as value.
+
+``get_leader(vehicle_id)``
+
+- Return the id of the vehicle in front of ``vehicle_id``.
+- Return an empty string ``""`` when ``vehicle_id`` does not have a leader
+
+``get_current_time()``:
+
+- Get simulation time (in seconds)
+- Return a ``double``
+
+``get_average_travel_time()``:
+
+- Get average travel time (in seconds)
+- Return a ``double``
+
+Control API
+-----------
+
+``set_tl_phase(intersection_id, phase_id)``: 
+
+- Set the phase of traffic light of ``intersection_id`` to ``phase_id``. Only works when ``rlTrafficLight`` is set to ``true``.
+- The ``intersection_id`` should be defined in ``roadnetFile``
+- ``phase_id`` is the index of phase in array ``"lightphases"``, defined in ``roadnetFile``.
+
+``set_vehicle_speed(vehicle_id, speed)``:
+
+- Set the speed of ``vehicle_id`` to ``speed``.
+- The vehicles have to obey fundamental rules to avoid collisions so the real speed might be different from ``speed``.
+
+``reset(seed=False)``: 
+
+- Reset the simulation (clear all vehicles and set simulation time back to zero)
+- Reset random seed if ``seed`` is set to ``True``
+- This does not clear old replays, instead, it appends new replays to ``replayLogFile``.
+
+``snapshot()``:
+
+- Take a snapshot of current simulation state
+- This will generate an ``Archive`` object which can be loaded later
+- You can save an ``Archive`` object to a file using its ``dump`` method.
+
+``load(archive)``:
+
+- Load an ``Archive`` object and restore simulation state
+
+``load_from_file(path)``
+
+- Load a snapshot file created by ``dump`` method and restore simulation state.
+- The whole process of saving and loading file is like:
+
+  .. code-block:: python
+
+      archive = eng.snapshot() # create an archive object
+      archive.dump("save.json") # if you want to save the snapshot to a file
+
+      # do something
+
+      eng.load(archive)
+      # load 'archive' and the simulation will start from the status when 'archive'is created
+
+      # or if you want to load from 'save.json'
+      eng.load_from_file("save.json")
+
+
+``set_random_seed(seed)``:
+
+- Set seed of random generator to ``seed``
+
+.. _set-replay-file:
+
+
+``set_vehicle_route(vehicle_id, route)``:
+
+- To change the route of a vehicle during its travelling.
+- `route` is a list of road ids (doesn't include the current road)
+- Return true if the route is available and can be connected.
+
+
+
+Other API
+---------
+
+``set_replay_file(replay_file)``: 
+
+- ``replay_file`` should be a path related to ``dir`` in config file
+- Set ``replayLogFile`` to ``replay_file``, newly generated replays will be output into ``replay_file``
+- This is useful when you want to look at a specific episode for debugging purposes
+- This API works only when ``saveReplay`` is ``true`` in config json
+
+``set_save_replay(open)``:
+
+- Open or close replay saving
+- Set ``open`` to False to stop replay saving
+- Set ``open`` to True to start replay saving
 - This API works only when ``saveReplay`` is ``true`` in config json

third_party/CityFlow/extern/milo/dtoa_milo.h

@@ -1,396 +1,396 @@
-#pragma once
-#include <assert.h>
-#include <cmath>
-#include <string.h>
-#include <stdint.h>
-
-#define UINT64_C2(h, l) ((static_cast<uint64_t>(h) << 32) | static_cast<uint64_t>(l))
-
-struct DiyFp {
-    DiyFp() {}
-
-    DiyFp(uint64_t f, int e) : f(f), e(e) {}
-
-    DiyFp(double d) {
-        union {
-            double d;
-            uint64_t u64;
-        } u = { d };
-
-        int biased_e = (u.u64 & kDpExponentMask) >> kDpSignificandSize;
-        uint64_t significand = (u.u64 & kDpSignificandMask);
-        if (biased_e != 0) {
-            f = significand + kDpHiddenBit;
-            e = biased_e - kDpExponentBias;
-        }
-        else {
-            f = significand;
-            e = kDpMinExponent + 1;
-        }
-    }
-
-    DiyFp operator-(const DiyFp& rhs) const {
-        assert(e == rhs.e);
-        assert(f >= rhs.f);
-        return DiyFp(f - rhs.f, e);
-    }
-
-    DiyFp operator*(const DiyFp& rhs) const {
-#if defined(_MSC_VER) && defined(_M_AMD64)
-        uint64_t h;
-		uint64_t l = _umul128(f, rhs.f, &h);
-		if (l & (uint64_t(1) << 63)) // rounding
-			h++;
-		return DiyFp(h, e + rhs.e + 64);
-#elif (__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 6)) && defined(__x86_64__)
-        unsigned __int128 p = static_cast<unsigned __int128>(f) * static_cast<unsigned __int128>(rhs.f);
-		uint64_t h = p >> 64;
-		uint64_t l = static_cast<uint64_t>(p);
-		if (l & (uint64_t(1) << 63)) // rounding
-			h++;
-		return DiyFp(h, e + rhs.e + 64);
-#else
-        const uint64_t M32 = 0xFFFFFFFF;
-        const uint64_t a = f >> 32;
-        const uint64_t b = f & M32;
-        const uint64_t c = rhs.f >> 32;
-        const uint64_t d = rhs.f & M32;
-        const uint64_t ac = a * c;
-        const uint64_t bc = b * c;
-        const uint64_t ad = a * d;
-        const uint64_t bd = b * d;
-        uint64_t tmp = (bd >> 32) + (ad & M32) + (bc & M32);
-        tmp += 1U << 31;  /// mult_round
-        return DiyFp(ac + (ad >> 32) + (bc >> 32) + (tmp >> 32), e + rhs.e + 64);
-#endif
-    }
-
-    DiyFp Normalize() const {
-#if defined(_MSC_VER) && defined(_M_AMD64)
-        unsigned long index;
-		_BitScanReverse64(&index, f);
-		return DiyFp(f << (63 - index), e - (63 - index));
-#elif defined(__GNUC__)
-        int s = __builtin_clzll(f);
-        return DiyFp(f << s, e - s);
-#else
-        DiyFp res = *this;
-		while (!(res.f & kDpHiddenBit)) {
-			res.f <<= 1;
-			res.e--;
-		}
-		res.f <<= (kDiySignificandSize - kDpSignificandSize - 1);
-		res.e = res.e - (kDiySignificandSize - kDpSignificandSize - 1);
-		return res;
-#endif
-    }
-
-    DiyFp NormalizeBoundary() const {
-#if defined(_MSC_VER) && defined(_M_AMD64)
-        unsigned long index;
-		_BitScanReverse64(&index, f);
-		return DiyFp (f << (63 - index), e - (63 - index));
-#else
-        DiyFp res = *this;
-        while (!(res.f & (kDpHiddenBit << 1))) {
-            res.f <<= 1;
-            res.e--;
-        }
-        res.f <<= (kDiySignificandSize - kDpSignificandSize - 2);
-        res.e = res.e - (kDiySignificandSize - kDpSignificandSize - 2);
-        return res;
-#endif
-    }
-
-    void NormalizedBoundaries(DiyFp* minus, DiyFp* plus) const {
-        DiyFp pl = DiyFp((f << 1) + 1, e - 1).NormalizeBoundary();
-        DiyFp mi = (f == kDpHiddenBit) ? DiyFp((f << 2) - 1, e - 2) : DiyFp((f << 1) - 1, e - 1);
-        mi.f <<= mi.e - pl.e;
-        mi.e = pl.e;
-        *plus = pl;
-        *minus = mi;
-    }
-
-    static const int kDiySignificandSize = 64;
-    static const int kDpSignificandSize = 52;
-    static const int kDpExponentBias = 0x3FF + kDpSignificandSize;
-    static const int kDpMinExponent = -kDpExponentBias;
-    static const uint64_t kDpExponentMask = UINT64_C2(0x7FF00000, 0x00000000);
-    static const uint64_t kDpSignificandMask = UINT64_C2(0x000FFFFF, 0xFFFFFFFF);
-    static const uint64_t kDpHiddenBit = UINT64_C2(0x00100000, 0x00000000);
-
-    uint64_t f;
-    int e;
-};
-
-inline DiyFp GetCachedPower(int e, int* K) {
-    // 10^-348, 10^-340, ..., 10^340
-    static const uint64_t kCachedPowers_F[] = {
-            UINT64_C2(0xfa8fd5a0, 0x081c0288), UINT64_C2(0xbaaee17f, 0xa23ebf76),
-            UINT64_C2(0x8b16fb20, 0x3055ac76), UINT64_C2(0xcf42894a, 0x5dce35ea),
-            UINT64_C2(0x9a6bb0aa, 0x55653b2d), UINT64_C2(0xe61acf03, 0x3d1a45df),
-            UINT64_C2(0xab70fe17, 0xc79ac6ca), UINT64_C2(0xff77b1fc, 0xbebcdc4f),
-            UINT64_C2(0xbe5691ef, 0x416bd60c), UINT64_C2(0x8dd01fad, 0x907ffc3c),
-            UINT64_C2(0xd3515c28, 0x31559a83), UINT64_C2(0x9d71ac8f, 0xada6c9b5),
-            UINT64_C2(0xea9c2277, 0x23ee8bcb), UINT64_C2(0xaecc4991, 0x4078536d),
-            UINT64_C2(0x823c1279, 0x5db6ce57), UINT64_C2(0xc2109436, 0x4dfb5637),
-            UINT64_C2(0x9096ea6f, 0x3848984f), UINT64_C2(0xd77485cb, 0x25823ac7),
-            UINT64_C2(0xa086cfcd, 0x97bf97f4), UINT64_C2(0xef340a98, 0x172aace5),
-            UINT64_C2(0xb23867fb, 0x2a35b28e), UINT64_C2(0x84c8d4df, 0xd2c63f3b),
-            UINT64_C2(0xc5dd4427, 0x1ad3cdba), UINT64_C2(0x936b9fce, 0xbb25c996),
-            UINT64_C2(0xdbac6c24, 0x7d62a584), UINT64_C2(0xa3ab6658, 0x0d5fdaf6),
-            UINT64_C2(0xf3e2f893, 0xdec3f126), UINT64_C2(0xb5b5ada8, 0xaaff80b8),
-            UINT64_C2(0x87625f05, 0x6c7c4a8b), UINT64_C2(0xc9bcff60, 0x34c13053),
-            UINT64_C2(0x964e858c, 0x91ba2655), UINT64_C2(0xdff97724, 0x70297ebd),
-            UINT64_C2(0xa6dfbd9f, 0xb8e5b88f), UINT64_C2(0xf8a95fcf, 0x88747d94),
-            UINT64_C2(0xb9447093, 0x8fa89bcf), UINT64_C2(0x8a08f0f8, 0xbf0f156b),
-            UINT64_C2(0xcdb02555, 0x653131b6), UINT64_C2(0x993fe2c6, 0xd07b7fac),
-            UINT64_C2(0xe45c10c4, 0x2a2b3b06), UINT64_C2(0xaa242499, 0x697392d3),
-            UINT64_C2(0xfd87b5f2, 0x8300ca0e), UINT64_C2(0xbce50864, 0x92111aeb),
-            UINT64_C2(0x8cbccc09, 0x6f5088cc), UINT64_C2(0xd1b71758, 0xe219652c),
-            UINT64_C2(0x9c400000, 0x00000000), UINT64_C2(0xe8d4a510, 0x00000000),
-            UINT64_C2(0xad78ebc5, 0xac620000), UINT64_C2(0x813f3978, 0xf8940984),
-            UINT64_C2(0xc097ce7b, 0xc90715b3), UINT64_C2(0x8f7e32ce, 0x7bea5c70),
-            UINT64_C2(0xd5d238a4, 0xabe98068), UINT64_C2(0x9f4f2726, 0x179a2245),
-            UINT64_C2(0xed63a231, 0xd4c4fb27), UINT64_C2(0xb0de6538, 0x8cc8ada8),
-            UINT64_C2(0x83c7088e, 0x1aab65db), UINT64_C2(0xc45d1df9, 0x42711d9a),
-            UINT64_C2(0x924d692c, 0xa61be758), UINT64_C2(0xda01ee64, 0x1a708dea),
-            UINT64_C2(0xa26da399, 0x9aef774a), UINT64_C2(0xf209787b, 0xb47d6b85),
-            UINT64_C2(0xb454e4a1, 0x79dd1877), UINT64_C2(0x865b8692, 0x5b9bc5c2),
-            UINT64_C2(0xc83553c5, 0xc8965d3d), UINT64_C2(0x952ab45c, 0xfa97a0b3),
-            UINT64_C2(0xde469fbd, 0x99a05fe3), UINT64_C2(0xa59bc234, 0xdb398c25),
-            UINT64_C2(0xf6c69a72, 0xa3989f5c), UINT64_C2(0xb7dcbf53, 0x54e9bece),
-            UINT64_C2(0x88fcf317, 0xf22241e2), UINT64_C2(0xcc20ce9b, 0xd35c78a5),
-            UINT64_C2(0x98165af3, 0x7b2153df), UINT64_C2(0xe2a0b5dc, 0x971f303a),
-            UINT64_C2(0xa8d9d153, 0x5ce3b396), UINT64_C2(0xfb9b7cd9, 0xa4a7443c),
-            UINT64_C2(0xbb764c4c, 0xa7a44410), UINT64_C2(0x8bab8eef, 0xb6409c1a),
-            UINT64_C2(0xd01fef10, 0xa657842c), UINT64_C2(0x9b10a4e5, 0xe9913129),
-            UINT64_C2(0xe7109bfb, 0xa19c0c9d), UINT64_C2(0xac2820d9, 0x623bf429),
-            UINT64_C2(0x80444b5e, 0x7aa7cf85), UINT64_C2(0xbf21e440, 0x03acdd2d),
-            UINT64_C2(0x8e679c2f, 0x5e44ff8f), UINT64_C2(0xd433179d, 0x9c8cb841),
-            UINT64_C2(0x9e19db92, 0xb4e31ba9), UINT64_C2(0xeb96bf6e, 0xbadf77d9),
-            UINT64_C2(0xaf87023b, 0x9bf0ee6b)
-    };
-    static const int16_t kCachedPowers_E[] = {
-            -1220, -1193, -1166, -1140, -1113, -1087, -1060, -1034, -1007,  -980,
-            -954,  -927,  -901,  -874,  -847,  -821,  -794,  -768,  -741,  -715,
-            -688,  -661,  -635,  -608,  -582,  -555,  -529,  -502,  -475,  -449,
-            -422,  -396,  -369,  -343,  -316,  -289,  -263,  -236,  -210,  -183,
-            -157,  -130,  -103,   -77,   -50,   -24,     3,    30,    56,    83,
-            109,   136,   162,   189,   216,   242,   269,   295,   322,   348,
-            375,   402,   428,   455,   481,   508,   534,   561,   588,   614,
-            641,   667,   694,   720,   747,   774,   800,   827,   853,   880,
-            907,   933,   960,   986,  1013,  1039,  1066
-    };
-
-    //int k = static_cast<int>(ceil((-61 - e) * 0.30102999566398114)) + 374;
-    double dk = (-61 - e) * 0.30102999566398114 + 347;	// dk must be positive, so can do ceiling in positive
-    int k = static_cast<int>(dk);
-    if (k != dk)
-        k++;
-
-    unsigned index = static_cast<unsigned>((k >> 3) + 1);
-    *K = -(-348 + static_cast<int>(index << 3));	// decimal exponent no need lookup table
-
-    assert(index < sizeof(kCachedPowers_F) / sizeof(kCachedPowers_F[0]));
-    return DiyFp(kCachedPowers_F[index], kCachedPowers_E[index]);
-}
-
-inline void GrisuRound(char* buffer, int len, uint64_t delta, uint64_t rest, uint64_t ten_kappa, uint64_t wp_w) {
-    while (rest < wp_w && delta - rest >= ten_kappa &&
-           (rest + ten_kappa < wp_w ||  /// closer
-            wp_w - rest > rest + ten_kappa - wp_w)) {
-        buffer[len - 1]--;
-        rest += ten_kappa;
-    }
-}
-
-inline unsigned CountDecimalDigit32(uint32_t n) {
-    // Simple pure C++ implementation was faster than __builtin_clz version in this situation.
-    if (n < 10) return 1;
-    if (n < 100) return 2;
-    if (n < 1000) return 3;
-    if (n < 10000) return 4;
-    if (n < 100000) return 5;
-    if (n < 1000000) return 6;
-    if (n < 10000000) return 7;
-    if (n < 100000000) return 8;
-    if (n < 1000000000) return 9;
-    return 10;
-}
-
-inline void DigitGen(const DiyFp& W, const DiyFp& Mp, uint64_t delta, char* buffer, int* len, int* K) {
-    static const uint32_t kPow10[] = { 1, 10, 100, 1000, 10000, 100000, 1000000, 10000000, 100000000, 1000000000 };
-    const DiyFp one(uint64_t(1) << -Mp.e, Mp.e);
-    const DiyFp wp_w = Mp - W;
-    uint32_t p1 = static_cast<uint32_t>(Mp.f >> -one.e);
-    uint64_t p2 = Mp.f & (one.f - 1);
-    int kappa = static_cast<int>(CountDecimalDigit32(p1));
-    *len = 0;
-
-    while (kappa > 0) {
-        uint32_t d;
-        switch (kappa) {
-            case 10: d = p1 / 1000000000; p1 %= 1000000000; break;
-            case  9: d = p1 /  100000000; p1 %=  100000000; break;
-            case  8: d = p1 /   10000000; p1 %=   10000000; break;
-            case  7: d = p1 /    1000000; p1 %=    1000000; break;
-            case  6: d = p1 /     100000; p1 %=     100000; break;
-            case  5: d = p1 /      10000; p1 %=      10000; break;
-            case  4: d = p1 /       1000; p1 %=       1000; break;
-            case  3: d = p1 /        100; p1 %=        100; break;
-            case  2: d = p1 /         10; p1 %=         10; break;
-            case  1: d = p1;              p1 =           0; break;
-            default:
-#if defined(_MSC_VER)
-                __assume(0);
-#elif __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 5)
-                __builtin_unreachable();
-#else
-                d = 0;
-#endif
-        }
-        if (d || *len)
-            buffer[(*len)++] = '0' + static_cast<char>(d);
-        kappa--;
-        uint64_t tmp = (static_cast<uint64_t>(p1) << -one.e) + p2;
-        if (tmp <= delta) {
-            *K += kappa;
-            GrisuRound(buffer, *len, delta, tmp, static_cast<uint64_t>(kPow10[kappa]) << -one.e, wp_w.f);
-            return;
-        }
-    }
-
-    // kappa = 0
-    for (;;) {
-        p2 *= 10;
-        delta *= 10;
-        char d = static_cast<char>(p2 >> -one.e);
-        if (d || *len)
-            buffer[(*len)++] = '0' + d;
-        p2 &= one.f - 1;
-        kappa--;
-        if (p2 < delta) {
-            *K += kappa;
-            GrisuRound(buffer, *len, delta, p2, one.f, wp_w.f * kPow10[-kappa]);
-            return;
-        }
-    }
-}
-
-inline void Grisu2(double value, char* buffer, int* length, int* K) {
-    const DiyFp v(value);
-    DiyFp w_m, w_p;
-    v.NormalizedBoundaries(&w_m, &w_p);
-
-    const DiyFp c_mk = GetCachedPower(w_p.e, K);
-    const DiyFp W = v.Normalize() * c_mk;
-    DiyFp Wp = w_p * c_mk;
-    DiyFp Wm = w_m * c_mk;
-    Wm.f++;
-    Wp.f--;
-    DigitGen(W, Wp, Wp.f - Wm.f, buffer, length, K);
-}
-
-inline const char* GetDigitsLut() {
-    static const char cDigitsLut[200] = {
-            '0', '0', '0', '1', '0', '2', '0', '3', '0', '4', '0', '5', '0', '6', '0', '7', '0', '8', '0', '9',
-            '1', '0', '1', '1', '1', '2', '1', '3', '1', '4', '1', '5', '1', '6', '1', '7', '1', '8', '1', '9',
-            '2', '0', '2', '1', '2', '2', '2', '3', '2', '4', '2', '5', '2', '6', '2', '7', '2', '8', '2', '9',
-            '3', '0', '3', '1', '3', '2', '3', '3', '3', '4', '3', '5', '3', '6', '3', '7', '3', '8', '3', '9',
-            '4', '0', '4', '1', '4', '2', '4', '3', '4', '4', '4', '5', '4', '6', '4', '7', '4', '8', '4', '9',
-            '5', '0', '5', '1', '5', '2', '5', '3', '5', '4', '5', '5', '5', '6', '5', '7', '5', '8', '5', '9',
-            '6', '0', '6', '1', '6', '2', '6', '3', '6', '4', '6', '5', '6', '6', '6', '7', '6', '8', '6', '9',
-            '7', '0', '7', '1', '7', '2', '7', '3', '7', '4', '7', '5', '7', '6', '7', '7', '7', '8', '7', '9',
-            '8', '0', '8', '1', '8', '2', '8', '3', '8', '4', '8', '5', '8', '6', '8', '7', '8', '8', '8', '9',
-            '9', '0', '9', '1', '9', '2', '9', '3', '9', '4', '9', '5', '9', '6', '9', '7', '9', '8', '9', '9'
-    };
-    return cDigitsLut;
-}
-
-inline void WriteExponent(int K, char* buffer) {
-    if (K < 0) {
-        *buffer++ = '-';
-        K = -K;
-    }
-
-    if (K >= 100) {
-        *buffer++ = '0' + static_cast<char>(K / 100);
-        K %= 100;
-        const char* d = GetDigitsLut() + K * 2;
-        *buffer++ = d[0];
-        *buffer++ = d[1];
-    }
-    else if (K >= 10) {
-        const char* d = GetDigitsLut() + K * 2;
-        *buffer++ = d[0];
-        *buffer++ = d[1];
-    }
-    else
-        *buffer++ = '0' + static_cast<char>(K);
-
-    *buffer = '\0';
-}
-
-inline void Prettify(char* buffer, int length, int k) {
-    const int kk = length + k;	// 10^(kk-1) <= v < 10^kk
-
-    if (length <= kk && kk <= 21) {
-        // 1234e7 -> 12340000000
-        for (int i = length; i < kk; i++)
-            buffer[i] = '0';
-        buffer[kk] = '.';
-        buffer[kk + 1] = '0';
-        buffer[kk + 2] = '\0';
-    }
-    else if (0 < kk && kk <= 21) {
-        // 1234e-2 -> 12.34
-        memmove(&buffer[kk + 1], &buffer[kk], length - kk);
-        buffer[kk] = '.';
-        buffer[length + 1] = '\0';
-    }
-    else if (-6 < kk && kk <= 0) {
-        // 1234e-6 -> 0.001234
-        const int offset = 2 - kk;
-        memmove(&buffer[offset], &buffer[0], length);
-        buffer[0] = '0';
-        buffer[1] = '.';
-        for (int i = 2; i < offset; i++)
-            buffer[i] = '0';
-        buffer[length + offset] = '\0';
-    }
-    else if (length == 1) {
-        // 1e30
-        buffer[1] = 'e';
-        WriteExponent(kk - 1, &buffer[2]);
-    }
-    else {
-        // 1234e30 -> 1.234e33
-        memmove(&buffer[2], &buffer[1], length - 1);
-        buffer[1] = '.';
-        buffer[length + 1] = 'e';
-        WriteExponent(kk - 1, &buffer[0 + length + 2]);
-    }
-}
-
-inline void dtoa_milo(double value, char* buffer) {
-    // Not handling NaN and inf
-    assert(!std::isnan(value));
-    assert(!std::isinf(value));
-
-    if (value == 0) {
-        buffer[0] = '0';
-        buffer[1] = '.';
-        buffer[2] = '0';
-        buffer[3] = '\0';
-    }
-    else {
-        if (value < 0) {
-            *buffer++ = '-';
-            value = -value;
-        }
-        int length, K;
-        Grisu2(value, buffer, &length, &K);
-        Prettify(buffer, length, K);
-    }
+#pragma once
+#include <assert.h>
+#include <cmath>
+#include <string.h>
+#include <stdint.h>
+
+#define UINT64_C2(h, l) ((static_cast<uint64_t>(h) << 32) | static_cast<uint64_t>(l))
+
+struct DiyFp {
+    DiyFp() {}
+
+    DiyFp(uint64_t f, int e) : f(f), e(e) {}
+
+    DiyFp(double d) {
+        union {
+            double d;
+            uint64_t u64;
+        } u = { d };
+
+        int biased_e = (u.u64 & kDpExponentMask) >> kDpSignificandSize;
+        uint64_t significand = (u.u64 & kDpSignificandMask);
+        if (biased_e != 0) {
+            f = significand + kDpHiddenBit;
+            e = biased_e - kDpExponentBias;
+        }
+        else {
+            f = significand;
+            e = kDpMinExponent + 1;
+        }
+    }
+
+    DiyFp operator-(const DiyFp& rhs) const {
+        assert(e == rhs.e);
+        assert(f >= rhs.f);
+        return DiyFp(f - rhs.f, e);
+    }
+
+    DiyFp operator*(const DiyFp& rhs) const {
+#if defined(_MSC_VER) && defined(_M_AMD64)
+        uint64_t h;
+		uint64_t l = _umul128(f, rhs.f, &h);
+		if (l & (uint64_t(1) << 63)) // rounding
+			h++;
+		return DiyFp(h, e + rhs.e + 64);
+#elif (__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 6)) && defined(__x86_64__)
+        unsigned __int128 p = static_cast<unsigned __int128>(f) * static_cast<unsigned __int128>(rhs.f);
+		uint64_t h = p >> 64;
+		uint64_t l = static_cast<uint64_t>(p);
+		if (l & (uint64_t(1) << 63)) // rounding
+			h++;
+		return DiyFp(h, e + rhs.e + 64);
+#else
+        const uint64_t M32 = 0xFFFFFFFF;
+        const uint64_t a = f >> 32;
+        const uint64_t b = f & M32;
+        const uint64_t c = rhs.f >> 32;
+        const uint64_t d = rhs.f & M32;
+        const uint64_t ac = a * c;
+        const uint64_t bc = b * c;
+        const uint64_t ad = a * d;
+        const uint64_t bd = b * d;
+        uint64_t tmp = (bd >> 32) + (ad & M32) + (bc & M32);
+        tmp += 1U << 31;  /// mult_round
+        return DiyFp(ac + (ad >> 32) + (bc >> 32) + (tmp >> 32), e + rhs.e + 64);
+#endif
+    }
+
+    DiyFp Normalize() const {
+#if defined(_MSC_VER) && defined(_M_AMD64)
+        unsigned long index;
+		_BitScanReverse64(&index, f);
+		return DiyFp(f << (63 - index), e - (63 - index));
+#elif defined(__GNUC__)
+        int s = __builtin_clzll(f);
+        return DiyFp(f << s, e - s);
+#else
+        DiyFp res = *this;
+		while (!(res.f & kDpHiddenBit)) {
+			res.f <<= 1;
+			res.e--;
+		}
+		res.f <<= (kDiySignificandSize - kDpSignificandSize - 1);
+		res.e = res.e - (kDiySignificandSize - kDpSignificandSize - 1);
+		return res;
+#endif
+    }
+
+    DiyFp NormalizeBoundary() const {
+#if defined(_MSC_VER) && defined(_M_AMD64)
+        unsigned long index;
+		_BitScanReverse64(&index, f);
+		return DiyFp (f << (63 - index), e - (63 - index));
+#else
+        DiyFp res = *this;
+        while (!(res.f & (kDpHiddenBit << 1))) {
+            res.f <<= 1;
+            res.e--;
+        }
+        res.f <<= (kDiySignificandSize - kDpSignificandSize - 2);
+        res.e = res.e - (kDiySignificandSize - kDpSignificandSize - 2);
+        return res;
+#endif
+    }
+
+    void NormalizedBoundaries(DiyFp* minus, DiyFp* plus) const {
+        DiyFp pl = DiyFp((f << 1) + 1, e - 1).NormalizeBoundary();
+        DiyFp mi = (f == kDpHiddenBit) ? DiyFp((f << 2) - 1, e - 2) : DiyFp((f << 1) - 1, e - 1);
+        mi.f <<= mi.e - pl.e;
+        mi.e = pl.e;
+        *plus = pl;
+        *minus = mi;
+    }
+
+    static const int kDiySignificandSize = 64;
+    static const int kDpSignificandSize = 52;
+    static const int kDpExponentBias = 0x3FF + kDpSignificandSize;
+    static const int kDpMinExponent = -kDpExponentBias;
+    static const uint64_t kDpExponentMask = UINT64_C2(0x7FF00000, 0x00000000);
+    static const uint64_t kDpSignificandMask = UINT64_C2(0x000FFFFF, 0xFFFFFFFF);
+    static const uint64_t kDpHiddenBit = UINT64_C2(0x00100000, 0x00000000);
+
+    uint64_t f;
+    int e;
+};
+
+inline DiyFp GetCachedPower(int e, int* K) {
+    // 10^-348, 10^-340, ..., 10^340
+    static const uint64_t kCachedPowers_F[] = {
+            UINT64_C2(0xfa8fd5a0, 0x081c0288), UINT64_C2(0xbaaee17f, 0xa23ebf76),
+            UINT64_C2(0x8b16fb20, 0x3055ac76), UINT64_C2(0xcf42894a, 0x5dce35ea),
+            UINT64_C2(0x9a6bb0aa, 0x55653b2d), UINT64_C2(0xe61acf03, 0x3d1a45df),
+            UINT64_C2(0xab70fe17, 0xc79ac6ca), UINT64_C2(0xff77b1fc, 0xbebcdc4f),
+            UINT64_C2(0xbe5691ef, 0x416bd60c), UINT64_C2(0x8dd01fad, 0x907ffc3c),
+            UINT64_C2(0xd3515c28, 0x31559a83), UINT64_C2(0x9d71ac8f, 0xada6c9b5),
+            UINT64_C2(0xea9c2277, 0x23ee8bcb), UINT64_C2(0xaecc4991, 0x4078536d),
+            UINT64_C2(0x823c1279, 0x5db6ce57), UINT64_C2(0xc2109436, 0x4dfb5637),
+            UINT64_C2(0x9096ea6f, 0x3848984f), UINT64_C2(0xd77485cb, 0x25823ac7),
+            UINT64_C2(0xa086cfcd, 0x97bf97f4), UINT64_C2(0xef340a98, 0x172aace5),
+            UINT64_C2(0xb23867fb, 0x2a35b28e), UINT64_C2(0x84c8d4df, 0xd2c63f3b),
+            UINT64_C2(0xc5dd4427, 0x1ad3cdba), UINT64_C2(0x936b9fce, 0xbb25c996),
+            UINT64_C2(0xdbac6c24, 0x7d62a584), UINT64_C2(0xa3ab6658, 0x0d5fdaf6),
+            UINT64_C2(0xf3e2f893, 0xdec3f126), UINT64_C2(0xb5b5ada8, 0xaaff80b8),
+            UINT64_C2(0x87625f05, 0x6c7c4a8b), UINT64_C2(0xc9bcff60, 0x34c13053),
+            UINT64_C2(0x964e858c, 0x91ba2655), UINT64_C2(0xdff97724, 0x70297ebd),
+            UINT64_C2(0xa6dfbd9f, 0xb8e5b88f), UINT64_C2(0xf8a95fcf, 0x88747d94),
+            UINT64_C2(0xb9447093, 0x8fa89bcf), UINT64_C2(0x8a08f0f8, 0xbf0f156b),
+            UINT64_C2(0xcdb02555, 0x653131b6), UINT64_C2(0x993fe2c6, 0xd07b7fac),
+            UINT64_C2(0xe45c10c4, 0x2a2b3b06), UINT64_C2(0xaa242499, 0x697392d3),
+            UINT64_C2(0xfd87b5f2, 0x8300ca0e), UINT64_C2(0xbce50864, 0x92111aeb),
+            UINT64_C2(0x8cbccc09, 0x6f5088cc), UINT64_C2(0xd1b71758, 0xe219652c),
+            UINT64_C2(0x9c400000, 0x00000000), UINT64_C2(0xe8d4a510, 0x00000000),
+            UINT64_C2(0xad78ebc5, 0xac620000), UINT64_C2(0x813f3978, 0xf8940984),
+            UINT64_C2(0xc097ce7b, 0xc90715b3), UINT64_C2(0x8f7e32ce, 0x7bea5c70),
+            UINT64_C2(0xd5d238a4, 0xabe98068), UINT64_C2(0x9f4f2726, 0x179a2245),
+            UINT64_C2(0xed63a231, 0xd4c4fb27), UINT64_C2(0xb0de6538, 0x8cc8ada8),
+            UINT64_C2(0x83c7088e, 0x1aab65db), UINT64_C2(0xc45d1df9, 0x42711d9a),
+            UINT64_C2(0x924d692c, 0xa61be758), UINT64_C2(0xda01ee64, 0x1a708dea),
+            UINT64_C2(0xa26da399, 0x9aef774a), UINT64_C2(0xf209787b, 0xb47d6b85),
+            UINT64_C2(0xb454e4a1, 0x79dd1877), UINT64_C2(0x865b8692, 0x5b9bc5c2),
+            UINT64_C2(0xc83553c5, 0xc8965d3d), UINT64_C2(0x952ab45c, 0xfa97a0b3),
+            UINT64_C2(0xde469fbd, 0x99a05fe3), UINT64_C2(0xa59bc234, 0xdb398c25),
+            UINT64_C2(0xf6c69a72, 0xa3989f5c), UINT64_C2(0xb7dcbf53, 0x54e9bece),
+            UINT64_C2(0x88fcf317, 0xf22241e2), UINT64_C2(0xcc20ce9b, 0xd35c78a5),
+            UINT64_C2(0x98165af3, 0x7b2153df), UINT64_C2(0xe2a0b5dc, 0x971f303a),
+            UINT64_C2(0xa8d9d153, 0x5ce3b396), UINT64_C2(0xfb9b7cd9, 0xa4a7443c),
+            UINT64_C2(0xbb764c4c, 0xa7a44410), UINT64_C2(0x8bab8eef, 0xb6409c1a),
+            UINT64_C2(0xd01fef10, 0xa657842c), UINT64_C2(0x9b10a4e5, 0xe9913129),
+            UINT64_C2(0xe7109bfb, 0xa19c0c9d), UINT64_C2(0xac2820d9, 0x623bf429),
+            UINT64_C2(0x80444b5e, 0x7aa7cf85), UINT64_C2(0xbf21e440, 0x03acdd2d),
+            UINT64_C2(0x8e679c2f, 0x5e44ff8f), UINT64_C2(0xd433179d, 0x9c8cb841),
+            UINT64_C2(0x9e19db92, 0xb4e31ba9), UINT64_C2(0xeb96bf6e, 0xbadf77d9),
+            UINT64_C2(0xaf87023b, 0x9bf0ee6b)
+    };
+    static const int16_t kCachedPowers_E[] = {
+            -1220, -1193, -1166, -1140, -1113, -1087, -1060, -1034, -1007,  -980,
+            -954,  -927,  -901,  -874,  -847,  -821,  -794,  -768,  -741,  -715,
+            -688,  -661,  -635,  -608,  -582,  -555,  -529,  -502,  -475,  -449,
+            -422,  -396,  -369,  -343,  -316,  -289,  -263,  -236,  -210,  -183,
+            -157,  -130,  -103,   -77,   -50,   -24,     3,    30,    56,    83,
+            109,   136,   162,   189,   216,   242,   269,   295,   322,   348,
+            375,   402,   428,   455,   481,   508,   534,   561,   588,   614,
+            641,   667,   694,   720,   747,   774,   800,   827,   853,   880,
+            907,   933,   960,   986,  1013,  1039,  1066
+    };
+
+    //int k = static_cast<int>(ceil((-61 - e) * 0.30102999566398114)) + 374;
+    double dk = (-61 - e) * 0.30102999566398114 + 347;	// dk must be positive, so can do ceiling in positive
+    int k = static_cast<int>(dk);
+    if (k != dk)
+        k++;
+
+    unsigned index = static_cast<unsigned>((k >> 3) + 1);
+    *K = -(-348 + static_cast<int>(index << 3));	// decimal exponent no need lookup table
+
+    assert(index < sizeof(kCachedPowers_F) / sizeof(kCachedPowers_F[0]));
+    return DiyFp(kCachedPowers_F[index], kCachedPowers_E[index]);
+}
+
+inline void GrisuRound(char* buffer, int len, uint64_t delta, uint64_t rest, uint64_t ten_kappa, uint64_t wp_w) {
+    while (rest < wp_w && delta - rest >= ten_kappa &&
+           (rest + ten_kappa < wp_w ||  /// closer
+            wp_w - rest > rest + ten_kappa - wp_w)) {
+        buffer[len - 1]--;
+        rest += ten_kappa;
+    }
+}
+
+inline unsigned CountDecimalDigit32(uint32_t n) {
+    // Simple pure C++ implementation was faster than __builtin_clz version in this situation.
+    if (n < 10) return 1;
+    if (n < 100) return 2;
+    if (n < 1000) return 3;
+    if (n < 10000) return 4;
+    if (n < 100000) return 5;
+    if (n < 1000000) return 6;
+    if (n < 10000000) return 7;
+    if (n < 100000000) return 8;
+    if (n < 1000000000) return 9;
+    return 10;
+}
+
+inline void DigitGen(const DiyFp& W, const DiyFp& Mp, uint64_t delta, char* buffer, int* len, int* K) {
+    static const uint32_t kPow10[] = { 1, 10, 100, 1000, 10000, 100000, 1000000, 10000000, 100000000, 1000000000 };
+    const DiyFp one(uint64_t(1) << -Mp.e, Mp.e);
+    const DiyFp wp_w = Mp - W;
+    uint32_t p1 = static_cast<uint32_t>(Mp.f >> -one.e);
+    uint64_t p2 = Mp.f & (one.f - 1);
+    int kappa = static_cast<int>(CountDecimalDigit32(p1));
+    *len = 0;
+
+    while (kappa > 0) {
+        uint32_t d;
+        switch (kappa) {
+            case 10: d = p1 / 1000000000; p1 %= 1000000000; break;
+            case  9: d = p1 /  100000000; p1 %=  100000000; break;
+            case  8: d = p1 /   10000000; p1 %=   10000000; break;
+            case  7: d = p1 /    1000000; p1 %=    1000000; break;
+            case  6: d = p1 /     100000; p1 %=     100000; break;
+            case  5: d = p1 /      10000; p1 %=      10000; break;
+            case  4: d = p1 /       1000; p1 %=       1000; break;
+            case  3: d = p1 /        100; p1 %=        100; break;
+            case  2: d = p1 /         10; p1 %=         10; break;
+            case  1: d = p1;              p1 =           0; break;
+            default:
+#if defined(_MSC_VER)
+                __assume(0);
+#elif __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 5)
+                __builtin_unreachable();
+#else
+                d = 0;
+#endif
+        }
+        if (d || *len)
+            buffer[(*len)++] = '0' + static_cast<char>(d);
+        kappa--;
+        uint64_t tmp = (static_cast<uint64_t>(p1) << -one.e) + p2;
+        if (tmp <= delta) {
+            *K += kappa;
+            GrisuRound(buffer, *len, delta, tmp, static_cast<uint64_t>(kPow10[kappa]) << -one.e, wp_w.f);
+            return;
+        }
+    }
+
+    // kappa = 0
+    for (;;) {
+        p2 *= 10;
+        delta *= 10;
+        char d = static_cast<char>(p2 >> -one.e);
+        if (d || *len)
+            buffer[(*len)++] = '0' + d;
+        p2 &= one.f - 1;
+        kappa--;
+        if (p2 < delta) {
+            *K += kappa;
+            GrisuRound(buffer, *len, delta, p2, one.f, wp_w.f * kPow10[-kappa]);
+            return;
+        }
+    }
+}
+
+inline void Grisu2(double value, char* buffer, int* length, int* K) {
+    const DiyFp v(value);
+    DiyFp w_m, w_p;
+    v.NormalizedBoundaries(&w_m, &w_p);
+
+    const DiyFp c_mk = GetCachedPower(w_p.e, K);
+    const DiyFp W = v.Normalize() * c_mk;
+    DiyFp Wp = w_p * c_mk;
+    DiyFp Wm = w_m * c_mk;
+    Wm.f++;
+    Wp.f--;
+    DigitGen(W, Wp, Wp.f - Wm.f, buffer, length, K);
+}
+
+inline const char* GetDigitsLut() {
+    static const char cDigitsLut[200] = {
+            '0', '0', '0', '1', '0', '2', '0', '3', '0', '4', '0', '5', '0', '6', '0', '7', '0', '8', '0', '9',
+            '1', '0', '1', '1', '1', '2', '1', '3', '1', '4', '1', '5', '1', '6', '1', '7', '1', '8', '1', '9',
+            '2', '0', '2', '1', '2', '2', '2', '3', '2', '4', '2', '5', '2', '6', '2', '7', '2', '8', '2', '9',
+            '3', '0', '3', '1', '3', '2', '3', '3', '3', '4', '3', '5', '3', '6', '3', '7', '3', '8', '3', '9',
+            '4', '0', '4', '1', '4', '2', '4', '3', '4', '4', '4', '5', '4', '6', '4', '7', '4', '8', '4', '9',
+            '5', '0', '5', '1', '5', '2', '5', '3', '5', '4', '5', '5', '5', '6', '5', '7', '5', '8', '5', '9',
+            '6', '0', '6', '1', '6', '2', '6', '3', '6', '4', '6', '5', '6', '6', '6', '7', '6', '8', '6', '9',
+            '7', '0', '7', '1', '7', '2', '7', '3', '7', '4', '7', '5', '7', '6', '7', '7', '7', '8', '7', '9',
+            '8', '0', '8', '1', '8', '2', '8', '3', '8', '4', '8', '5', '8', '6', '8', '7', '8', '8', '8', '9',
+            '9', '0', '9', '1', '9', '2', '9', '3', '9', '4', '9', '5', '9', '6', '9', '7', '9', '8', '9', '9'
+    };
+    return cDigitsLut;
+}
+
+inline void WriteExponent(int K, char* buffer) {
+    if (K < 0) {
+        *buffer++ = '-';
+        K = -K;
+    }
+
+    if (K >= 100) {
+        *buffer++ = '0' + static_cast<char>(K / 100);
+        K %= 100;
+        const char* d = GetDigitsLut() + K * 2;
+        *buffer++ = d[0];
+        *buffer++ = d[1];
+    }
+    else if (K >= 10) {
+        const char* d = GetDigitsLut() + K * 2;
+        *buffer++ = d[0];
+        *buffer++ = d[1];
+    }
+    else
+        *buffer++ = '0' + static_cast<char>(K);
+
+    *buffer = '\0';
+}
+
+inline void Prettify(char* buffer, int length, int k) {
+    const int kk = length + k;	// 10^(kk-1) <= v < 10^kk
+
+    if (length <= kk && kk <= 21) {
+        // 1234e7 -> 12340000000
+        for (int i = length; i < kk; i++)
+            buffer[i] = '0';
+        buffer[kk] = '.';
+        buffer[kk + 1] = '0';
+        buffer[kk + 2] = '\0';
+    }
+    else if (0 < kk && kk <= 21) {
+        // 1234e-2 -> 12.34
+        memmove(&buffer[kk + 1], &buffer[kk], length - kk);
+        buffer[kk] = '.';
+        buffer[length + 1] = '\0';
+    }
+    else if (-6 < kk && kk <= 0) {
+        // 1234e-6 -> 0.001234
+        const int offset = 2 - kk;
+        memmove(&buffer[offset], &buffer[0], length);
+        buffer[0] = '0';
+        buffer[1] = '.';
+        for (int i = 2; i < offset; i++)
+            buffer[i] = '0';
+        buffer[length + offset] = '\0';
+    }
+    else if (length == 1) {
+        // 1e30
+        buffer[1] = 'e';
+        WriteExponent(kk - 1, &buffer[2]);
+    }
+    else {
+        // 1234e30 -> 1.234e33
+        memmove(&buffer[2], &buffer[1], length - 1);
+        buffer[1] = '.';
+        buffer[length + 1] = 'e';
+        WriteExponent(kk - 1, &buffer[0 + length + 2]);
+    }
+}
+
+inline void dtoa_milo(double value, char* buffer) {
+    // Not handling NaN and inf
+    assert(!std::isnan(value));
+    assert(!std::isinf(value));
+
+    if (value == 0) {
+        buffer[0] = '0';
+        buffer[1] = '.';
+        buffer[2] = '0';
+        buffer[3] = '\0';
+    }
+    else {
+        if (value < 0) {
+            *buffer++ = '-';
+            value = -value;
+        }
+        int length, K;
+        Grisu2(value, buffer, &length, &K);
+        Prettify(buffer, length, K);
+    }
 }

third_party/CityFlow/extern/pybind11/.appveyor.yml

@@ -1,35 +1,35 @@
-version: 1.0.{build}
-image:
-- Visual Studio 2017
-test: off
-skip_branch_with_pr: true
-build:
-  parallel: true
-platform:
-- x86
-environment:
-  matrix:
-  - PYTHON: 36
-    CONFIG: Debug
-install:
-- ps: |
-    $env:CMAKE_GENERATOR = "Visual Studio 15 2017"
-    if ($env:PLATFORM -eq "x64") { $env:PYTHON = "$env:PYTHON-x64" }
-    $env:PATH = "C:\Python$env:PYTHON\;C:\Python$env:PYTHON\Scripts\;$env:PATH"
-    python -W ignore -m pip install --upgrade pip wheel
-    python -W ignore -m pip install pytest numpy --no-warn-script-location pytest-timeout
-- ps: |
-    Start-FileDownload 'https://gitlab.com/libeigen/eigen/-/archive/3.3.7/eigen-3.3.7.zip'
-    7z x eigen-3.3.7.zip -y > $null
-    $env:CMAKE_INCLUDE_PATH = "eigen-3.3.7;$env:CMAKE_INCLUDE_PATH"
-build_script:
-- cmake -G "%CMAKE_GENERATOR%" -A "%CMAKE_ARCH%"
-    -DCMAKE_CXX_STANDARD=14
-    -DPYBIND11_WERROR=ON
-    -DDOWNLOAD_CATCH=ON
-    -DCMAKE_SUPPRESS_REGENERATION=1
-    .
-- set MSBuildLogger="C:\Program Files\AppVeyor\BuildAgent\Appveyor.MSBuildLogger.dll"
-- cmake --build . --config %CONFIG% --target pytest -- /m /v:m /logger:%MSBuildLogger%
-- cmake --build . --config %CONFIG% --target cpptest -- /m /v:m /logger:%MSBuildLogger%
-on_failure: if exist "tests\test_cmake_build" type tests\test_cmake_build\*.log*
+version: 1.0.{build}
+image:
+- Visual Studio 2017
+test: off
+skip_branch_with_pr: true
+build:
+  parallel: true
+platform:
+- x86
+environment:
+  matrix:
+  - PYTHON: 36
+    CONFIG: Debug
+install:
+- ps: |
+    $env:CMAKE_GENERATOR = "Visual Studio 15 2017"
+    if ($env:PLATFORM -eq "x64") { $env:PYTHON = "$env:PYTHON-x64" }
+    $env:PATH = "C:\Python$env:PYTHON\;C:\Python$env:PYTHON\Scripts\;$env:PATH"
+    python -W ignore -m pip install --upgrade pip wheel
+    python -W ignore -m pip install pytest numpy --no-warn-script-location pytest-timeout
+- ps: |
+    Start-FileDownload 'https://gitlab.com/libeigen/eigen/-/archive/3.3.7/eigen-3.3.7.zip'
+    7z x eigen-3.3.7.zip -y > $null
+    $env:CMAKE_INCLUDE_PATH = "eigen-3.3.7;$env:CMAKE_INCLUDE_PATH"
+build_script:
+- cmake -G "%CMAKE_GENERATOR%" -A "%CMAKE_ARCH%"
+    -DCMAKE_CXX_STANDARD=14
+    -DPYBIND11_WERROR=ON
+    -DDOWNLOAD_CATCH=ON
+    -DCMAKE_SUPPRESS_REGENERATION=1
+    .
+- set MSBuildLogger="C:\Program Files\AppVeyor\BuildAgent\Appveyor.MSBuildLogger.dll"
+- cmake --build . --config %CONFIG% --target pytest -- /m /v:m /logger:%MSBuildLogger%
+- cmake --build . --config %CONFIG% --target cpptest -- /m /v:m /logger:%MSBuildLogger%
+on_failure: if exist "tests\test_cmake_build" type tests\test_cmake_build\*.log*

third_party/CityFlow/extern/pybind11/.clang-format

@@ -1,38 +1,38 @@
----
-# See all possible options and defaults with:
-# clang-format --style=llvm --dump-config
-BasedOnStyle: LLVM
-AccessModifierOffset: -4
-AllowShortLambdasOnASingleLine: true
-AlwaysBreakTemplateDeclarations: Yes
-BinPackArguments: false
-BinPackParameters: false
-BreakBeforeBinaryOperators: All
-BreakConstructorInitializers: BeforeColon
-ColumnLimit: 99
-CommentPragmas: 'NOLINT:.*|^ IWYU pragma:'
-IncludeBlocks: Regroup
-IndentCaseLabels: true
-IndentPPDirectives: AfterHash
-IndentWidth: 4
-Language: Cpp
-SpaceAfterCStyleCast: true
-Standard: Cpp11
-StatementMacros: ['PyObject_HEAD']
-TabWidth: 4
-IncludeCategories:
-  - Regex:           '<pybind11/.*'
-    Priority:        -1
-  - Regex:           'pybind11.h"$'
-    Priority:        1
-  - Regex:           '^".*/?detail/'
-    Priority:        1
-    SortPriority:    2
-  - Regex:           '^"'
-    Priority:        1
-    SortPriority:    3
-  - Regex:           '<[[:alnum:]._]+>'
-    Priority:        4
-  - Regex:           '.*'
-    Priority:        5
-...
+---
+# See all possible options and defaults with:
+# clang-format --style=llvm --dump-config
+BasedOnStyle: LLVM
+AccessModifierOffset: -4
+AllowShortLambdasOnASingleLine: true
+AlwaysBreakTemplateDeclarations: Yes
+BinPackArguments: false
+BinPackParameters: false
+BreakBeforeBinaryOperators: All
+BreakConstructorInitializers: BeforeColon
+ColumnLimit: 99
+CommentPragmas: 'NOLINT:.*|^ IWYU pragma:'
+IncludeBlocks: Regroup
+IndentCaseLabels: true
+IndentPPDirectives: AfterHash
+IndentWidth: 4
+Language: Cpp
+SpaceAfterCStyleCast: true
+Standard: Cpp11
+StatementMacros: ['PyObject_HEAD']
+TabWidth: 4
+IncludeCategories:
+  - Regex:           '<pybind11/.*'
+    Priority:        -1
+  - Regex:           'pybind11.h"$'
+    Priority:        1
+  - Regex:           '^".*/?detail/'
+    Priority:        1
+    SortPriority:    2
+  - Regex:           '^"'
+    Priority:        1
+    SortPriority:    3
+  - Regex:           '<[[:alnum:]._]+>'
+    Priority:        4
+  - Regex:           '.*'
+    Priority:        5
+...

third_party/CityFlow/extern/pybind11/.clang-tidy

@@ -1,77 +1,77 @@
-FormatStyle: file
-
-Checks: |
-  *bugprone*,
-  *performance*,
-  clang-analyzer-optin.cplusplus.VirtualCall,
-  clang-analyzer-optin.performance.Padding,
-  cppcoreguidelines-init-variables,
-  cppcoreguidelines-prefer-member-initializer,
-  cppcoreguidelines-pro-type-static-cast-downcast,
-  cppcoreguidelines-slicing,
-  google-explicit-constructor,
-  llvm-namespace-comment,
-  misc-definitions-in-headers,
-  misc-misplaced-const,
-  misc-non-copyable-objects,
-  misc-static-assert,
-  misc-throw-by-value-catch-by-reference,
-  misc-uniqueptr-reset-release,
-  misc-unused-parameters,
-  modernize-avoid-bind,
-  modernize-loop-convert,
-  modernize-make-shared,
-  modernize-redundant-void-arg,
-  modernize-replace-auto-ptr,
-  modernize-replace-disallow-copy-and-assign-macro,
-  modernize-replace-random-shuffle,
-  modernize-shrink-to-fit,
-  modernize-use-auto,
-  modernize-use-bool-literals,
-  modernize-use-default-member-init,
-  modernize-use-emplace,
-  modernize-use-equals-default,
-  modernize-use-equals-delete,
-  modernize-use-noexcept,
-  modernize-use-nullptr,
-  modernize-use-override,
-  modernize-use-using,
-  readability-avoid-const-params-in-decls,
-  readability-braces-around-statements,
-  readability-const-return-type,
-  readability-container-size-empty,
-  readability-delete-null-pointer,
-  readability-else-after-return,
-  readability-implicit-bool-conversion,
-  readability-inconsistent-declaration-parameter-name,
-  readability-make-member-function-const,
-  readability-misplaced-array-index,
-  readability-non-const-parameter,
-  readability-qualified-auto,
-  readability-redundant-function-ptr-dereference,
-  readability-redundant-smartptr-get,
-  readability-redundant-string-cstr,
-  readability-simplify-subscript-expr,
-  readability-static-accessed-through-instance,
-  readability-static-definition-in-anonymous-namespace,
-  readability-string-compare,
-  readability-suspicious-call-argument,
-  readability-uniqueptr-delete-release,
-  -bugprone-easily-swappable-parameters,
-  -bugprone-exception-escape,
-  -bugprone-reserved-identifier,
-  -bugprone-unused-raii,
-
-CheckOptions:
-- key:             modernize-use-equals-default.IgnoreMacros
-  value:           false
-- key:             performance-for-range-copy.WarnOnAllAutoCopies
-  value:           true
-- key:             performance-inefficient-string-concatenation.StrictMode
-  value:           true
-- key:             performance-unnecessary-value-param.AllowedTypes
-  value:           'exception_ptr$;'
-- key:             readability-implicit-bool-conversion.AllowPointerConditions
-  value:           true
-
-HeaderFilterRegex: 'pybind11/.*h'
+FormatStyle: file
+
+Checks: |
+  *bugprone*,
+  *performance*,
+  clang-analyzer-optin.cplusplus.VirtualCall,
+  clang-analyzer-optin.performance.Padding,
+  cppcoreguidelines-init-variables,
+  cppcoreguidelines-prefer-member-initializer,
+  cppcoreguidelines-pro-type-static-cast-downcast,
+  cppcoreguidelines-slicing,
+  google-explicit-constructor,
+  llvm-namespace-comment,
+  misc-definitions-in-headers,
+  misc-misplaced-const,
+  misc-non-copyable-objects,
+  misc-static-assert,
+  misc-throw-by-value-catch-by-reference,
+  misc-uniqueptr-reset-release,
+  misc-unused-parameters,
+  modernize-avoid-bind,
+  modernize-loop-convert,
+  modernize-make-shared,
+  modernize-redundant-void-arg,
+  modernize-replace-auto-ptr,
+  modernize-replace-disallow-copy-and-assign-macro,
+  modernize-replace-random-shuffle,
+  modernize-shrink-to-fit,
+  modernize-use-auto,
+  modernize-use-bool-literals,
+  modernize-use-default-member-init,
+  modernize-use-emplace,
+  modernize-use-equals-default,
+  modernize-use-equals-delete,
+  modernize-use-noexcept,
+  modernize-use-nullptr,
+  modernize-use-override,
+  modernize-use-using,
+  readability-avoid-const-params-in-decls,
+  readability-braces-around-statements,
+  readability-const-return-type,
+  readability-container-size-empty,
+  readability-delete-null-pointer,
+  readability-else-after-return,
+  readability-implicit-bool-conversion,
+  readability-inconsistent-declaration-parameter-name,
+  readability-make-member-function-const,
+  readability-misplaced-array-index,
+  readability-non-const-parameter,
+  readability-qualified-auto,
+  readability-redundant-function-ptr-dereference,
+  readability-redundant-smartptr-get,
+  readability-redundant-string-cstr,
+  readability-simplify-subscript-expr,
+  readability-static-accessed-through-instance,
+  readability-static-definition-in-anonymous-namespace,
+  readability-string-compare,
+  readability-suspicious-call-argument,
+  readability-uniqueptr-delete-release,
+  -bugprone-easily-swappable-parameters,
+  -bugprone-exception-escape,
+  -bugprone-reserved-identifier,
+  -bugprone-unused-raii,
+
+CheckOptions:
+- key:             modernize-use-equals-default.IgnoreMacros
+  value:           false
+- key:             performance-for-range-copy.WarnOnAllAutoCopies
+  value:           true
+- key:             performance-inefficient-string-concatenation.StrictMode
+  value:           true
+- key:             performance-unnecessary-value-param.AllowedTypes
+  value:           'exception_ptr$;'
+- key:             readability-implicit-bool-conversion.AllowPointerConditions
+  value:           true
+
+HeaderFilterRegex: 'pybind11/.*h'

third_party/CityFlow/extern/pybind11/.cmake-format.yaml

@@ -1,73 +1,73 @@
-parse:
-  additional_commands:
-    pybind11_add_module:
-      flags:
-        - THIN_LTO
-        - MODULE
-        - SHARED
-        - NO_EXTRAS
-        - EXCLUDE_FROM_ALL
-        - SYSTEM
-
-format:
-  line_width: 99
-  tab_size: 2
-
-  # If an argument group contains more than this many sub-groups
-  # (parg or kwarg groups) then force it to a vertical layout.
-  max_subgroups_hwrap: 2
-
-  # If a positional argument group contains more than this many
-  # arguments, then force it to a vertical layout.
-  max_pargs_hwrap: 6
-
-  # If a cmdline positional group consumes more than this many
-  # lines without nesting, then invalidate the layout (and nest)
-  max_rows_cmdline: 2
-  separate_ctrl_name_with_space: false
-  separate_fn_name_with_space: false
-  dangle_parens: false
-
-  # If the trailing parenthesis must be 'dangled' on its on
-  # 'line, then align it to this reference: `prefix`: the start'
-  # 'of the statement,  `prefix-indent`: the start of the'
-  # 'statement, plus one indentation  level, `child`: align to'
-  # the column of the arguments
-  dangle_align: prefix
-  # If the statement spelling length (including space and
-  # parenthesis) is smaller than this amount, then force reject
-  # nested layouts.
-  min_prefix_chars: 4
-
-  # If the statement spelling length (including space and
-  # parenthesis) is larger than the tab width by more than this
-  # amount, then force reject un-nested layouts.
-  max_prefix_chars: 10
-
-  # If a candidate layout is wrapped horizontally but it exceeds
-  # this many lines, then reject the layout.
-  max_lines_hwrap: 2
-
-  line_ending: unix
-
-  # Format command names consistently as 'lower' or 'upper' case
-  command_case: canonical
-
-  # Format keywords consistently as 'lower' or 'upper' case
-  # unchanged is valid too
-  keyword_case: 'upper'
-
-  # A list of command names which should always be wrapped
-  always_wrap: []
-
-  # If true, the argument lists which are known to be sortable
-  # will be sorted lexicographically
-  enable_sort: true
-
-  # If true, the parsers may infer whether or not an argument
-  # list is sortable (without annotation).
-  autosort: false
-
-# Causes a few issues - can be solved later, possibly.
-markup:
-  enable_markup: false
+parse:
+  additional_commands:
+    pybind11_add_module:
+      flags:
+        - THIN_LTO
+        - MODULE
+        - SHARED
+        - NO_EXTRAS
+        - EXCLUDE_FROM_ALL
+        - SYSTEM
+
+format:
+  line_width: 99
+  tab_size: 2
+
+  # If an argument group contains more than this many sub-groups
+  # (parg or kwarg groups) then force it to a vertical layout.
+  max_subgroups_hwrap: 2
+
+  # If a positional argument group contains more than this many
+  # arguments, then force it to a vertical layout.
+  max_pargs_hwrap: 6
+
+  # If a cmdline positional group consumes more than this many
+  # lines without nesting, then invalidate the layout (and nest)
+  max_rows_cmdline: 2
+  separate_ctrl_name_with_space: false
+  separate_fn_name_with_space: false
+  dangle_parens: false
+
+  # If the trailing parenthesis must be 'dangled' on its on
+  # 'line, then align it to this reference: `prefix`: the start'
+  # 'of the statement,  `prefix-indent`: the start of the'
+  # 'statement, plus one indentation  level, `child`: align to'
+  # the column of the arguments
+  dangle_align: prefix
+  # If the statement spelling length (including space and
+  # parenthesis) is smaller than this amount, then force reject
+  # nested layouts.
+  min_prefix_chars: 4
+
+  # If the statement spelling length (including space and
+  # parenthesis) is larger than the tab width by more than this
+  # amount, then force reject un-nested layouts.
+  max_prefix_chars: 10
+
+  # If a candidate layout is wrapped horizontally but it exceeds
+  # this many lines, then reject the layout.
+  max_lines_hwrap: 2
+
+  line_ending: unix
+
+  # Format command names consistently as 'lower' or 'upper' case
+  command_case: canonical
+
+  # Format keywords consistently as 'lower' or 'upper' case
+  # unchanged is valid too
+  keyword_case: 'upper'
+
+  # A list of command names which should always be wrapped
+  always_wrap: []
+
+  # If true, the argument lists which are known to be sortable
+  # will be sorted lexicographically
+  enable_sort: true
+
+  # If true, the parsers may infer whether or not an argument
+  # list is sortable (without annotation).
+  autosort: false
+
+# Causes a few issues - can be solved later, possibly.
+markup:
+  enable_markup: false

third_party/CityFlow/extern/pybind11/.codespell-ignore-lines

@@ -1,24 +1,24 @@
-template <op_id id, op_type ot, typename L = undefined_t, typename R = undefined_t>
-    template <typename ThisT>
-        auto &this_ = static_cast<ThisT &>(*this);
-                if (load_impl<ThisT>(temp, false)) {
-        ssize_t nd = 0;
-        auto trivial = broadcast(buffers, nd, shape);
-        auto ndim = (size_t) nd;
-    int nd;
-    ssize_t ndim() const { return detail::array_proxy(m_ptr)->nd; }
-        using op = op_impl<id, ot, Base, L_type, R_type>;
-template <op_id id, op_type ot, typename L, typename R>
-    template <detail::op_id id, detail::op_type ot, typename L, typename R, typename... Extra>
-    class_ &def(const detail::op_<id, ot, L, R> &op, const Extra &...extra) {
-    class_ &def_cast(const detail::op_<id, ot, L, R> &op, const Extra &...extra) {
-@pytest.mark.parametrize("access", ["ro", "rw", "static_ro", "static_rw"])
-struct IntStruct {
-    explicit IntStruct(int v) : value(v){};
-    ~IntStruct() { value = -value; }
-    IntStruct(const IntStruct &) = default;
-    IntStruct &operator=(const IntStruct &) = default;
-    py::class_<IntStruct>(m, "IntStruct").def(py::init([](const int i) { return IntStruct(i); }));
-    py::implicitly_convertible<int, IntStruct>();
-    m.def("test", [](int expected, const IntStruct &in) {
-        [](int expected, const IntStruct &in) {
+template <op_id id, op_type ot, typename L = undefined_t, typename R = undefined_t>
+    template <typename ThisT>
+        auto &this_ = static_cast<ThisT &>(*this);
+                if (load_impl<ThisT>(temp, false)) {
+        ssize_t nd = 0;
+        auto trivial = broadcast(buffers, nd, shape);
+        auto ndim = (size_t) nd;
+    int nd;
+    ssize_t ndim() const { return detail::array_proxy(m_ptr)->nd; }
+        using op = op_impl<id, ot, Base, L_type, R_type>;
+template <op_id id, op_type ot, typename L, typename R>
+    template <detail::op_id id, detail::op_type ot, typename L, typename R, typename... Extra>
+    class_ &def(const detail::op_<id, ot, L, R> &op, const Extra &...extra) {
+    class_ &def_cast(const detail::op_<id, ot, L, R> &op, const Extra &...extra) {
+@pytest.mark.parametrize("access", ["ro", "rw", "static_ro", "static_rw"])
+struct IntStruct {
+    explicit IntStruct(int v) : value(v){};
+    ~IntStruct() { value = -value; }
+    IntStruct(const IntStruct &) = default;
+    IntStruct &operator=(const IntStruct &) = default;
+    py::class_<IntStruct>(m, "IntStruct").def(py::init([](const int i) { return IntStruct(i); }));
+    py::implicitly_convertible<int, IntStruct>();
+    m.def("test", [](int expected, const IntStruct &in) {
+        [](int expected, const IntStruct &in) {

third_party/CityFlow/extern/pybind11/.git.bak/FETCH_HEAD

@@ -1,32 +1,32 @@
-68a11bb65b774df161c898204d08e85ac2cbac5f	not-for-merge	branch 'archive/smart_holder' of https://github.com/pybind/pybind11
-619fb2305697c1eb4a6e248af03eab2c8c57237d	not-for-merge	branch 'array-sequence-fix' of https://github.com/pybind/pybind11
-1423623205a5d656ec2f068b948dcf5f02146f2f	not-for-merge	branch 'cpp17-aligned-new' of https://github.com/pybind/pybind11
-fd3a93c520a661b78e177280128a9c855d7f5be5	not-for-merge	branch 'fold-expression-caster' of https://github.com/pybind/pybind11
-9fa6acdf5bf53b6f26d6bf2f1bdab65da782ec08	not-for-merge	branch 'henryiii-patch-1' of https://github.com/pybind/pybind11
-d8c30a8f2df87007ca2a5679119af50aff5c0695	not-for-merge	branch 'henryiii-patch-2' of https://github.com/pybind/pybind11
-d7cc5b052d737de8478b536fee4a2075cedec866	not-for-merge	branch 'henryiii-patch-3' of https://github.com/pybind/pybind11
-19ddbe5bc3eb3064201a914626ac642e1884e654	not-for-merge	branch 'henryiii/revert/pycapsule' of https://github.com/pybind/pybind11
-78e074b8bbda1073e60273620e084aac28b0740c	not-for-merge	branch 'internals_ptr' of https://github.com/pybind/pybind11
-8986743b6daebfcb07428e921192ff77308db055	not-for-merge	branch 'issue1561_fix' of https://github.com/pybind/pybind11
-cd538ed1184d41cf685dd4da81c1eca80d24f353	not-for-merge	branch 'master' of https://github.com/pybind/pybind11
-45c45eefe9bb7ba37a7e71dcabff5e7b5ff4596c	not-for-merge	branch 'pre-commit-ci-update-config' of https://github.com/pybind/pybind11
-dba00d7369677617d00974f5a00ebcd5e6288cdc	not-for-merge	branch 'revert-4220-fix-nvcc-11.4-11.8' of https://github.com/pybind/pybind11
-04cfb45b7998fe960a70743770b94bdb3a712f73	not-for-merge	branch 'stable' of https://github.com/pybind/pybind11
-e076c4513dc2c89c1e9b7cb716fb8e4588e8e067	not-for-merge	branch 'undefined-macos' of https://github.com/pybind/pybind11
-121360c6ae0fff0c97c64470508c11a0cc27bf94	not-for-merge	branch 'v1.8' of https://github.com/pybind/pybind11
-07de0d8627101be53986e841cd4e21ee38c2498a	not-for-merge	branch 'v2.0' of https://github.com/pybind/pybind11
-1df91d36cfa997c8987889234304ea5e37cc3e68	not-for-merge	branch 'v2.1' of https://github.com/pybind/pybind11
-5b0a6fc2017fcc176545afe3e09c9f9885283242	not-for-merge	branch 'v2.10' of https://github.com/pybind/pybind11
-95d943ae0ebdf609bbd650d119fda539509929b6	not-for-merge	branch 'v2.11' of https://github.com/pybind/pybind11
-2e0815278cb899b20870a67ca8205996ef47e70f	not-for-merge	branch 'v2.12' of https://github.com/pybind/pybind11
-a2e59f0e7065404b44dfe92a28aca47ba1378dc4	not-for-merge	branch 'v2.13' of https://github.com/pybind/pybind11
-a23996fce38ff6ccfbcdc09f1e63f2c4be5ea2ef	not-for-merge	branch 'v2.2' of https://github.com/pybind/pybind11
-a1b71df137e015d44f7e31f7b6d4807253fb7871	not-for-merge	branch 'v2.3' of https://github.com/pybind/pybind11
-80d452484c5409444b0ec19383faa84bb7a4d351	not-for-merge	branch 'v2.4' of https://github.com/pybind/pybind11
-3b1dbebabc801c9cf6f0953a4c20b904d444f879	not-for-merge	branch 'v2.5' of https://github.com/pybind/pybind11
-8de7772cc72daca8e947b79b83fea46214931604	not-for-merge	branch 'v2.6' of https://github.com/pybind/pybind11
-5b4432439ed72417253f9eec99f2a014636c0362	not-for-merge	branch 'v2.7' of https://github.com/pybind/pybind11
-f7b499615e14d70ab098a20deb0cdb3889998a1a	not-for-merge	branch 'v2.8' of https://github.com/pybind/pybind11
-914c06fb252b6cc3727d0eedab6736e88a3fcb01	not-for-merge	branch 'v2.9' of https://github.com/pybind/pybind11
-45fab4087eaaff234227a10cf7845e8b07f28a98	not-for-merge	branch 'v3.0' of https://github.com/pybind/pybind11
-0991e90375606254087f7bffe0dd15dd910ec62b	not-for-merge	branch 'void-caster-fix' of https://github.com/pybind/pybind11
+68a11bb65b774df161c898204d08e85ac2cbac5f	not-for-merge	branch 'archive/smart_holder' of https://github.com/pybind/pybind11
+619fb2305697c1eb4a6e248af03eab2c8c57237d	not-for-merge	branch 'array-sequence-fix' of https://github.com/pybind/pybind11
+1423623205a5d656ec2f068b948dcf5f02146f2f	not-for-merge	branch 'cpp17-aligned-new' of https://github.com/pybind/pybind11
+fd3a93c520a661b78e177280128a9c855d7f5be5	not-for-merge	branch 'fold-expression-caster' of https://github.com/pybind/pybind11
+9fa6acdf5bf53b6f26d6bf2f1bdab65da782ec08	not-for-merge	branch 'henryiii-patch-1' of https://github.com/pybind/pybind11
+d8c30a8f2df87007ca2a5679119af50aff5c0695	not-for-merge	branch 'henryiii-patch-2' of https://github.com/pybind/pybind11
+d7cc5b052d737de8478b536fee4a2075cedec866	not-for-merge	branch 'henryiii-patch-3' of https://github.com/pybind/pybind11
+19ddbe5bc3eb3064201a914626ac642e1884e654	not-for-merge	branch 'henryiii/revert/pycapsule' of https://github.com/pybind/pybind11
+78e074b8bbda1073e60273620e084aac28b0740c	not-for-merge	branch 'internals_ptr' of https://github.com/pybind/pybind11
+8986743b6daebfcb07428e921192ff77308db055	not-for-merge	branch 'issue1561_fix' of https://github.com/pybind/pybind11
+cd538ed1184d41cf685dd4da81c1eca80d24f353	not-for-merge	branch 'master' of https://github.com/pybind/pybind11
+45c45eefe9bb7ba37a7e71dcabff5e7b5ff4596c	not-for-merge	branch 'pre-commit-ci-update-config' of https://github.com/pybind/pybind11
+dba00d7369677617d00974f5a00ebcd5e6288cdc	not-for-merge	branch 'revert-4220-fix-nvcc-11.4-11.8' of https://github.com/pybind/pybind11
+04cfb45b7998fe960a70743770b94bdb3a712f73	not-for-merge	branch 'stable' of https://github.com/pybind/pybind11
+e076c4513dc2c89c1e9b7cb716fb8e4588e8e067	not-for-merge	branch 'undefined-macos' of https://github.com/pybind/pybind11
+121360c6ae0fff0c97c64470508c11a0cc27bf94	not-for-merge	branch 'v1.8' of https://github.com/pybind/pybind11
+07de0d8627101be53986e841cd4e21ee38c2498a	not-for-merge	branch 'v2.0' of https://github.com/pybind/pybind11
+1df91d36cfa997c8987889234304ea5e37cc3e68	not-for-merge	branch 'v2.1' of https://github.com/pybind/pybind11
+5b0a6fc2017fcc176545afe3e09c9f9885283242	not-for-merge	branch 'v2.10' of https://github.com/pybind/pybind11
+95d943ae0ebdf609bbd650d119fda539509929b6	not-for-merge	branch 'v2.11' of https://github.com/pybind/pybind11
+2e0815278cb899b20870a67ca8205996ef47e70f	not-for-merge	branch 'v2.12' of https://github.com/pybind/pybind11
+a2e59f0e7065404b44dfe92a28aca47ba1378dc4	not-for-merge	branch 'v2.13' of https://github.com/pybind/pybind11
+a23996fce38ff6ccfbcdc09f1e63f2c4be5ea2ef	not-for-merge	branch 'v2.2' of https://github.com/pybind/pybind11
+a1b71df137e015d44f7e31f7b6d4807253fb7871	not-for-merge	branch 'v2.3' of https://github.com/pybind/pybind11
+80d452484c5409444b0ec19383faa84bb7a4d351	not-for-merge	branch 'v2.4' of https://github.com/pybind/pybind11
+3b1dbebabc801c9cf6f0953a4c20b904d444f879	not-for-merge	branch 'v2.5' of https://github.com/pybind/pybind11
+8de7772cc72daca8e947b79b83fea46214931604	not-for-merge	branch 'v2.6' of https://github.com/pybind/pybind11
+5b4432439ed72417253f9eec99f2a014636c0362	not-for-merge	branch 'v2.7' of https://github.com/pybind/pybind11
+f7b499615e14d70ab098a20deb0cdb3889998a1a	not-for-merge	branch 'v2.8' of https://github.com/pybind/pybind11
+914c06fb252b6cc3727d0eedab6736e88a3fcb01	not-for-merge	branch 'v2.9' of https://github.com/pybind/pybind11
+45fab4087eaaff234227a10cf7845e8b07f28a98	not-for-merge	branch 'v3.0' of https://github.com/pybind/pybind11
+0991e90375606254087f7bffe0dd15dd910ec62b	not-for-merge	branch 'void-caster-fix' of https://github.com/pybind/pybind11

third_party/CityFlow/extern/pybind11/.git.bak/HEAD

@@ -1 +1 @@
-3e9dfa2866941655c56877882565e7577de6fc7b
+3e9dfa2866941655c56877882565e7577de6fc7b

third_party/CityFlow/extern/pybind11/.git.bak/config

@@ -1,13 +1,13 @@
-[core]
-	repositoryformatversion = 0
-	filemode = true
-	bare = false
-	logallrefupdates = true
-	ignorecase = true
-	precomposeunicode = true
-[remote "origin"]
-	url = https://github.com/pybind/pybind11.git
-	fetch = +refs/heads/*:refs/remotes/origin/*
-[branch "master"]
-	remote = origin
-	merge = refs/heads/master
+[core]
+	repositoryformatversion = 0
+	filemode = true
+	bare = false
+	logallrefupdates = true
+	ignorecase = true
+	precomposeunicode = true
+[remote "origin"]
+	url = https://github.com/pybind/pybind11.git
+	fetch = +refs/heads/*:refs/remotes/origin/*
+[branch "master"]
+	remote = origin
+	merge = refs/heads/master

third_party/CityFlow/extern/pybind11/.git.bak/description

@@ -1 +1 @@
-Unnamed repository; edit this file 'description' to name the repository.
+Unnamed repository; edit this file 'description' to name the repository.

third_party/CityFlow/extern/pybind11/.git.bak/packed-refs

@@ -1,143 +1,143 @@
-# pack-refs with: peeled fully-peeled sorted 
-68a11bb65b774df161c898204d08e85ac2cbac5f refs/remotes/origin/archive/smart_holder
-619fb2305697c1eb4a6e248af03eab2c8c57237d refs/remotes/origin/array-sequence-fix
-1423623205a5d656ec2f068b948dcf5f02146f2f refs/remotes/origin/cpp17-aligned-new
-fd3a93c520a661b78e177280128a9c855d7f5be5 refs/remotes/origin/fold-expression-caster
-9fa6acdf5bf53b6f26d6bf2f1bdab65da782ec08 refs/remotes/origin/henryiii-patch-1
-d8c30a8f2df87007ca2a5679119af50aff5c0695 refs/remotes/origin/henryiii-patch-2
-d7cc5b052d737de8478b536fee4a2075cedec866 refs/remotes/origin/henryiii-patch-3
-19ddbe5bc3eb3064201a914626ac642e1884e654 refs/remotes/origin/henryiii/revert/pycapsule
-78e074b8bbda1073e60273620e084aac28b0740c refs/remotes/origin/internals_ptr
-8986743b6daebfcb07428e921192ff77308db055 refs/remotes/origin/issue1561_fix
-cd538ed1184d41cf685dd4da81c1eca80d24f353 refs/remotes/origin/master
-45c45eefe9bb7ba37a7e71dcabff5e7b5ff4596c refs/remotes/origin/pre-commit-ci-update-config
-dba00d7369677617d00974f5a00ebcd5e6288cdc refs/remotes/origin/revert-4220-fix-nvcc-11.4-11.8
-04cfb45b7998fe960a70743770b94bdb3a712f73 refs/remotes/origin/stable
-e076c4513dc2c89c1e9b7cb716fb8e4588e8e067 refs/remotes/origin/undefined-macos
-121360c6ae0fff0c97c64470508c11a0cc27bf94 refs/remotes/origin/v1.8
-07de0d8627101be53986e841cd4e21ee38c2498a refs/remotes/origin/v2.0
-1df91d36cfa997c8987889234304ea5e37cc3e68 refs/remotes/origin/v2.1
-5b0a6fc2017fcc176545afe3e09c9f9885283242 refs/remotes/origin/v2.10
-95d943ae0ebdf609bbd650d119fda539509929b6 refs/remotes/origin/v2.11
-2e0815278cb899b20870a67ca8205996ef47e70f refs/remotes/origin/v2.12
-a2e59f0e7065404b44dfe92a28aca47ba1378dc4 refs/remotes/origin/v2.13
-a23996fce38ff6ccfbcdc09f1e63f2c4be5ea2ef refs/remotes/origin/v2.2
-a1b71df137e015d44f7e31f7b6d4807253fb7871 refs/remotes/origin/v2.3
-80d452484c5409444b0ec19383faa84bb7a4d351 refs/remotes/origin/v2.4
-3b1dbebabc801c9cf6f0953a4c20b904d444f879 refs/remotes/origin/v2.5
-8de7772cc72daca8e947b79b83fea46214931604 refs/remotes/origin/v2.6
-5b4432439ed72417253f9eec99f2a014636c0362 refs/remotes/origin/v2.7
-f7b499615e14d70ab098a20deb0cdb3889998a1a refs/remotes/origin/v2.8
-914c06fb252b6cc3727d0eedab6736e88a3fcb01 refs/remotes/origin/v2.9
-45fab4087eaaff234227a10cf7845e8b07f28a98 refs/remotes/origin/v3.0
-0991e90375606254087f7bffe0dd15dd910ec62b refs/remotes/origin/void-caster-fix
-8ae716ab79e0141537eff420cb7e79b06d14c402 refs/tags/v1.0
-^929fd7e6946255ed84c803d2993f48912de96e15
-1a25b3f8f7455246adf2930e4c857c128c71a240 refs/tags/v1.1
-^bda3b67dc5f9481857aa7a14478bab3293bb376f
-ef4345f46c672a74e161f5a8955784658fb10ae8 refs/tags/v1.2
-^8ed2808239f3a6052e7789feeeab34eed39b5c62
-1c32fcbfba8849abedf2a50e675e5f847c20a42d refs/tags/v1.3
-^d2385e8fc6a3008cab96532c99db4c3d57541fc5
-0b8a0c621a2872312b477bed4f8b72a1a3a34d61 refs/tags/v1.4
-^0e6ca5916e2585ca9b778f8304c166b6a36b7e5a
-dce23aeae9dcae322670073e6b5a7a22fb740c14 refs/tags/v1.5
-^bb79d7bdc0f48f1a9284af85bf36d392afc28307
-549781cb1c71a91b8bab23e452c5bfed413dee40 refs/tags/v1.6
-^e85e9d82824e88352c9389694ff2130e4a6c5d02
-f21d226f83c5c3db2f3f5c554c35fb8942fd6dcb refs/tags/v1.7
-^e70b2abb6dee27a2889b01f245a2a28e6fcd4b01
-8e8bd7090ba1197117560c7e7f46cd2e9d026424 refs/tags/v1.8
-^c0759976177b92f386856a5d9f2e8d63ef89293a
-4da184714d7a3ee298edcabb51497c629108205b refs/tags/v1.8.1
-^121360c6ae0fff0c97c64470508c11a0cc27bf94
-40585804f4e9dbf45b277dd55c19a8026b356eef refs/tags/v2.0.0
-^e33ef9c20d36fe760792c61ccc95ecf1b42cf81d
-12006926087bdd34dcbd4db40611be7d5b6ed830 refs/tags/v2.0.0-rc1
-^3c7967111280b0a796986ac2025d0ca201623656
-f74dd5d5a4033e68d9000d3c288d0b57a3fc0105 refs/tags/v2.0.1
-^07de0d8627101be53986e841cd4e21ee38c2498a
-a2207c044fdffac6023975df015e73f161082b57 refs/tags/v2.1.0
-^ad9d574c85f1836c57f2f0727ffe997bb8cbfdd7
-cbf3c94e781074f2f094e9a39d7ea86304d69a1d refs/tags/v2.1.1
-^1df91d36cfa997c8987889234304ea5e37cc3e68
-8d298f32f3bf5c1854adeadf7f1ec1c236dd5221 refs/tags/v2.10.0
-^aa304c9c7d725ffb9d10af08a3b34cb372307020
-bcee506ac0b09ea13000484c08ab3e5a41ee0fb2 refs/tags/v2.10.1
-^80dc998efced8ceb2be59756668a7e90e8bef917
-76b3533f96774e555a6e10d6deb9bbafe4970011 refs/tags/v2.10.2
-^0694ec6a15863bff2e0ea5efe07c78de39b9a33c
-70a09bf92bff267b3eceee51bee00741bc91367f refs/tags/v2.10.3
-^0bd8896a4010f2d91b2340570c24fa08606ec406
-95ddd6b61bbecd06d00eef8a0e72fa9ffd46631e refs/tags/v2.10.4
-^5b0a6fc2017fcc176545afe3e09c9f9885283242
-8d8aecf4a5579c0e51d07fb93411aa120ae0360c refs/tags/v2.11.0
-^1a917f1852eb7819b671fc3fa862840f4c491a07
-0630807c3070287c716f6be3eacb00b8816b4215 refs/tags/v2.11.1
-^8a099e44b3d5f85b20f05828d919d2332a8de841
-95d943ae0ebdf609bbd650d119fda539509929b6 refs/tags/v2.11.2
-3e9dfa2866941655c56877882565e7577de6fc7b refs/tags/v2.12.0
-2e0815278cb899b20870a67ca8205996ef47e70f refs/tags/v2.12.1
-0c69e1eb2177fa8f8580632c7b1f97fdb606ce8f refs/tags/v2.13.0
-941f45bcb51457884fa1afd6e24a67377d70f75c refs/tags/v2.13.1
-07f30430d4186c2712761f1ffaea50ede63f2b2b refs/tags/v2.13.2
-bd67643652d3800837f1f41549a2a5adbaa3fafe refs/tags/v2.13.3
-c6239a8a1b6871cc0fb5f7af885a02ffd1349f9d refs/tags/v2.13.4
-7c33cdc2d39c7b99a122579f53bc94c8eb3332ff refs/tags/v2.13.5
-a2e59f0e7065404b44dfe92a28aca47ba1378dc4 refs/tags/v2.13.6
-c36cf6254170aa8aef35b65854f518016551d5b8 refs/tags/v2.2.0
-^2a5a5ec0a47c245fbf1bb1a8a90b4c3278e01693
-9a9239eaa52e0e2a16c76894a7f30f19997f0167 refs/tags/v2.2.1
-^86e2ad4f77442c3350f9a2476650da6bee253c52
-8bd683141ccf900aafc3dc76e5efd86f1e8ac541 refs/tags/v2.2.2
-^f117a48ea2fd446d2865826a58d08027d4579cb3
-197ae8a04cec7bf9327d36c780d4fca2a6b51339 refs/tags/v2.2.3
-^8edc147d67ca85a93ed1f53628004528dc36a04d
-e4637eb508aa3e41233875f6ce3891d96fbc5d33 refs/tags/v2.2.4
-^9a19306fbf30642ca331d0ec88e7da54a96860f9
-7107ada7cbbd01e76a2a9f3e2ec27b683dcec99b refs/tags/v2.3.0
-^e43e1cc01ae6d4e4e5ba10557a057d7f3d5ece0d
-ca8264815ffcf8beda3b206405a92927c722027f refs/tags/v2.4.0
-^00a0aa992953d6482114a0f539a21bb535a16383
-8b7a01d0b8dddf9ff650a6511377cd32a4f1501a refs/tags/v2.4.1
-^e44fcc3c15b41f0720c72832c0b9cd07de819781
-6c383e01bbd4155a29ad280ad7ba7941e05675dd refs/tags/v2.4.2
-^7ec2ddfc95f65d1e986d359466a6c254aa514ef3
-aa56a0e4a40af9ff27dd5b4d283d29bc64c19088 refs/tags/v2.4.3
-^80d452484c5409444b0ec19383faa84bb7a4d351
-014cd12ec1a3258f3bfc6597f371ed46c8e89ccd refs/tags/v2.5.0
-^3b1dbebabc801c9cf6f0953a4c20b904d444f879
-78b2d1991b9e81bbc1a6670ab4af189094e952eb refs/tags/v2.6.0
-^59a2ac2745d8a57ac94c6accced73620d59fb844
-319b99648b94c37e16cec64e0aec6d80557de64f refs/tags/v2.6.0b1
-d46f3322a45cb907777f568bb1377ab1b9457ad8 refs/tags/v2.6.0rc1
-c4a8b5bb9140cdc8c214044d41e2593986f875d0 refs/tags/v2.6.0rc2
-c16da993094988141101ac4d96a9b2c92f9ac714 refs/tags/v2.6.0rc3
-f4bc37b3de4857b9d80c1d85ff9f9e5dceef3dd4 refs/tags/v2.6.1
-^f1abf5d9159b805674197f6bc443592e631c9130
-c7faa0f557df4ee266e6e6dca311cd1474ad2123 refs/tags/v2.6.2
-^8de7772cc72daca8e947b79b83fea46214931604
-40d14c37b4cb8488a241f837ea2e3eb60404f7b7 refs/tags/v2.7.0
-^65e95ea8675ea34bdd566d6461330f25c651e5a8
-c0e8a831c6023be719144e7d10c8ea7c9fb81a58 refs/tags/v2.7.1
-^787d2c88cafa4d07fb38c9519c485a86323cfcf4
-dc756043d5ed7654e48c41d97a64403a847214a7 refs/tags/v2.8.0
-^97976c16fb7652f7faf02d76756666ef87adbe7d
-79dfe03e432e2af41bba00add596e6df92099b49 refs/tags/v2.8.1
-^f7b499615e14d70ab098a20deb0cdb3889998a1a
-1dad2a58efb1eef1eb9f2e5532dedd3711924810 refs/tags/v2.9.0
-^45f792efdd92da094548e2095d6efdbfa7e536ee
-35b51445ba2bf5e67137c04bc26ceaab33e4285f refs/tags/v2.9.1
-^ffa346860b306c9bbfb341aed9c14c067751feb8
-dd9ef9f901f3d49426f87a67666393970a6c9431 refs/tags/v2.9.2
-^914c06fb252b6cc3727d0eedab6736e88a3fcb01
-f0ecf21301c0c24bc78b8b310347c7507d9f41d0 refs/tags/v3.0.0
-^ed5057ded698e305210269dafa57574ecf964483
-fc888f758fde1c37d80f85666060d3f179f6c001 refs/tags/v3.0.0rc1
-df595b16579d847cd019072aa0daec1e566c7ba2 refs/tags/v3.0.0rc2
-5d32ed76c0ea53d689f9cec3d4c152d1b0738e8e refs/tags/v3.0.0rc3
-ea3e33e40dd1cbfa9f885e991386337a0e5b4b66 refs/tags/v3.0.0rc4
-e86205cb2ba070755d582856430c0f83c0af6694 refs/tags/v3.0.1
-^f5fbe867d2d26e4a0a9177a51f6e568868ad3dc8
-e6c503bb0b0c13f76ca0546eca7f8d986039517f refs/tags/v3.0.2
-^45fab4087eaaff234227a10cf7845e8b07f28a98
+# pack-refs with: peeled fully-peeled sorted 
+68a11bb65b774df161c898204d08e85ac2cbac5f refs/remotes/origin/archive/smart_holder
+619fb2305697c1eb4a6e248af03eab2c8c57237d refs/remotes/origin/array-sequence-fix
+1423623205a5d656ec2f068b948dcf5f02146f2f refs/remotes/origin/cpp17-aligned-new
+fd3a93c520a661b78e177280128a9c855d7f5be5 refs/remotes/origin/fold-expression-caster
+9fa6acdf5bf53b6f26d6bf2f1bdab65da782ec08 refs/remotes/origin/henryiii-patch-1
+d8c30a8f2df87007ca2a5679119af50aff5c0695 refs/remotes/origin/henryiii-patch-2
+d7cc5b052d737de8478b536fee4a2075cedec866 refs/remotes/origin/henryiii-patch-3
+19ddbe5bc3eb3064201a914626ac642e1884e654 refs/remotes/origin/henryiii/revert/pycapsule
+78e074b8bbda1073e60273620e084aac28b0740c refs/remotes/origin/internals_ptr
+8986743b6daebfcb07428e921192ff77308db055 refs/remotes/origin/issue1561_fix
+cd538ed1184d41cf685dd4da81c1eca80d24f353 refs/remotes/origin/master
+45c45eefe9bb7ba37a7e71dcabff5e7b5ff4596c refs/remotes/origin/pre-commit-ci-update-config
+dba00d7369677617d00974f5a00ebcd5e6288cdc refs/remotes/origin/revert-4220-fix-nvcc-11.4-11.8
+04cfb45b7998fe960a70743770b94bdb3a712f73 refs/remotes/origin/stable
+e076c4513dc2c89c1e9b7cb716fb8e4588e8e067 refs/remotes/origin/undefined-macos
+121360c6ae0fff0c97c64470508c11a0cc27bf94 refs/remotes/origin/v1.8
+07de0d8627101be53986e841cd4e21ee38c2498a refs/remotes/origin/v2.0
+1df91d36cfa997c8987889234304ea5e37cc3e68 refs/remotes/origin/v2.1
+5b0a6fc2017fcc176545afe3e09c9f9885283242 refs/remotes/origin/v2.10
+95d943ae0ebdf609bbd650d119fda539509929b6 refs/remotes/origin/v2.11
+2e0815278cb899b20870a67ca8205996ef47e70f refs/remotes/origin/v2.12
+a2e59f0e7065404b44dfe92a28aca47ba1378dc4 refs/remotes/origin/v2.13
+a23996fce38ff6ccfbcdc09f1e63f2c4be5ea2ef refs/remotes/origin/v2.2
+a1b71df137e015d44f7e31f7b6d4807253fb7871 refs/remotes/origin/v2.3
+80d452484c5409444b0ec19383faa84bb7a4d351 refs/remotes/origin/v2.4
+3b1dbebabc801c9cf6f0953a4c20b904d444f879 refs/remotes/origin/v2.5
+8de7772cc72daca8e947b79b83fea46214931604 refs/remotes/origin/v2.6
+5b4432439ed72417253f9eec99f2a014636c0362 refs/remotes/origin/v2.7
+f7b499615e14d70ab098a20deb0cdb3889998a1a refs/remotes/origin/v2.8
+914c06fb252b6cc3727d0eedab6736e88a3fcb01 refs/remotes/origin/v2.9
+45fab4087eaaff234227a10cf7845e8b07f28a98 refs/remotes/origin/v3.0
+0991e90375606254087f7bffe0dd15dd910ec62b refs/remotes/origin/void-caster-fix
+8ae716ab79e0141537eff420cb7e79b06d14c402 refs/tags/v1.0
+^929fd7e6946255ed84c803d2993f48912de96e15
+1a25b3f8f7455246adf2930e4c857c128c71a240 refs/tags/v1.1
+^bda3b67dc5f9481857aa7a14478bab3293bb376f
+ef4345f46c672a74e161f5a8955784658fb10ae8 refs/tags/v1.2
+^8ed2808239f3a6052e7789feeeab34eed39b5c62
+1c32fcbfba8849abedf2a50e675e5f847c20a42d refs/tags/v1.3
+^d2385e8fc6a3008cab96532c99db4c3d57541fc5
+0b8a0c621a2872312b477bed4f8b72a1a3a34d61 refs/tags/v1.4
+^0e6ca5916e2585ca9b778f8304c166b6a36b7e5a
+dce23aeae9dcae322670073e6b5a7a22fb740c14 refs/tags/v1.5
+^bb79d7bdc0f48f1a9284af85bf36d392afc28307
+549781cb1c71a91b8bab23e452c5bfed413dee40 refs/tags/v1.6
+^e85e9d82824e88352c9389694ff2130e4a6c5d02
+f21d226f83c5c3db2f3f5c554c35fb8942fd6dcb refs/tags/v1.7
+^e70b2abb6dee27a2889b01f245a2a28e6fcd4b01
+8e8bd7090ba1197117560c7e7f46cd2e9d026424 refs/tags/v1.8
+^c0759976177b92f386856a5d9f2e8d63ef89293a
+4da184714d7a3ee298edcabb51497c629108205b refs/tags/v1.8.1
+^121360c6ae0fff0c97c64470508c11a0cc27bf94
+40585804f4e9dbf45b277dd55c19a8026b356eef refs/tags/v2.0.0
+^e33ef9c20d36fe760792c61ccc95ecf1b42cf81d
+12006926087bdd34dcbd4db40611be7d5b6ed830 refs/tags/v2.0.0-rc1
+^3c7967111280b0a796986ac2025d0ca201623656
+f74dd5d5a4033e68d9000d3c288d0b57a3fc0105 refs/tags/v2.0.1
+^07de0d8627101be53986e841cd4e21ee38c2498a
+a2207c044fdffac6023975df015e73f161082b57 refs/tags/v2.1.0
+^ad9d574c85f1836c57f2f0727ffe997bb8cbfdd7
+cbf3c94e781074f2f094e9a39d7ea86304d69a1d refs/tags/v2.1.1
+^1df91d36cfa997c8987889234304ea5e37cc3e68
+8d298f32f3bf5c1854adeadf7f1ec1c236dd5221 refs/tags/v2.10.0
+^aa304c9c7d725ffb9d10af08a3b34cb372307020
+bcee506ac0b09ea13000484c08ab3e5a41ee0fb2 refs/tags/v2.10.1
+^80dc998efced8ceb2be59756668a7e90e8bef917
+76b3533f96774e555a6e10d6deb9bbafe4970011 refs/tags/v2.10.2
+^0694ec6a15863bff2e0ea5efe07c78de39b9a33c
+70a09bf92bff267b3eceee51bee00741bc91367f refs/tags/v2.10.3
+^0bd8896a4010f2d91b2340570c24fa08606ec406
+95ddd6b61bbecd06d00eef8a0e72fa9ffd46631e refs/tags/v2.10.4
+^5b0a6fc2017fcc176545afe3e09c9f9885283242
+8d8aecf4a5579c0e51d07fb93411aa120ae0360c refs/tags/v2.11.0
+^1a917f1852eb7819b671fc3fa862840f4c491a07
+0630807c3070287c716f6be3eacb00b8816b4215 refs/tags/v2.11.1
+^8a099e44b3d5f85b20f05828d919d2332a8de841
+95d943ae0ebdf609bbd650d119fda539509929b6 refs/tags/v2.11.2
+3e9dfa2866941655c56877882565e7577de6fc7b refs/tags/v2.12.0
+2e0815278cb899b20870a67ca8205996ef47e70f refs/tags/v2.12.1
+0c69e1eb2177fa8f8580632c7b1f97fdb606ce8f refs/tags/v2.13.0
+941f45bcb51457884fa1afd6e24a67377d70f75c refs/tags/v2.13.1
+07f30430d4186c2712761f1ffaea50ede63f2b2b refs/tags/v2.13.2
+bd67643652d3800837f1f41549a2a5adbaa3fafe refs/tags/v2.13.3
+c6239a8a1b6871cc0fb5f7af885a02ffd1349f9d refs/tags/v2.13.4
+7c33cdc2d39c7b99a122579f53bc94c8eb3332ff refs/tags/v2.13.5
+a2e59f0e7065404b44dfe92a28aca47ba1378dc4 refs/tags/v2.13.6
+c36cf6254170aa8aef35b65854f518016551d5b8 refs/tags/v2.2.0
+^2a5a5ec0a47c245fbf1bb1a8a90b4c3278e01693
+9a9239eaa52e0e2a16c76894a7f30f19997f0167 refs/tags/v2.2.1
+^86e2ad4f77442c3350f9a2476650da6bee253c52
+8bd683141ccf900aafc3dc76e5efd86f1e8ac541 refs/tags/v2.2.2
+^f117a48ea2fd446d2865826a58d08027d4579cb3
+197ae8a04cec7bf9327d36c780d4fca2a6b51339 refs/tags/v2.2.3
+^8edc147d67ca85a93ed1f53628004528dc36a04d
+e4637eb508aa3e41233875f6ce3891d96fbc5d33 refs/tags/v2.2.4
+^9a19306fbf30642ca331d0ec88e7da54a96860f9
+7107ada7cbbd01e76a2a9f3e2ec27b683dcec99b refs/tags/v2.3.0
+^e43e1cc01ae6d4e4e5ba10557a057d7f3d5ece0d
+ca8264815ffcf8beda3b206405a92927c722027f refs/tags/v2.4.0
+^00a0aa992953d6482114a0f539a21bb535a16383
+8b7a01d0b8dddf9ff650a6511377cd32a4f1501a refs/tags/v2.4.1
+^e44fcc3c15b41f0720c72832c0b9cd07de819781
+6c383e01bbd4155a29ad280ad7ba7941e05675dd refs/tags/v2.4.2
+^7ec2ddfc95f65d1e986d359466a6c254aa514ef3
+aa56a0e4a40af9ff27dd5b4d283d29bc64c19088 refs/tags/v2.4.3
+^80d452484c5409444b0ec19383faa84bb7a4d351
+014cd12ec1a3258f3bfc6597f371ed46c8e89ccd refs/tags/v2.5.0
+^3b1dbebabc801c9cf6f0953a4c20b904d444f879
+78b2d1991b9e81bbc1a6670ab4af189094e952eb refs/tags/v2.6.0
+^59a2ac2745d8a57ac94c6accced73620d59fb844
+319b99648b94c37e16cec64e0aec6d80557de64f refs/tags/v2.6.0b1
+d46f3322a45cb907777f568bb1377ab1b9457ad8 refs/tags/v2.6.0rc1
+c4a8b5bb9140cdc8c214044d41e2593986f875d0 refs/tags/v2.6.0rc2
+c16da993094988141101ac4d96a9b2c92f9ac714 refs/tags/v2.6.0rc3
+f4bc37b3de4857b9d80c1d85ff9f9e5dceef3dd4 refs/tags/v2.6.1
+^f1abf5d9159b805674197f6bc443592e631c9130
+c7faa0f557df4ee266e6e6dca311cd1474ad2123 refs/tags/v2.6.2
+^8de7772cc72daca8e947b79b83fea46214931604
+40d14c37b4cb8488a241f837ea2e3eb60404f7b7 refs/tags/v2.7.0
+^65e95ea8675ea34bdd566d6461330f25c651e5a8
+c0e8a831c6023be719144e7d10c8ea7c9fb81a58 refs/tags/v2.7.1
+^787d2c88cafa4d07fb38c9519c485a86323cfcf4
+dc756043d5ed7654e48c41d97a64403a847214a7 refs/tags/v2.8.0
+^97976c16fb7652f7faf02d76756666ef87adbe7d
+79dfe03e432e2af41bba00add596e6df92099b49 refs/tags/v2.8.1
+^f7b499615e14d70ab098a20deb0cdb3889998a1a
+1dad2a58efb1eef1eb9f2e5532dedd3711924810 refs/tags/v2.9.0
+^45f792efdd92da094548e2095d6efdbfa7e536ee
+35b51445ba2bf5e67137c04bc26ceaab33e4285f refs/tags/v2.9.1
+^ffa346860b306c9bbfb341aed9c14c067751feb8
+dd9ef9f901f3d49426f87a67666393970a6c9431 refs/tags/v2.9.2
+^914c06fb252b6cc3727d0eedab6736e88a3fcb01
+f0ecf21301c0c24bc78b8b310347c7507d9f41d0 refs/tags/v3.0.0
+^ed5057ded698e305210269dafa57574ecf964483
+fc888f758fde1c37d80f85666060d3f179f6c001 refs/tags/v3.0.0rc1
+df595b16579d847cd019072aa0daec1e566c7ba2 refs/tags/v3.0.0rc2
+5d32ed76c0ea53d689f9cec3d4c152d1b0738e8e refs/tags/v3.0.0rc3
+ea3e33e40dd1cbfa9f885e991386337a0e5b4b66 refs/tags/v3.0.0rc4
+e86205cb2ba070755d582856430c0f83c0af6694 refs/tags/v3.0.1
+^f5fbe867d2d26e4a0a9177a51f6e568868ad3dc8
+e6c503bb0b0c13f76ca0546eca7f8d986039517f refs/tags/v3.0.2
+^45fab4087eaaff234227a10cf7845e8b07f28a98

third_party/CityFlow/extern/pybind11/.gitattributes

@@ -1 +1 @@
-docs/*.svg binary
+docs/*.svg binary

third_party/CityFlow/extern/pybind11/.github/CODEOWNERS

@@ -1,9 +1,9 @@
-*.cmake @henryiii
-CMakeLists.txt @henryiii
-*.yml @henryiii
-*.yaml @henryiii
-/tools/ @henryiii
-/pybind11/ @henryiii
-noxfile.py @henryiii
-.clang-format @henryiii
-.clang-tidy @henryiii
+*.cmake @henryiii
+CMakeLists.txt @henryiii
+*.yml @henryiii
+*.yaml @henryiii
+/tools/ @henryiii
+/pybind11/ @henryiii
+noxfile.py @henryiii
+.clang-format @henryiii
+.clang-tidy @henryiii

third_party/CityFlow/extern/pybind11/.github/CONTRIBUTING.md

@@ -1,388 +1,388 @@
-Thank you for your interest in this project! Please refer to the following
-sections on how to contribute code and bug reports.
-
-### Reporting bugs
-
-Before submitting a question or bug report, please take a moment of your time
-and ensure that your issue isn't already discussed in the project documentation
-provided at [pybind11.readthedocs.org][] or in the [issue tracker][]. You can
-also check [gitter][] to see if it came up before.
-
-Assuming that you have identified a previously unknown problem or an important
-question, it's essential that you submit a self-contained and minimal piece of
-code that reproduces the problem. In other words: no external dependencies,
-isolate the function(s) that cause breakage, submit matched and complete C++
-and Python snippets that can be easily compiled and run in isolation; or
-ideally make a small PR with a failing test case that can be used as a starting
-point.
-
-## Pull requests
-
-Contributions are submitted, reviewed, and accepted using GitHub pull requests.
-Please refer to [this article][using pull requests] for details and adhere to
-the following rules to make the process as smooth as possible:
-
-* Make a new branch for every feature you're working on.
-* Make small and clean pull requests that are easy to review but make sure they
-  do add value by themselves.
-* Add tests for any new functionality and run the test suite (`cmake --build
-  build --target pytest`) to ensure that no existing features break.
-* Please run [`pre-commit`][pre-commit] to check your code matches the
-  project style. (Note that `gawk` is required.) Use `pre-commit run
-  --all-files` before committing (or use installed-mode, check pre-commit docs)
-  to verify your code passes before pushing to save time.
-* This project has a strong focus on providing general solutions using a
-  minimal amount of code, thus small pull requests are greatly preferred.
-
-### Licensing of contributions
-
-pybind11 is provided under a BSD-style license that can be found in the
-``LICENSE`` file. By using, distributing, or contributing to this project, you
-agree to the terms and conditions of this license.
-
-You are under no obligation whatsoever to provide any bug fixes, patches, or
-upgrades to the features, functionality or performance of the source code
-("Enhancements") to anyone; however, if you choose to make your Enhancements
-available either publicly, or directly to the author of this software, without
-imposing a separate written license agreement for such Enhancements, then you
-hereby grant the following license: a non-exclusive, royalty-free perpetual
-license to install, use, modify, prepare derivative works, incorporate into
-other computer software, distribute, and sublicense such enhancements or
-derivative works thereof, in binary and source code form.
-
-
-## Development of pybind11
-
-### Quick setup
-
-To setup a quick development environment, use [`nox`](https://nox.thea.codes).
-This will allow you to do some common tasks with minimal setup effort, but will
-take more time to run and be less flexible than a full development environment.
-If you use [`pipx run nox`](https://pipx.pypa.io), you don't even need to
-install `nox`. Examples:
-
-```bash
-# List all available sessions
-nox -l
-
-# Run linters
-nox -s lint
-
-# Run tests on Python 3.9
-nox -s tests-3.9
-
-# Build and preview docs
-nox -s docs -- serve
-
-# Build SDists and wheels
-nox -s build
-```
-
-### Full setup
-
-To setup an ideal development environment, run the following commands on a
-system with CMake 3.14+:
-
-```bash
-python3 -m venv venv
-source venv/bin/activate
-pip install -r tests/requirements.txt
-cmake -S . -B build -DDOWNLOAD_CATCH=ON -DDOWNLOAD_EIGEN=ON
-cmake --build build -j4
-```
-
-Tips:
-
-* You can use `virtualenv` (faster, from PyPI) instead of `venv`.
-* You can select any name for your environment folder; if it contains "env" it
-  will be ignored by git.
-* If you don't have CMake 3.14+, just add "cmake" to the pip install command.
-* You can use `-DPYBIND11_FINDPYTHON=ON` to use FindPython on CMake 3.12+
-* In classic mode, you may need to set `-DPYTHON_EXECUTABLE=/path/to/python`.
-  FindPython uses `-DPython_ROOT_DIR=/path/to` or
-  `-DPython_EXECUTABLE=/path/to/python`.
-
-### Configuration options
-
-In CMake, configuration options are given with "-D". Options are stored in the
-build directory, in the `CMakeCache.txt` file, so they are remembered for each
-build directory. Two selections are special - the generator, given with `-G`,
-and the compiler, which is selected based on environment variables `CXX` and
-similar, or `-DCMAKE_CXX_COMPILER=`. Unlike the others, these cannot be changed
-after the initial run.
-
-The valid options are:
-
-* `-DCMAKE_BUILD_TYPE`: Release, Debug, MinSizeRel, RelWithDebInfo
-* `-DPYBIND11_FINDPYTHON=ON`: Use CMake 3.12+'s FindPython instead of the
-  classic, deprecated, custom FindPythonLibs
-* `-DPYBIND11_NOPYTHON=ON`: Disable all Python searching (disables tests)
-* `-DBUILD_TESTING=ON`: Enable the tests
-* `-DDOWNLOAD_CATCH=ON`: Download catch to build the C++ tests
-* `-DDOWNLOAD_EIGEN=ON`: Download Eigen for the NumPy tests
-* `-DPYBIND11_INSTALL=ON/OFF`: Enable the install target (on by default for the
-  master project)
-* `-DUSE_PYTHON_INSTALL_DIR=ON`: Try to install into the python dir
-
-
-<details><summary>A few standard CMake tricks: (click to expand)</summary><p>
-
-* Use `cmake --build build -v` to see the commands used to build the files.
-* Use `cmake build -LH` to list the CMake options with help.
-* Use `ccmake` if available to see a curses (terminal) gui, or `cmake-gui` for
-  a completely graphical interface (not present in the PyPI package).
-* Use `cmake --build build -j12` to build with 12 cores (for example).
-* Use `-G` and the name of a generator to use something different. `cmake
-  --help` lists the generators available.
-      - On Unix, setting `CMAKE_GENERATER=Ninja` in your environment will give
-        you automatic multithreading on all your CMake projects!
-* Open the `CMakeLists.txt` with QtCreator to generate for that IDE.
-* You can use `-DCMAKE_EXPORT_COMPILE_COMMANDS=ON` to generate the `.json` file
-  that some tools expect.
-
-</p></details>
-
-
-To run the tests, you can "build" the check target:
-
-```bash
-cmake --build build --target check
-```
-
-`--target` can be spelled `-t` in CMake 3.15+. You can also run individual
-tests with these targets:
-
-* `pytest`: Python tests only, using the
-[pytest](https://docs.pytest.org/en/stable/) framework
-* `cpptest`: C++ tests only
-* `test_cmake_build`: Install / subdirectory tests
-
-If you want to build just a subset of tests, use
-`-DPYBIND11_TEST_OVERRIDE="test_callbacks;test_pickling"`. If this is
-empty, all tests will be built. Tests are specified without an extension if they need both a .py and
-.cpp file.
-
-You may also pass flags to the `pytest` target by editing `tests/pytest.ini` or
-by using the `PYTEST_ADDOPTS` environment variable
-(see [`pytest` docs](https://docs.pytest.org/en/2.7.3/customize.html#adding-default-options)). As an example:
-
-```bash
-env PYTEST_ADDOPTS="--capture=no --exitfirst" \
-    cmake --build build --target pytest
-# Or using abbreviated flags
-env PYTEST_ADDOPTS="-s -x" cmake --build build --target pytest
-```
-
-### Formatting
-
-All formatting is handled by pre-commit.
-
-Install with brew (macOS) or pip (any OS):
-
-```bash
-# Any OS
-python3 -m pip install pre-commit
-
-# OR macOS with homebrew:
-brew install pre-commit
-```
-
-Then, you can run it on the items you've added to your staging area, or all
-files:
-
-```bash
-pre-commit run
-# OR
-pre-commit run --all-files
-```
-
-And, if you want to always use it, you can install it as a git hook (hence the
-name, pre-commit):
-
-```bash
-pre-commit install
-```
-
-### Clang-Format
-
-As of v2.6.2, pybind11 ships with a [`clang-format`][clang-format]
-configuration file at the top level of the repo (the filename is
-`.clang-format`). Currently, formatting is NOT applied automatically, but
-manually using `clang-format` for newly developed files is highly encouraged.
-To check if a file needs formatting:
-
-```bash
-clang-format -style=file --dry-run some.cpp
-```
-
-The output will show things to be fixed, if any. To actually format the file:
-
-```bash
-clang-format -style=file -i some.cpp
-```
-
-Note that the `-style-file` option searches the parent directories for the
-`.clang-format` file, i.e. the commands above can be run in any subdirectory
-of the pybind11 repo.
-
-### Clang-Tidy
-
-[`clang-tidy`][clang-tidy] performs deeper static code analyses and is
-more complex to run, compared to `clang-format`, but support for `clang-tidy`
-is built into the pybind11 CMake configuration. To run `clang-tidy`, the
-following recipe should work. Run the `docker` command from the top-level
-directory inside your pybind11 git clone. Files will be modified in place,
-so you can use git to monitor the changes.
-
-```bash
-docker run --rm -v $PWD:/mounted_pybind11 -it silkeh/clang:15-bullseye
-apt-get update && apt-get install -y git python3-dev python3-pytest
-cmake -S /mounted_pybind11/ -B build -DCMAKE_CXX_CLANG_TIDY="$(which clang-tidy);--use-color" -DDOWNLOAD_EIGEN=ON -DDOWNLOAD_CATCH=ON -DCMAKE_CXX_STANDARD=17
-cmake --build build -j 2
-```
-
-You can add `--fix` to the options list if you want.
-
-### Include what you use
-
-To run include what you use, install (`brew install include-what-you-use` on
-macOS), then run:
-
-```bash
-cmake -S . -B build-iwyu -DCMAKE_CXX_INCLUDE_WHAT_YOU_USE=$(which include-what-you-use)
-cmake --build build
-```
-
-The report is sent to stderr; you can pipe it into a file if you wish.
-
-### Build recipes
-
-This builds with the Intel compiler (assuming it is in your path, along with a
-recent CMake and Python):
-
-```bash
-python3 -m venv venv
-. venv/bin/activate
-pip install pytest
-cmake -S . -B build-intel -DCMAKE_CXX_COMPILER=$(which icpc) -DDOWNLOAD_CATCH=ON -DDOWNLOAD_EIGEN=ON -DPYBIND11_WERROR=ON
-```
-
-This will test the PGI compilers:
-
-```bash
-docker run --rm -it -v $PWD:/pybind11 nvcr.io/hpc/pgi-compilers:ce
-apt-get update && apt-get install -y python3-dev python3-pip python3-pytest
-wget -qO- "https://cmake.org/files/v3.18/cmake-3.18.2-Linux-x86_64.tar.gz" | tar --strip-components=1 -xz -C /usr/local
-cmake -S pybind11/ -B build
-cmake --build build
-```
-
-### Explanation of the SDist/wheel building design
-
-> These details below are _only_ for packaging the Python sources from git. The
-> SDists and wheels created do not have any extra requirements at all and are
-> completely normal.
-
-The main objective of the packaging system is to create SDists (Python's source
-distribution packages) and wheels (Python's binary distribution packages) that
-include everything that is needed to work with pybind11, and which can be
-installed without any additional dependencies. This is more complex than it
-appears: in order to support CMake as a first class language even when using
-the PyPI package, they must include the _generated_ CMake files (so as not to
-require CMake when installing the `pybind11` package itself). They should also
-provide the option to install to the "standard" location
-(`<ENVROOT>/include/pybind11` and `<ENVROOT>/share/cmake/pybind11`) so they are
-easy to find with CMake, but this can cause problems if you are not an
-environment or using ``pyproject.toml`` requirements. This was solved by having
-two packages; the "nice" pybind11 package that stores the includes and CMake
-files inside the package, that you get access to via functions in the package,
-and a `pybind11-global` package that can be included via `pybind11[global]` if
-you want the more invasive but discoverable file locations.
-
-If you want to install or package the GitHub source, it is best to have Pip 10
-or newer on Windows, macOS, or Linux (manylinux1 compatible, includes most
-distributions).  You can then build the SDists, or run any procedure that makes
-SDists internally, like making wheels or installing.
-
-
-```bash
-# Editable development install example
-python3 -m pip install -e .
-```
-
-Since Pip itself does not have an `sdist` command (it does have `wheel` and
-`install`), you may want to use the upcoming `build` package:
-
-```bash
-python3 -m pip install build
-
-# Normal package
-python3 -m build -s .
-
-# Global extra
-PYBIND11_GLOBAL_SDIST=1 python3 -m build -s .
-```
-
-If you want to use the classic "direct" usage of `python setup.py`, you will
-need CMake 3.15+ and either `make` or `ninja` preinstalled (possibly via `pip
-install cmake ninja`), since directly running Python on `setup.py` cannot pick
-up and install `pyproject.toml` requirements. As long as you have those two
-things, though, everything works the way you would expect:
-
-```bash
-# Normal package
-python3 setup.py sdist
-
-# Global extra
-PYBIND11_GLOBAL_SDIST=1 python3 setup.py sdist
-```
-
-A detailed explanation of the build procedure design for developers wanting to
-work on or maintain the packaging system is as follows:
-
-#### 1. Building from the source directory
-
-When you invoke any `setup.py` command from the source directory, including
-`pip wheel .` and `pip install .`, you will activate a full source build. This
-is made of the following steps:
-
-1. If the tool is PEP 518 compliant, like Pip 10+, it will create a temporary
-   virtual environment and install the build requirements (mostly CMake) into
-   it. (if you are not on Windows, macOS, or a manylinux compliant system, you
-   can disable this with `--no-build-isolation` as long as you have CMake 3.15+
-   installed)
-2. The environment variable `PYBIND11_GLOBAL_SDIST` is checked - if it is set
-   and truthy, this will be make the accessory `pybind11-global` package,
-   instead of the normal `pybind11` package. This package is used for
-   installing the files directly to your environment root directory, using
-   `pybind11[global]`.
-2. `setup.py` reads the version from `pybind11/_version.py` and verifies it
-   matches `includes/pybind11/detail/common.h`.
-3. CMake is run with `-DCMAKE_INSTALL_PREIFX=pybind11`. Since the CMake install
-   procedure uses only relative paths and is identical on all platforms, these
-   files are valid as long as they stay in the correct relative position to the
-   includes. `pybind11/share/cmake/pybind11` has the CMake files, and
-   `pybind11/include` has the includes. The build directory is discarded.
-4. Simpler files are placed in the SDist: `tools/setup_*.py.in`,
-   `tools/pyproject.toml` (`main` or `global`)
-5. The package is created by running the setup function in the
-   `tools/setup_*.py`.  `setup_main.py` fills in Python packages, and
-   `setup_global.py` fills in only the data/header slots.
-6. A context manager cleans up the temporary CMake install directory (even if
-   an error is thrown).
-
-### 2. Building from SDist
-
-Since the SDist has the rendered template files in `tools` along with the
-includes and CMake files in the correct locations, the builds are completely
-trivial and simple. No extra requirements are required. You can even use Pip 9
-if you really want to.
-
-
-[pre-commit]: https://pre-commit.com
-[clang-format]: https://clang.llvm.org/docs/ClangFormat.html
-[clang-tidy]: https://clang.llvm.org/extra/clang-tidy/
-[pybind11.readthedocs.org]: http://pybind11.readthedocs.org/en/latest
-[issue tracker]: https://github.com/pybind/pybind11/issues
-[gitter]: https://gitter.im/pybind/Lobby
-[using pull requests]: https://help.github.com/articles/using-pull-requests
+Thank you for your interest in this project! Please refer to the following
+sections on how to contribute code and bug reports.
+
+### Reporting bugs
+
+Before submitting a question or bug report, please take a moment of your time
+and ensure that your issue isn't already discussed in the project documentation
+provided at [pybind11.readthedocs.org][] or in the [issue tracker][]. You can
+also check [gitter][] to see if it came up before.
+
+Assuming that you have identified a previously unknown problem or an important
+question, it's essential that you submit a self-contained and minimal piece of
+code that reproduces the problem. In other words: no external dependencies,
+isolate the function(s) that cause breakage, submit matched and complete C++
+and Python snippets that can be easily compiled and run in isolation; or
+ideally make a small PR with a failing test case that can be used as a starting
+point.
+
+## Pull requests
+
+Contributions are submitted, reviewed, and accepted using GitHub pull requests.
+Please refer to [this article][using pull requests] for details and adhere to
+the following rules to make the process as smooth as possible:
+
+* Make a new branch for every feature you're working on.
+* Make small and clean pull requests that are easy to review but make sure they
+  do add value by themselves.
+* Add tests for any new functionality and run the test suite (`cmake --build
+  build --target pytest`) to ensure that no existing features break.
+* Please run [`pre-commit`][pre-commit] to check your code matches the
+  project style. (Note that `gawk` is required.) Use `pre-commit run
+  --all-files` before committing (or use installed-mode, check pre-commit docs)
+  to verify your code passes before pushing to save time.
+* This project has a strong focus on providing general solutions using a
+  minimal amount of code, thus small pull requests are greatly preferred.
+
+### Licensing of contributions
+
+pybind11 is provided under a BSD-style license that can be found in the
+``LICENSE`` file. By using, distributing, or contributing to this project, you
+agree to the terms and conditions of this license.
+
+You are under no obligation whatsoever to provide any bug fixes, patches, or
+upgrades to the features, functionality or performance of the source code
+("Enhancements") to anyone; however, if you choose to make your Enhancements
+available either publicly, or directly to the author of this software, without
+imposing a separate written license agreement for such Enhancements, then you
+hereby grant the following license: a non-exclusive, royalty-free perpetual
+license to install, use, modify, prepare derivative works, incorporate into
+other computer software, distribute, and sublicense such enhancements or
+derivative works thereof, in binary and source code form.
+
+
+## Development of pybind11
+
+### Quick setup
+
+To setup a quick development environment, use [`nox`](https://nox.thea.codes).
+This will allow you to do some common tasks with minimal setup effort, but will
+take more time to run and be less flexible than a full development environment.
+If you use [`pipx run nox`](https://pipx.pypa.io), you don't even need to
+install `nox`. Examples:
+
+```bash
+# List all available sessions
+nox -l
+
+# Run linters
+nox -s lint
+
+# Run tests on Python 3.9
+nox -s tests-3.9
+
+# Build and preview docs
+nox -s docs -- serve
+
+# Build SDists and wheels
+nox -s build
+```
+
+### Full setup
+
+To setup an ideal development environment, run the following commands on a
+system with CMake 3.14+:
+
+```bash
+python3 -m venv venv
+source venv/bin/activate
+pip install -r tests/requirements.txt
+cmake -S . -B build -DDOWNLOAD_CATCH=ON -DDOWNLOAD_EIGEN=ON
+cmake --build build -j4
+```
+
+Tips:
+
+* You can use `virtualenv` (faster, from PyPI) instead of `venv`.
+* You can select any name for your environment folder; if it contains "env" it
+  will be ignored by git.
+* If you don't have CMake 3.14+, just add "cmake" to the pip install command.
+* You can use `-DPYBIND11_FINDPYTHON=ON` to use FindPython on CMake 3.12+
+* In classic mode, you may need to set `-DPYTHON_EXECUTABLE=/path/to/python`.
+  FindPython uses `-DPython_ROOT_DIR=/path/to` or
+  `-DPython_EXECUTABLE=/path/to/python`.
+
+### Configuration options
+
+In CMake, configuration options are given with "-D". Options are stored in the
+build directory, in the `CMakeCache.txt` file, so they are remembered for each
+build directory. Two selections are special - the generator, given with `-G`,
+and the compiler, which is selected based on environment variables `CXX` and
+similar, or `-DCMAKE_CXX_COMPILER=`. Unlike the others, these cannot be changed
+after the initial run.
+
+The valid options are:
+
+* `-DCMAKE_BUILD_TYPE`: Release, Debug, MinSizeRel, RelWithDebInfo
+* `-DPYBIND11_FINDPYTHON=ON`: Use CMake 3.12+'s FindPython instead of the
+  classic, deprecated, custom FindPythonLibs
+* `-DPYBIND11_NOPYTHON=ON`: Disable all Python searching (disables tests)
+* `-DBUILD_TESTING=ON`: Enable the tests
+* `-DDOWNLOAD_CATCH=ON`: Download catch to build the C++ tests
+* `-DDOWNLOAD_EIGEN=ON`: Download Eigen for the NumPy tests
+* `-DPYBIND11_INSTALL=ON/OFF`: Enable the install target (on by default for the
+  master project)
+* `-DUSE_PYTHON_INSTALL_DIR=ON`: Try to install into the python dir
+
+
+<details><summary>A few standard CMake tricks: (click to expand)</summary><p>
+
+* Use `cmake --build build -v` to see the commands used to build the files.
+* Use `cmake build -LH` to list the CMake options with help.
+* Use `ccmake` if available to see a curses (terminal) gui, or `cmake-gui` for
+  a completely graphical interface (not present in the PyPI package).
+* Use `cmake --build build -j12` to build with 12 cores (for example).
+* Use `-G` and the name of a generator to use something different. `cmake
+  --help` lists the generators available.
+      - On Unix, setting `CMAKE_GENERATER=Ninja` in your environment will give
+        you automatic multithreading on all your CMake projects!
+* Open the `CMakeLists.txt` with QtCreator to generate for that IDE.
+* You can use `-DCMAKE_EXPORT_COMPILE_COMMANDS=ON` to generate the `.json` file
+  that some tools expect.
+
+</p></details>
+
+
+To run the tests, you can "build" the check target:
+
+```bash
+cmake --build build --target check
+```
+
+`--target` can be spelled `-t` in CMake 3.15+. You can also run individual
+tests with these targets:
+
+* `pytest`: Python tests only, using the
+[pytest](https://docs.pytest.org/en/stable/) framework
+* `cpptest`: C++ tests only
+* `test_cmake_build`: Install / subdirectory tests
+
+If you want to build just a subset of tests, use
+`-DPYBIND11_TEST_OVERRIDE="test_callbacks;test_pickling"`. If this is
+empty, all tests will be built. Tests are specified without an extension if they need both a .py and
+.cpp file.
+
+You may also pass flags to the `pytest` target by editing `tests/pytest.ini` or
+by using the `PYTEST_ADDOPTS` environment variable
+(see [`pytest` docs](https://docs.pytest.org/en/2.7.3/customize.html#adding-default-options)). As an example:
+
+```bash
+env PYTEST_ADDOPTS="--capture=no --exitfirst" \
+    cmake --build build --target pytest
+# Or using abbreviated flags
+env PYTEST_ADDOPTS="-s -x" cmake --build build --target pytest
+```
+
+### Formatting
+
+All formatting is handled by pre-commit.
+
+Install with brew (macOS) or pip (any OS):
+
+```bash
+# Any OS
+python3 -m pip install pre-commit
+
+# OR macOS with homebrew:
+brew install pre-commit
+```
+
+Then, you can run it on the items you've added to your staging area, or all
+files:
+
+```bash
+pre-commit run
+# OR
+pre-commit run --all-files
+```
+
+And, if you want to always use it, you can install it as a git hook (hence the
+name, pre-commit):
+
+```bash
+pre-commit install
+```
+
+### Clang-Format
+
+As of v2.6.2, pybind11 ships with a [`clang-format`][clang-format]
+configuration file at the top level of the repo (the filename is
+`.clang-format`). Currently, formatting is NOT applied automatically, but
+manually using `clang-format` for newly developed files is highly encouraged.
+To check if a file needs formatting:
+
+```bash
+clang-format -style=file --dry-run some.cpp
+```
+
+The output will show things to be fixed, if any. To actually format the file:
+
+```bash
+clang-format -style=file -i some.cpp
+```
+
+Note that the `-style-file` option searches the parent directories for the
+`.clang-format` file, i.e. the commands above can be run in any subdirectory
+of the pybind11 repo.
+
+### Clang-Tidy
+
+[`clang-tidy`][clang-tidy] performs deeper static code analyses and is
+more complex to run, compared to `clang-format`, but support for `clang-tidy`
+is built into the pybind11 CMake configuration. To run `clang-tidy`, the
+following recipe should work. Run the `docker` command from the top-level
+directory inside your pybind11 git clone. Files will be modified in place,
+so you can use git to monitor the changes.
+
+```bash
+docker run --rm -v $PWD:/mounted_pybind11 -it silkeh/clang:15-bullseye
+apt-get update && apt-get install -y git python3-dev python3-pytest
+cmake -S /mounted_pybind11/ -B build -DCMAKE_CXX_CLANG_TIDY="$(which clang-tidy);--use-color" -DDOWNLOAD_EIGEN=ON -DDOWNLOAD_CATCH=ON -DCMAKE_CXX_STANDARD=17
+cmake --build build -j 2
+```
+
+You can add `--fix` to the options list if you want.
+
+### Include what you use
+
+To run include what you use, install (`brew install include-what-you-use` on
+macOS), then run:
+
+```bash
+cmake -S . -B build-iwyu -DCMAKE_CXX_INCLUDE_WHAT_YOU_USE=$(which include-what-you-use)
+cmake --build build
+```
+
+The report is sent to stderr; you can pipe it into a file if you wish.
+
+### Build recipes
+
+This builds with the Intel compiler (assuming it is in your path, along with a
+recent CMake and Python):
+
+```bash
+python3 -m venv venv
+. venv/bin/activate
+pip install pytest
+cmake -S . -B build-intel -DCMAKE_CXX_COMPILER=$(which icpc) -DDOWNLOAD_CATCH=ON -DDOWNLOAD_EIGEN=ON -DPYBIND11_WERROR=ON
+```
+
+This will test the PGI compilers:
+
+```bash
+docker run --rm -it -v $PWD:/pybind11 nvcr.io/hpc/pgi-compilers:ce
+apt-get update && apt-get install -y python3-dev python3-pip python3-pytest
+wget -qO- "https://cmake.org/files/v3.18/cmake-3.18.2-Linux-x86_64.tar.gz" | tar --strip-components=1 -xz -C /usr/local
+cmake -S pybind11/ -B build
+cmake --build build
+```
+
+### Explanation of the SDist/wheel building design
+
+> These details below are _only_ for packaging the Python sources from git. The
+> SDists and wheels created do not have any extra requirements at all and are
+> completely normal.
+
+The main objective of the packaging system is to create SDists (Python's source
+distribution packages) and wheels (Python's binary distribution packages) that
+include everything that is needed to work with pybind11, and which can be
+installed without any additional dependencies. This is more complex than it
+appears: in order to support CMake as a first class language even when using
+the PyPI package, they must include the _generated_ CMake files (so as not to
+require CMake when installing the `pybind11` package itself). They should also
+provide the option to install to the "standard" location
+(`<ENVROOT>/include/pybind11` and `<ENVROOT>/share/cmake/pybind11`) so they are
+easy to find with CMake, but this can cause problems if you are not an
+environment or using ``pyproject.toml`` requirements. This was solved by having
+two packages; the "nice" pybind11 package that stores the includes and CMake
+files inside the package, that you get access to via functions in the package,
+and a `pybind11-global` package that can be included via `pybind11[global]` if
+you want the more invasive but discoverable file locations.
+
+If you want to install or package the GitHub source, it is best to have Pip 10
+or newer on Windows, macOS, or Linux (manylinux1 compatible, includes most
+distributions).  You can then build the SDists, or run any procedure that makes
+SDists internally, like making wheels or installing.
+
+
+```bash
+# Editable development install example
+python3 -m pip install -e .
+```
+
+Since Pip itself does not have an `sdist` command (it does have `wheel` and
+`install`), you may want to use the upcoming `build` package:
+
+```bash
+python3 -m pip install build
+
+# Normal package
+python3 -m build -s .
+
+# Global extra
+PYBIND11_GLOBAL_SDIST=1 python3 -m build -s .
+```
+
+If you want to use the classic "direct" usage of `python setup.py`, you will
+need CMake 3.15+ and either `make` or `ninja` preinstalled (possibly via `pip
+install cmake ninja`), since directly running Python on `setup.py` cannot pick
+up and install `pyproject.toml` requirements. As long as you have those two
+things, though, everything works the way you would expect:
+
+```bash
+# Normal package
+python3 setup.py sdist
+
+# Global extra
+PYBIND11_GLOBAL_SDIST=1 python3 setup.py sdist
+```
+
+A detailed explanation of the build procedure design for developers wanting to
+work on or maintain the packaging system is as follows:
+
+#### 1. Building from the source directory
+
+When you invoke any `setup.py` command from the source directory, including
+`pip wheel .` and `pip install .`, you will activate a full source build. This
+is made of the following steps:
+
+1. If the tool is PEP 518 compliant, like Pip 10+, it will create a temporary
+   virtual environment and install the build requirements (mostly CMake) into
+   it. (if you are not on Windows, macOS, or a manylinux compliant system, you
+   can disable this with `--no-build-isolation` as long as you have CMake 3.15+
+   installed)
+2. The environment variable `PYBIND11_GLOBAL_SDIST` is checked - if it is set
+   and truthy, this will be make the accessory `pybind11-global` package,
+   instead of the normal `pybind11` package. This package is used for
+   installing the files directly to your environment root directory, using
+   `pybind11[global]`.
+2. `setup.py` reads the version from `pybind11/_version.py` and verifies it
+   matches `includes/pybind11/detail/common.h`.
+3. CMake is run with `-DCMAKE_INSTALL_PREIFX=pybind11`. Since the CMake install
+   procedure uses only relative paths and is identical on all platforms, these
+   files are valid as long as they stay in the correct relative position to the
+   includes. `pybind11/share/cmake/pybind11` has the CMake files, and
+   `pybind11/include` has the includes. The build directory is discarded.
+4. Simpler files are placed in the SDist: `tools/setup_*.py.in`,
+   `tools/pyproject.toml` (`main` or `global`)
+5. The package is created by running the setup function in the
+   `tools/setup_*.py`.  `setup_main.py` fills in Python packages, and
+   `setup_global.py` fills in only the data/header slots.
+6. A context manager cleans up the temporary CMake install directory (even if
+   an error is thrown).
+
+### 2. Building from SDist
+
+Since the SDist has the rendered template files in `tools` along with the
+includes and CMake files in the correct locations, the builds are completely
+trivial and simple. No extra requirements are required. You can even use Pip 9
+if you really want to.
+
+
+[pre-commit]: https://pre-commit.com
+[clang-format]: https://clang.llvm.org/docs/ClangFormat.html
+[clang-tidy]: https://clang.llvm.org/extra/clang-tidy/
+[pybind11.readthedocs.org]: http://pybind11.readthedocs.org/en/latest
+[issue tracker]: https://github.com/pybind/pybind11/issues
+[gitter]: https://gitter.im/pybind/Lobby
+[using pull requests]: https://help.github.com/articles/using-pull-requests

third_party/CityFlow/extern/pybind11/.github/dependabot.yml

@@ -1,15 +1,15 @@
-version: 2
-updates:
-  # Maintain dependencies for GitHub Actions
-  - package-ecosystem: "github-actions"
-    directory: "/"
-    schedule:
-      interval: "weekly"
-    groups:
-      actions:
-        patterns:
-          - "*"
-    ignore:
-      - dependency-name: actions/checkout
-        versions:
-          - "<5"
+version: 2
+updates:
+  # Maintain dependencies for GitHub Actions
+  - package-ecosystem: "github-actions"
+    directory: "/"
+    schedule:
+      interval: "weekly"
+    groups:
+      actions:
+        patterns:
+          - "*"
+    ignore:
+      - dependency-name: actions/checkout
+        versions:
+          - "<5"

third_party/CityFlow/extern/pybind11/.github/labeler.yml

@@ -1,8 +1,8 @@
-docs:
-- any:
-  - 'docs/**/*.rst'
-  - '!docs/changelog.rst'
-  - '!docs/upgrade.rst'
-
-ci:
-- '.github/workflows/*.yml'
+docs:
+- any:
+  - 'docs/**/*.rst'
+  - '!docs/changelog.rst'
+  - '!docs/upgrade.rst'
+
+ci:
+- '.github/workflows/*.yml'

third_party/CityFlow/extern/pybind11/.github/labeler_merged.yml

@@ -1,3 +1,3 @@
-needs changelog:
-- all:
-  - '!docs/changelog.rst'
+needs changelog:
+- all:
+  - '!docs/changelog.rst'

third_party/CityFlow/extern/pybind11/.github/pull_request_template.md

@@ -1,19 +1,19 @@
-<!--
-Title (above): please place [branch_name] at the beginning if you are targeting a branch other than master. *Do not target stable*.
-It is recommended to use conventional commit format, see conventionalcommits.org, but not required.
--->
-## Description
-
-<!-- Include relevant issues or PRs here, describe what changed and why -->
-
-
-## Suggested changelog entry:
-
-<!-- Fill in the below block with the expected RestructuredText entry. Delete if no entry needed;
-     but do not delete header or rst block if an entry is needed! Will be collected via a script. -->
-
-```rst
-
-```
-
-<!-- If the upgrade guide needs updating, note that here too -->
+<!--
+Title (above): please place [branch_name] at the beginning if you are targeting a branch other than master. *Do not target stable*.
+It is recommended to use conventional commit format, see conventionalcommits.org, but not required.
+-->
+## Description
+
+<!-- Include relevant issues or PRs here, describe what changed and why -->
+
+
+## Suggested changelog entry:
+
+<!-- Fill in the below block with the expected RestructuredText entry. Delete if no entry needed;
+     but do not delete header or rst block if an entry is needed! Will be collected via a script. -->
+
+```rst
+
+```
+
+<!-- If the upgrade guide needs updating, note that here too -->

third_party/CityFlow/extern/pybind11/.gitignore

@@ -1,46 +1,46 @@
-CMakeCache.txt
-CMakeFiles
-Makefile
-cmake_install.cmake
-cmake_uninstall.cmake
-.DS_Store
-*.so
-*.pyd
-*.dll
-*.sln
-*.sdf
-*.opensdf
-*.vcxproj
-*.vcxproj.user
-*.filters
-example.dir
-Win32
-x64
-Release
-Debug
-.vs
-CTestTestfile.cmake
-Testing
-autogen
-MANIFEST
-/.ninja_*
-/*.ninja
-/docs/.build
-*.py[co]
-*.egg-info
-*~
-.*.swp
-.DS_Store
-/dist
-/*build*
-.cache/
-sosize-*.txt
-pybind11Config*.cmake
-pybind11Targets.cmake
-/*env*
-/.vscode
-/pybind11/include/*
-/pybind11/share/*
-/docs/_build/*
-.ipynb_checkpoints/
-tests/main.cpp
+CMakeCache.txt
+CMakeFiles
+Makefile
+cmake_install.cmake
+cmake_uninstall.cmake
+.DS_Store
+*.so
+*.pyd
+*.dll
+*.sln
+*.sdf
+*.opensdf
+*.vcxproj
+*.vcxproj.user
+*.filters
+example.dir
+Win32
+x64
+Release
+Debug
+.vs
+CTestTestfile.cmake
+Testing
+autogen
+MANIFEST
+/.ninja_*
+/*.ninja
+/docs/.build
+*.py[co]
+*.egg-info
+*~
+.*.swp
+.DS_Store
+/dist
+/*build*
+.cache/
+sosize-*.txt
+pybind11Config*.cmake
+pybind11Targets.cmake
+/*env*
+/.vscode
+/pybind11/include/*
+/pybind11/share/*
+/docs/_build/*
+.ipynb_checkpoints/
+tests/main.cpp

third_party/CityFlow/extern/pybind11/.pre-commit-config.yaml

@@ -1,155 +1,155 @@
-# To use:
-#
-#     pre-commit run -a
-#
-# Or:
-#
-#     pre-commit install  # (runs every time you commit in git)
-#
-# To update this file:
-#
-#     pre-commit autoupdate
-#
-# See https://github.com/pre-commit/pre-commit
-
-
-ci:
-  autoupdate_commit_msg: "chore(deps): update pre-commit hooks"
-  autofix_commit_msg: "style: pre-commit fixes"
-  autoupdate_schedule: monthly
-
-# third-party content
-exclude: ^tools/JoinPaths.cmake$
-
-repos:
-
-# Clang format the codebase automatically
-- repo: https://github.com/pre-commit/mirrors-clang-format
-  rev: "v17.0.6"
-  hooks:
-  - id: clang-format
-    types_or: [c++, c, cuda]
-
-# Ruff, the Python auto-correcting linter/formatter written in Rust
-- repo: https://github.com/astral-sh/ruff-pre-commit
-  rev: v0.2.0
-  hooks:
-  - id: ruff
-    args: ["--fix", "--show-fixes"]
-  - id: ruff-format
-
-# Check static types with mypy
-- repo: https://github.com/pre-commit/mirrors-mypy
-  rev: "v1.8.0"
-  hooks:
-  - id: mypy
-    args: []
-    exclude: ^(tests|docs)/
-    additional_dependencies:
-    - markdown-it-py<3 # Drop this together with dropping Python 3.7 support.
-    - nox
-    - rich
-    - types-setuptools
-
-# CMake formatting
-- repo: https://github.com/cheshirekow/cmake-format-precommit
-  rev: "v0.6.13"
-  hooks:
-  - id: cmake-format
-    additional_dependencies: [pyyaml]
-    types: [file]
-    files: (\.cmake|CMakeLists.txt)(.in)?$
-
-# Standard hooks
-- repo: https://github.com/pre-commit/pre-commit-hooks
-  rev: "v4.5.0"
-  hooks:
-  - id: check-added-large-files
-  - id: check-case-conflict
-  - id: check-docstring-first
-  - id: check-merge-conflict
-  - id: check-symlinks
-  - id: check-toml
-  - id: check-yaml
-  - id: debug-statements
-  - id: end-of-file-fixer
-  - id: mixed-line-ending
-  - id: requirements-txt-fixer
-  - id: trailing-whitespace
-
-# Also code format the docs
-- repo: https://github.com/asottile/blacken-docs
-  rev: "1.16.0"
-  hooks:
-  - id: blacken-docs
-    additional_dependencies:
-    - black==23.*
-
-# Changes tabs to spaces
-- repo: https://github.com/Lucas-C/pre-commit-hooks
-  rev: "v1.5.4"
-  hooks:
-  - id: remove-tabs
-
-# Avoid directional quotes
-- repo: https://github.com/sirosen/texthooks
-  rev: "0.6.4"
-  hooks:
-  - id: fix-ligatures
-  - id: fix-smartquotes
-
-# Checking for common mistakes
-- repo: https://github.com/pre-commit/pygrep-hooks
-  rev: "v1.10.0"
-  hooks:
-  - id: rst-backticks
-  - id: rst-directive-colons
-  - id: rst-inline-touching-normal
-
-# Checks the manifest for missing files (native support)
-- repo: https://github.com/mgedmin/check-manifest
-  rev: "0.49"
-  hooks:
-  - id: check-manifest
-    # This is a slow hook, so only run this if --hook-stage manual is passed
-    stages: [manual]
-    additional_dependencies: [cmake, ninja]
-
-# Check for spelling
-# Use tools/codespell_ignore_lines_from_errors.py
-# to rebuild .codespell-ignore-lines
-- repo: https://github.com/codespell-project/codespell
-  rev: "v2.2.6"
-  hooks:
-  - id: codespell
-    exclude: ".supp$"
-    args: ["-x.codespell-ignore-lines", "-Lccompiler"]
-
-# Check for common shell mistakes
-- repo: https://github.com/shellcheck-py/shellcheck-py
-  rev: "v0.9.0.6"
-  hooks:
-  - id: shellcheck
-
-# Disallow some common capitalization mistakes
-- repo: local
-  hooks:
-  - id: disallow-caps
-    name: Disallow improper capitalization
-    language: pygrep
-    entry: PyBind|\bNumpy\b|Cmake|CCache|PyTest
-    exclude: ^\.pre-commit-config.yaml$
-
-# PyLint has native support - not always usable, but works for us
-- repo: https://github.com/PyCQA/pylint
-  rev: "v3.0.3"
-  hooks:
-  - id: pylint
-    files: ^pybind11
-
-- repo: https://github.com/python-jsonschema/check-jsonschema
-  rev: 0.28.0
-  hooks:
-  - id: check-readthedocs
-  - id: check-github-workflows
-  - id: check-dependabot
+# To use:
+#
+#     pre-commit run -a
+#
+# Or:
+#
+#     pre-commit install  # (runs every time you commit in git)
+#
+# To update this file:
+#
+#     pre-commit autoupdate
+#
+# See https://github.com/pre-commit/pre-commit
+
+
+ci:
+  autoupdate_commit_msg: "chore(deps): update pre-commit hooks"
+  autofix_commit_msg: "style: pre-commit fixes"
+  autoupdate_schedule: monthly
+
+# third-party content
+exclude: ^tools/JoinPaths.cmake$
+
+repos:
+
+# Clang format the codebase automatically
+- repo: https://github.com/pre-commit/mirrors-clang-format
+  rev: "v17.0.6"
+  hooks:
+  - id: clang-format
+    types_or: [c++, c, cuda]
+
+# Ruff, the Python auto-correcting linter/formatter written in Rust
+- repo: https://github.com/astral-sh/ruff-pre-commit
+  rev: v0.2.0
+  hooks:
+  - id: ruff
+    args: ["--fix", "--show-fixes"]
+  - id: ruff-format
+
+# Check static types with mypy
+- repo: https://github.com/pre-commit/mirrors-mypy
+  rev: "v1.8.0"
+  hooks:
+  - id: mypy
+    args: []
+    exclude: ^(tests|docs)/
+    additional_dependencies:
+    - markdown-it-py<3 # Drop this together with dropping Python 3.7 support.
+    - nox
+    - rich
+    - types-setuptools
+
+# CMake formatting
+- repo: https://github.com/cheshirekow/cmake-format-precommit
+  rev: "v0.6.13"
+  hooks:
+  - id: cmake-format
+    additional_dependencies: [pyyaml]
+    types: [file]
+    files: (\.cmake|CMakeLists.txt)(.in)?$
+
+# Standard hooks
+- repo: https://github.com/pre-commit/pre-commit-hooks
+  rev: "v4.5.0"
+  hooks:
+  - id: check-added-large-files
+  - id: check-case-conflict
+  - id: check-docstring-first
+  - id: check-merge-conflict
+  - id: check-symlinks
+  - id: check-toml
+  - id: check-yaml
+  - id: debug-statements
+  - id: end-of-file-fixer
+  - id: mixed-line-ending
+  - id: requirements-txt-fixer
+  - id: trailing-whitespace
+
+# Also code format the docs
+- repo: https://github.com/asottile/blacken-docs
+  rev: "1.16.0"
+  hooks:
+  - id: blacken-docs
+    additional_dependencies:
+    - black==23.*
+
+# Changes tabs to spaces
+- repo: https://github.com/Lucas-C/pre-commit-hooks
+  rev: "v1.5.4"
+  hooks:
+  - id: remove-tabs
+
+# Avoid directional quotes
+- repo: https://github.com/sirosen/texthooks
+  rev: "0.6.4"
+  hooks:
+  - id: fix-ligatures
+  - id: fix-smartquotes
+
+# Checking for common mistakes
+- repo: https://github.com/pre-commit/pygrep-hooks
+  rev: "v1.10.0"
+  hooks:
+  - id: rst-backticks
+  - id: rst-directive-colons
+  - id: rst-inline-touching-normal
+
+# Checks the manifest for missing files (native support)
+- repo: https://github.com/mgedmin/check-manifest
+  rev: "0.49"
+  hooks:
+  - id: check-manifest
+    # This is a slow hook, so only run this if --hook-stage manual is passed
+    stages: [manual]
+    additional_dependencies: [cmake, ninja]
+
+# Check for spelling
+# Use tools/codespell_ignore_lines_from_errors.py
+# to rebuild .codespell-ignore-lines
+- repo: https://github.com/codespell-project/codespell
+  rev: "v2.2.6"
+  hooks:
+  - id: codespell
+    exclude: ".supp$"
+    args: ["-x.codespell-ignore-lines", "-Lccompiler"]
+
+# Check for common shell mistakes
+- repo: https://github.com/shellcheck-py/shellcheck-py
+  rev: "v0.9.0.6"
+  hooks:
+  - id: shellcheck
+
+# Disallow some common capitalization mistakes
+- repo: local
+  hooks:
+  - id: disallow-caps
+    name: Disallow improper capitalization
+    language: pygrep
+    entry: PyBind|\bNumpy\b|Cmake|CCache|PyTest
+    exclude: ^\.pre-commit-config.yaml$
+
+# PyLint has native support - not always usable, but works for us
+- repo: https://github.com/PyCQA/pylint
+  rev: "v3.0.3"
+  hooks:
+  - id: pylint
+    files: ^pybind11
+
+- repo: https://github.com/python-jsonschema/check-jsonschema
+  rev: 0.28.0
+  hooks:
+  - id: check-readthedocs
+  - id: check-github-workflows
+  - id: check-dependabot

third_party/CityFlow/extern/pybind11/.readthedocs.yml

@@ -1,20 +1,20 @@
-# https://blog.readthedocs.com/migrate-configuration-v2/
-
-version: 2
-
-build:
-  os: ubuntu-22.04
-  apt_packages:
-    - librsvg2-bin
-  tools:
-    python: "3.11"
-
-sphinx:
-  configuration: docs/conf.py
-
-python:
-  install:
-  - requirements: docs/requirements.txt
-
-formats:
-  - pdf
+# https://blog.readthedocs.com/migrate-configuration-v2/
+
+version: 2
+
+build:
+  os: ubuntu-22.04
+  apt_packages:
+    - librsvg2-bin
+  tools:
+    python: "3.11"
+
+sphinx:
+  configuration: docs/conf.py
+
+python:
+  install:
+  - requirements: docs/requirements.txt
+
+formats:
+  - pdf

third_party/CityFlow/extern/pybind11/CMakeLists.txt

@@ -1,373 +1,373 @@
-# CMakeLists.txt -- Build system for the pybind11 modules
-#
-# Copyright (c) 2015 Wenzel Jakob <wenzel@inf.ethz.ch>
-#
-# All rights reserved. Use of this source code is governed by a
-# BSD-style license that can be found in the LICENSE file.
-
-# Propagate this policy (FindPythonInterp removal) so it can be detected later
-if(NOT CMAKE_VERSION VERSION_LESS "3.27")
-  cmake_policy(GET CMP0148 _pybind11_cmp0148)
-endif()
-
-cmake_minimum_required(VERSION 3.5)
-
-# The `cmake_minimum_required(VERSION 3.5...3.27)` syntax does not work with
-# some versions of VS that have a patched CMake 3.11. This forces us to emulate
-# the behavior using the following workaround:
-if(${CMAKE_VERSION} VERSION_LESS 3.27)
-  cmake_policy(VERSION ${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION})
-else()
-  cmake_policy(VERSION 3.27)
-endif()
-
-if(_pybind11_cmp0148)
-  cmake_policy(SET CMP0148 ${_pybind11_cmp0148})
-  unset(_pybind11_cmp0148)
-endif()
-
-# Avoid infinite recursion if tests include this as a subdirectory
-if(DEFINED PYBIND11_MASTER_PROJECT)
-  return()
-endif()
-
-# Extract project version from source
-file(STRINGS "${CMAKE_CURRENT_SOURCE_DIR}/include/pybind11/detail/common.h"
-     pybind11_version_defines REGEX "#define PYBIND11_VERSION_(MAJOR|MINOR|PATCH) ")
-
-foreach(ver ${pybind11_version_defines})
-  if(ver MATCHES [[#define PYBIND11_VERSION_(MAJOR|MINOR|PATCH) +([^ ]+)$]])
-    set(PYBIND11_VERSION_${CMAKE_MATCH_1} "${CMAKE_MATCH_2}")
-  endif()
-endforeach()
-
-if(PYBIND11_VERSION_PATCH MATCHES [[\.([a-zA-Z0-9]+)$]])
-  set(pybind11_VERSION_TYPE "${CMAKE_MATCH_1}")
-endif()
-string(REGEX MATCH "^[0-9]+" PYBIND11_VERSION_PATCH "${PYBIND11_VERSION_PATCH}")
-
-project(
-  pybind11
-  LANGUAGES CXX
-  VERSION "${PYBIND11_VERSION_MAJOR}.${PYBIND11_VERSION_MINOR}.${PYBIND11_VERSION_PATCH}")
-
-# Standard includes
-include(GNUInstallDirs)
-include(CMakePackageConfigHelpers)
-include(CMakeDependentOption)
-
-if(NOT pybind11_FIND_QUIETLY)
-  message(STATUS "pybind11 v${pybind11_VERSION} ${pybind11_VERSION_TYPE}")
-endif()
-
-# Check if pybind11 is being used directly or via add_subdirectory
-if(CMAKE_SOURCE_DIR STREQUAL PROJECT_SOURCE_DIR)
-  ### Warn if not an out-of-source builds
-  if(CMAKE_CURRENT_SOURCE_DIR STREQUAL CMAKE_CURRENT_BINARY_DIR)
-    set(lines
-        "You are building in-place. If that is not what you intended to "
-        "do, you can clean the source directory with:\n"
-        "rm -r CMakeCache.txt CMakeFiles/ cmake_uninstall.cmake pybind11Config.cmake "
-        "pybind11ConfigVersion.cmake tests/CMakeFiles/\n")
-    message(AUTHOR_WARNING ${lines})
-  endif()
-
-  set(PYBIND11_MASTER_PROJECT ON)
-
-  if(OSX AND CMAKE_VERSION VERSION_LESS 3.7)
-    # Bug in macOS CMake < 3.7 is unable to download catch
-    message(WARNING "CMAKE 3.7+ needed on macOS to download catch, and newer HIGHLY recommended")
-  elseif(WINDOWS AND CMAKE_VERSION VERSION_LESS 3.8)
-    # Only tested with 3.8+ in CI.
-    message(WARNING "CMAKE 3.8+ tested on Windows, previous versions untested")
-  endif()
-
-  message(STATUS "CMake ${CMAKE_VERSION}")
-
-  if(CMAKE_CXX_STANDARD)
-    set(CMAKE_CXX_EXTENSIONS OFF)
-    set(CMAKE_CXX_STANDARD_REQUIRED ON)
-  endif()
-
-  set(pybind11_system "")
-
-  set_property(GLOBAL PROPERTY USE_FOLDERS ON)
-  if(CMAKE_VERSION VERSION_LESS "3.18")
-    set(_pybind11_findpython_default OFF)
-  else()
-    set(_pybind11_findpython_default ON)
-  endif()
-else()
-  set(PYBIND11_MASTER_PROJECT OFF)
-  set(pybind11_system SYSTEM)
-  set(_pybind11_findpython_default OFF)
-endif()
-
-# Options
-option(PYBIND11_INSTALL "Install pybind11 header files?" ${PYBIND11_MASTER_PROJECT})
-option(PYBIND11_TEST "Build pybind11 test suite?" ${PYBIND11_MASTER_PROJECT})
-option(PYBIND11_NOPYTHON "Disable search for Python" OFF)
-option(PYBIND11_DISABLE_HANDLE_TYPE_NAME_DEFAULT_IMPLEMENTATION
-       "To enforce that a handle_type_name<> specialization exists" OFF)
-option(PYBIND11_SIMPLE_GIL_MANAGEMENT
-       "Use simpler GIL management logic that does not support disassociation" OFF)
-option(PYBIND11_NUMPY_1_ONLY
-       "Disable NumPy 2 support to avoid changes to previous pybind11 versions." OFF)
-set(PYBIND11_INTERNALS_VERSION
-    ""
-    CACHE STRING "Override the ABI version, may be used to enable the unstable ABI.")
-
-if(PYBIND11_DISABLE_HANDLE_TYPE_NAME_DEFAULT_IMPLEMENTATION)
-  add_compile_definitions(PYBIND11_DISABLE_HANDLE_TYPE_NAME_DEFAULT_IMPLEMENTATION)
-endif()
-if(PYBIND11_SIMPLE_GIL_MANAGEMENT)
-  add_compile_definitions(PYBIND11_SIMPLE_GIL_MANAGEMENT)
-endif()
-if(PYBIND11_NUMPY_1_ONLY)
-  add_compile_definitions(PYBIND11_NUMPY_1_ONLY)
-endif()
-
-cmake_dependent_option(
-  USE_PYTHON_INCLUDE_DIR
-  "Install pybind11 headers in Python include directory instead of default installation prefix"
-  OFF "PYBIND11_INSTALL" OFF)
-
-cmake_dependent_option(PYBIND11_FINDPYTHON "Force new FindPython" ${_pybind11_findpython_default}
-                       "NOT CMAKE_VERSION VERSION_LESS 3.12" OFF)
-
-# Allow PYTHON_EXECUTABLE if in FINDPYTHON mode and building pybind11's tests
-# (makes transition easier while we support both modes).
-if(PYBIND11_MASTER_PROJECT
-   AND PYBIND11_FINDPYTHON
-   AND DEFINED PYTHON_EXECUTABLE
-   AND NOT DEFINED Python_EXECUTABLE)
-  set(Python_EXECUTABLE "${PYTHON_EXECUTABLE}")
-endif()
-
-# NB: when adding a header don't forget to also add it to setup.py
-set(PYBIND11_HEADERS
-    include/pybind11/detail/class.h
-    include/pybind11/detail/common.h
-    include/pybind11/detail/descr.h
-    include/pybind11/detail/init.h
-    include/pybind11/detail/internals.h
-    include/pybind11/detail/type_caster_base.h
-    include/pybind11/detail/typeid.h
-    include/pybind11/attr.h
-    include/pybind11/buffer_info.h
-    include/pybind11/cast.h
-    include/pybind11/chrono.h
-    include/pybind11/common.h
-    include/pybind11/complex.h
-    include/pybind11/options.h
-    include/pybind11/eigen.h
-    include/pybind11/eigen/common.h
-    include/pybind11/eigen/matrix.h
-    include/pybind11/eigen/tensor.h
-    include/pybind11/embed.h
-    include/pybind11/eval.h
-    include/pybind11/gil.h
-    include/pybind11/gil_safe_call_once.h
-    include/pybind11/iostream.h
-    include/pybind11/functional.h
-    include/pybind11/numpy.h
-    include/pybind11/operators.h
-    include/pybind11/pybind11.h
-    include/pybind11/pytypes.h
-    include/pybind11/stl.h
-    include/pybind11/stl_bind.h
-    include/pybind11/stl/filesystem.h
-    include/pybind11/type_caster_pyobject_ptr.h
-    include/pybind11/typing.h)
-
-# Compare with grep and warn if mismatched
-if(PYBIND11_MASTER_PROJECT AND NOT CMAKE_VERSION VERSION_LESS 3.12)
-  file(
-    GLOB_RECURSE _pybind11_header_check
-    LIST_DIRECTORIES false
-    RELATIVE "${CMAKE_CURRENT_SOURCE_DIR}"
-    CONFIGURE_DEPENDS "include/pybind11/*.h")
-  set(_pybind11_here_only ${PYBIND11_HEADERS})
-  set(_pybind11_disk_only ${_pybind11_header_check})
-  list(REMOVE_ITEM _pybind11_here_only ${_pybind11_header_check})
-  list(REMOVE_ITEM _pybind11_disk_only ${PYBIND11_HEADERS})
-  if(_pybind11_here_only)
-    message(AUTHOR_WARNING "PYBIND11_HEADERS has extra files:" ${_pybind11_here_only})
-  endif()
-  if(_pybind11_disk_only)
-    message(AUTHOR_WARNING "PYBIND11_HEADERS is missing files:" ${_pybind11_disk_only})
-  endif()
-endif()
-
-# CMake 3.12 added list(TRANSFORM <list> PREPEND
-# But we can't use it yet
-string(REPLACE "include/" "${CMAKE_CURRENT_SOURCE_DIR}/include/" PYBIND11_HEADERS
-               "${PYBIND11_HEADERS}")
-
-# Cache variable so this can be used in parent projects
-set(pybind11_INCLUDE_DIR
-    "${CMAKE_CURRENT_LIST_DIR}/include"
-    CACHE INTERNAL "Directory where pybind11 headers are located")
-
-# Backward compatible variable for add_subdirectory mode
-if(NOT PYBIND11_MASTER_PROJECT)
-  set(PYBIND11_INCLUDE_DIR
-      "${pybind11_INCLUDE_DIR}"
-      CACHE INTERNAL "")
-endif()
-
-# Note: when creating targets, you cannot use if statements at configure time -
-# you need generator expressions, because those will be placed in the target file.
-# You can also place ifs *in* the Config.in, but not here.
-
-# This section builds targets, but does *not* touch Python
-# Non-IMPORT targets cannot be defined twice
-if(NOT TARGET pybind11_headers)
-  # Build the headers-only target (no Python included):
-  # (long name used here to keep this from clashing in subdirectory mode)
-  add_library(pybind11_headers INTERFACE)
-  add_library(pybind11::pybind11_headers ALIAS pybind11_headers) # to match exported target
-  add_library(pybind11::headers ALIAS pybind11_headers) # easier to use/remember
-
-  target_include_directories(
-    pybind11_headers ${pybind11_system} INTERFACE $<BUILD_INTERFACE:${pybind11_INCLUDE_DIR}>
-                                                  $<INSTALL_INTERFACE:${CMAKE_INSTALL_INCLUDEDIR}>)
-
-  target_compile_features(pybind11_headers INTERFACE cxx_inheriting_constructors cxx_user_literals
-                                                     cxx_right_angle_brackets)
-  if(NOT "${PYBIND11_INTERNALS_VERSION}" STREQUAL "")
-    target_compile_definitions(
-      pybind11_headers INTERFACE "PYBIND11_INTERNALS_VERSION=${PYBIND11_INTERNALS_VERSION}")
-  endif()
-else()
-  # It is invalid to install a target twice, too.
-  set(PYBIND11_INSTALL OFF)
-endif()
-
-include("${CMAKE_CURRENT_SOURCE_DIR}/tools/pybind11Common.cmake")
-# https://github.com/jtojnar/cmake-snips/#concatenating-paths-when-building-pkg-config-files
-# TODO: cmake 3.20 adds the cmake_path() function, which obsoletes this snippet
-include("${CMAKE_CURRENT_SOURCE_DIR}/tools/JoinPaths.cmake")
-
-# Relative directory setting
-if(USE_PYTHON_INCLUDE_DIR AND DEFINED Python_INCLUDE_DIRS)
-  file(RELATIVE_PATH CMAKE_INSTALL_INCLUDEDIR ${CMAKE_INSTALL_PREFIX} ${Python_INCLUDE_DIRS})
-elseif(USE_PYTHON_INCLUDE_DIR AND DEFINED PYTHON_INCLUDE_DIR)
-  file(RELATIVE_PATH CMAKE_INSTALL_INCLUDEDIR ${CMAKE_INSTALL_PREFIX} ${PYTHON_INCLUDE_DIRS})
-endif()
-
-if(PYBIND11_INSTALL)
-  install(DIRECTORY ${pybind11_INCLUDE_DIR}/pybind11 DESTINATION ${CMAKE_INSTALL_INCLUDEDIR})
-  set(PYBIND11_CMAKECONFIG_INSTALL_DIR
-      "${CMAKE_INSTALL_DATAROOTDIR}/cmake/${PROJECT_NAME}"
-      CACHE STRING "install path for pybind11Config.cmake")
-
-  if(IS_ABSOLUTE "${CMAKE_INSTALL_INCLUDEDIR}")
-    set(pybind11_INCLUDEDIR "${CMAKE_INSTALL_FULL_INCLUDEDIR}")
-  else()
-    set(pybind11_INCLUDEDIR "\$\{PACKAGE_PREFIX_DIR\}/${CMAKE_INSTALL_INCLUDEDIR}")
-  endif()
-
-  configure_package_config_file(
-    tools/${PROJECT_NAME}Config.cmake.in "${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}Config.cmake"
-    INSTALL_DESTINATION ${PYBIND11_CMAKECONFIG_INSTALL_DIR})
-
-  if(CMAKE_VERSION VERSION_LESS 3.14)
-    # Remove CMAKE_SIZEOF_VOID_P from ConfigVersion.cmake since the library does
-    # not depend on architecture specific settings or libraries.
-    set(_PYBIND11_CMAKE_SIZEOF_VOID_P ${CMAKE_SIZEOF_VOID_P})
-    unset(CMAKE_SIZEOF_VOID_P)
-
-    write_basic_package_version_file(
-      ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}ConfigVersion.cmake
-      VERSION ${PROJECT_VERSION}
-      COMPATIBILITY AnyNewerVersion)
-
-    set(CMAKE_SIZEOF_VOID_P ${_PYBIND11_CMAKE_SIZEOF_VOID_P})
-  else()
-    # CMake 3.14+ natively supports header-only libraries
-    write_basic_package_version_file(
-      ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}ConfigVersion.cmake
-      VERSION ${PROJECT_VERSION}
-      COMPATIBILITY AnyNewerVersion ARCH_INDEPENDENT)
-  endif()
-
-  install(
-    FILES ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}Config.cmake
-          ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}ConfigVersion.cmake
-          tools/FindPythonLibsNew.cmake
-          tools/pybind11Common.cmake
-          tools/pybind11Tools.cmake
-          tools/pybind11NewTools.cmake
-    DESTINATION ${PYBIND11_CMAKECONFIG_INSTALL_DIR})
-
-  if(NOT PYBIND11_EXPORT_NAME)
-    set(PYBIND11_EXPORT_NAME "${PROJECT_NAME}Targets")
-  endif()
-
-  install(TARGETS pybind11_headers EXPORT "${PYBIND11_EXPORT_NAME}")
-
-  install(
-    EXPORT "${PYBIND11_EXPORT_NAME}"
-    NAMESPACE "pybind11::"
-    DESTINATION ${PYBIND11_CMAKECONFIG_INSTALL_DIR})
-
-  # pkg-config support
-  if(NOT prefix_for_pc_file)
-    if(IS_ABSOLUTE "${CMAKE_INSTALL_DATAROOTDIR}")
-      set(prefix_for_pc_file "${CMAKE_INSTALL_PREFIX}")
-    else()
-      set(pc_datarootdir "${CMAKE_INSTALL_DATAROOTDIR}")
-      if(CMAKE_VERSION VERSION_LESS 3.20)
-        set(prefix_for_pc_file "\${pcfiledir}/..")
-        while(pc_datarootdir)
-          get_filename_component(pc_datarootdir "${pc_datarootdir}" DIRECTORY)
-          string(APPEND prefix_for_pc_file "/..")
-        endwhile()
-      else()
-        cmake_path(RELATIVE_PATH CMAKE_INSTALL_PREFIX BASE_DIRECTORY CMAKE_INSTALL_DATAROOTDIR
-                   OUTPUT_VARIABLE prefix_for_pc_file)
-      endif()
-    endif()
-  endif()
-  join_paths(includedir_for_pc_file "\${prefix}" "${CMAKE_INSTALL_INCLUDEDIR}")
-  configure_file("${CMAKE_CURRENT_SOURCE_DIR}/tools/pybind11.pc.in"
-                 "${CMAKE_CURRENT_BINARY_DIR}/pybind11.pc" @ONLY)
-  install(FILES "${CMAKE_CURRENT_BINARY_DIR}/pybind11.pc"
-          DESTINATION "${CMAKE_INSTALL_DATAROOTDIR}/pkgconfig/")
-
-  # Uninstall target
-  if(PYBIND11_MASTER_PROJECT)
-    configure_file("${CMAKE_CURRENT_SOURCE_DIR}/tools/cmake_uninstall.cmake.in"
-                   "${CMAKE_CURRENT_BINARY_DIR}/cmake_uninstall.cmake" IMMEDIATE @ONLY)
-
-    add_custom_target(uninstall COMMAND ${CMAKE_COMMAND} -P
-                                        ${CMAKE_CURRENT_BINARY_DIR}/cmake_uninstall.cmake)
-  endif()
-endif()
-
-# BUILD_TESTING takes priority, but only if this is the master project
-if(PYBIND11_MASTER_PROJECT AND DEFINED BUILD_TESTING)
-  if(BUILD_TESTING)
-    if(_pybind11_nopython)
-      message(FATAL_ERROR "Cannot activate tests in NOPYTHON mode")
-    else()
-      add_subdirectory(tests)
-    endif()
-  endif()
-else()
-  if(PYBIND11_TEST)
-    if(_pybind11_nopython)
-      message(FATAL_ERROR "Cannot activate tests in NOPYTHON mode")
-    else()
-      add_subdirectory(tests)
-    endif()
-  endif()
-endif()
-
-# Better symmetry with find_package(pybind11 CONFIG) mode.
-if(NOT PYBIND11_MASTER_PROJECT)
-  set(pybind11_FOUND
-      TRUE
-      CACHE INTERNAL "True if pybind11 and all required components found on the system")
-endif()
+# CMakeLists.txt -- Build system for the pybind11 modules
+#
+# Copyright (c) 2015 Wenzel Jakob <wenzel@inf.ethz.ch>
+#
+# All rights reserved. Use of this source code is governed by a
+# BSD-style license that can be found in the LICENSE file.
+
+# Propagate this policy (FindPythonInterp removal) so it can be detected later
+if(NOT CMAKE_VERSION VERSION_LESS "3.27")
+  cmake_policy(GET CMP0148 _pybind11_cmp0148)
+endif()
+
+cmake_minimum_required(VERSION 3.5)
+
+# The `cmake_minimum_required(VERSION 3.5...3.27)` syntax does not work with
+# some versions of VS that have a patched CMake 3.11. This forces us to emulate
+# the behavior using the following workaround:
+if(${CMAKE_VERSION} VERSION_LESS 3.27)
+  cmake_policy(VERSION ${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION})
+else()
+  cmake_policy(VERSION 3.27)
+endif()
+
+if(_pybind11_cmp0148)
+  cmake_policy(SET CMP0148 ${_pybind11_cmp0148})
+  unset(_pybind11_cmp0148)
+endif()
+
+# Avoid infinite recursion if tests include this as a subdirectory
+if(DEFINED PYBIND11_MASTER_PROJECT)
+  return()
+endif()
+
+# Extract project version from source
+file(STRINGS "${CMAKE_CURRENT_SOURCE_DIR}/include/pybind11/detail/common.h"
+     pybind11_version_defines REGEX "#define PYBIND11_VERSION_(MAJOR|MINOR|PATCH) ")
+
+foreach(ver ${pybind11_version_defines})
+  if(ver MATCHES [[#define PYBIND11_VERSION_(MAJOR|MINOR|PATCH) +([^ ]+)$]])
+    set(PYBIND11_VERSION_${CMAKE_MATCH_1} "${CMAKE_MATCH_2}")
+  endif()
+endforeach()
+
+if(PYBIND11_VERSION_PATCH MATCHES [[\.([a-zA-Z0-9]+)$]])
+  set(pybind11_VERSION_TYPE "${CMAKE_MATCH_1}")
+endif()
+string(REGEX MATCH "^[0-9]+" PYBIND11_VERSION_PATCH "${PYBIND11_VERSION_PATCH}")
+
+project(
+  pybind11
+  LANGUAGES CXX
+  VERSION "${PYBIND11_VERSION_MAJOR}.${PYBIND11_VERSION_MINOR}.${PYBIND11_VERSION_PATCH}")
+
+# Standard includes
+include(GNUInstallDirs)
+include(CMakePackageConfigHelpers)
+include(CMakeDependentOption)
+
+if(NOT pybind11_FIND_QUIETLY)
+  message(STATUS "pybind11 v${pybind11_VERSION} ${pybind11_VERSION_TYPE}")
+endif()
+
+# Check if pybind11 is being used directly or via add_subdirectory
+if(CMAKE_SOURCE_DIR STREQUAL PROJECT_SOURCE_DIR)
+  ### Warn if not an out-of-source builds
+  if(CMAKE_CURRENT_SOURCE_DIR STREQUAL CMAKE_CURRENT_BINARY_DIR)
+    set(lines
+        "You are building in-place. If that is not what you intended to "
+        "do, you can clean the source directory with:\n"
+        "rm -r CMakeCache.txt CMakeFiles/ cmake_uninstall.cmake pybind11Config.cmake "
+        "pybind11ConfigVersion.cmake tests/CMakeFiles/\n")
+    message(AUTHOR_WARNING ${lines})
+  endif()
+
+  set(PYBIND11_MASTER_PROJECT ON)
+
+  if(OSX AND CMAKE_VERSION VERSION_LESS 3.7)
+    # Bug in macOS CMake < 3.7 is unable to download catch
+    message(WARNING "CMAKE 3.7+ needed on macOS to download catch, and newer HIGHLY recommended")
+  elseif(WINDOWS AND CMAKE_VERSION VERSION_LESS 3.8)
+    # Only tested with 3.8+ in CI.
+    message(WARNING "CMAKE 3.8+ tested on Windows, previous versions untested")
+  endif()
+
+  message(STATUS "CMake ${CMAKE_VERSION}")
+
+  if(CMAKE_CXX_STANDARD)
+    set(CMAKE_CXX_EXTENSIONS OFF)
+    set(CMAKE_CXX_STANDARD_REQUIRED ON)
+  endif()
+
+  set(pybind11_system "")
+
+  set_property(GLOBAL PROPERTY USE_FOLDERS ON)
+  if(CMAKE_VERSION VERSION_LESS "3.18")
+    set(_pybind11_findpython_default OFF)
+  else()
+    set(_pybind11_findpython_default ON)
+  endif()
+else()
+  set(PYBIND11_MASTER_PROJECT OFF)
+  set(pybind11_system SYSTEM)
+  set(_pybind11_findpython_default OFF)
+endif()
+
+# Options
+option(PYBIND11_INSTALL "Install pybind11 header files?" ${PYBIND11_MASTER_PROJECT})
+option(PYBIND11_TEST "Build pybind11 test suite?" ${PYBIND11_MASTER_PROJECT})
+option(PYBIND11_NOPYTHON "Disable search for Python" OFF)
+option(PYBIND11_DISABLE_HANDLE_TYPE_NAME_DEFAULT_IMPLEMENTATION
+       "To enforce that a handle_type_name<> specialization exists" OFF)
+option(PYBIND11_SIMPLE_GIL_MANAGEMENT
+       "Use simpler GIL management logic that does not support disassociation" OFF)
+option(PYBIND11_NUMPY_1_ONLY
+       "Disable NumPy 2 support to avoid changes to previous pybind11 versions." OFF)
+set(PYBIND11_INTERNALS_VERSION
+    ""
+    CACHE STRING "Override the ABI version, may be used to enable the unstable ABI.")
+
+if(PYBIND11_DISABLE_HANDLE_TYPE_NAME_DEFAULT_IMPLEMENTATION)
+  add_compile_definitions(PYBIND11_DISABLE_HANDLE_TYPE_NAME_DEFAULT_IMPLEMENTATION)
+endif()
+if(PYBIND11_SIMPLE_GIL_MANAGEMENT)
+  add_compile_definitions(PYBIND11_SIMPLE_GIL_MANAGEMENT)
+endif()
+if(PYBIND11_NUMPY_1_ONLY)
+  add_compile_definitions(PYBIND11_NUMPY_1_ONLY)
+endif()
+
+cmake_dependent_option(
+  USE_PYTHON_INCLUDE_DIR
+  "Install pybind11 headers in Python include directory instead of default installation prefix"
+  OFF "PYBIND11_INSTALL" OFF)
+
+cmake_dependent_option(PYBIND11_FINDPYTHON "Force new FindPython" ${_pybind11_findpython_default}
+                       "NOT CMAKE_VERSION VERSION_LESS 3.12" OFF)
+
+# Allow PYTHON_EXECUTABLE if in FINDPYTHON mode and building pybind11's tests
+# (makes transition easier while we support both modes).
+if(PYBIND11_MASTER_PROJECT
+   AND PYBIND11_FINDPYTHON
+   AND DEFINED PYTHON_EXECUTABLE
+   AND NOT DEFINED Python_EXECUTABLE)
+  set(Python_EXECUTABLE "${PYTHON_EXECUTABLE}")
+endif()
+
+# NB: when adding a header don't forget to also add it to setup.py
+set(PYBIND11_HEADERS
+    include/pybind11/detail/class.h
+    include/pybind11/detail/common.h
+    include/pybind11/detail/descr.h
+    include/pybind11/detail/init.h
+    include/pybind11/detail/internals.h
+    include/pybind11/detail/type_caster_base.h
+    include/pybind11/detail/typeid.h
+    include/pybind11/attr.h
+    include/pybind11/buffer_info.h
+    include/pybind11/cast.h
+    include/pybind11/chrono.h
+    include/pybind11/common.h
+    include/pybind11/complex.h
+    include/pybind11/options.h
+    include/pybind11/eigen.h
+    include/pybind11/eigen/common.h
+    include/pybind11/eigen/matrix.h
+    include/pybind11/eigen/tensor.h
+    include/pybind11/embed.h
+    include/pybind11/eval.h
+    include/pybind11/gil.h
+    include/pybind11/gil_safe_call_once.h
+    include/pybind11/iostream.h
+    include/pybind11/functional.h
+    include/pybind11/numpy.h
+    include/pybind11/operators.h
+    include/pybind11/pybind11.h
+    include/pybind11/pytypes.h
+    include/pybind11/stl.h
+    include/pybind11/stl_bind.h
+    include/pybind11/stl/filesystem.h
+    include/pybind11/type_caster_pyobject_ptr.h
+    include/pybind11/typing.h)
+
+# Compare with grep and warn if mismatched
+if(PYBIND11_MASTER_PROJECT AND NOT CMAKE_VERSION VERSION_LESS 3.12)
+  file(
+    GLOB_RECURSE _pybind11_header_check
+    LIST_DIRECTORIES false
+    RELATIVE "${CMAKE_CURRENT_SOURCE_DIR}"
+    CONFIGURE_DEPENDS "include/pybind11/*.h")
+  set(_pybind11_here_only ${PYBIND11_HEADERS})
+  set(_pybind11_disk_only ${_pybind11_header_check})
+  list(REMOVE_ITEM _pybind11_here_only ${_pybind11_header_check})
+  list(REMOVE_ITEM _pybind11_disk_only ${PYBIND11_HEADERS})
+  if(_pybind11_here_only)
+    message(AUTHOR_WARNING "PYBIND11_HEADERS has extra files:" ${_pybind11_here_only})
+  endif()
+  if(_pybind11_disk_only)
+    message(AUTHOR_WARNING "PYBIND11_HEADERS is missing files:" ${_pybind11_disk_only})
+  endif()
+endif()
+
+# CMake 3.12 added list(TRANSFORM <list> PREPEND
+# But we can't use it yet
+string(REPLACE "include/" "${CMAKE_CURRENT_SOURCE_DIR}/include/" PYBIND11_HEADERS
+               "${PYBIND11_HEADERS}")
+
+# Cache variable so this can be used in parent projects
+set(pybind11_INCLUDE_DIR
+    "${CMAKE_CURRENT_LIST_DIR}/include"
+    CACHE INTERNAL "Directory where pybind11 headers are located")
+
+# Backward compatible variable for add_subdirectory mode
+if(NOT PYBIND11_MASTER_PROJECT)
+  set(PYBIND11_INCLUDE_DIR
+      "${pybind11_INCLUDE_DIR}"
+      CACHE INTERNAL "")
+endif()
+
+# Note: when creating targets, you cannot use if statements at configure time -
+# you need generator expressions, because those will be placed in the target file.
+# You can also place ifs *in* the Config.in, but not here.
+
+# This section builds targets, but does *not* touch Python
+# Non-IMPORT targets cannot be defined twice
+if(NOT TARGET pybind11_headers)
+  # Build the headers-only target (no Python included):
+  # (long name used here to keep this from clashing in subdirectory mode)
+  add_library(pybind11_headers INTERFACE)
+  add_library(pybind11::pybind11_headers ALIAS pybind11_headers) # to match exported target
+  add_library(pybind11::headers ALIAS pybind11_headers) # easier to use/remember
+
+  target_include_directories(
+    pybind11_headers ${pybind11_system} INTERFACE $<BUILD_INTERFACE:${pybind11_INCLUDE_DIR}>
+                                                  $<INSTALL_INTERFACE:${CMAKE_INSTALL_INCLUDEDIR}>)
+
+  target_compile_features(pybind11_headers INTERFACE cxx_inheriting_constructors cxx_user_literals
+                                                     cxx_right_angle_brackets)
+  if(NOT "${PYBIND11_INTERNALS_VERSION}" STREQUAL "")
+    target_compile_definitions(
+      pybind11_headers INTERFACE "PYBIND11_INTERNALS_VERSION=${PYBIND11_INTERNALS_VERSION}")
+  endif()
+else()
+  # It is invalid to install a target twice, too.
+  set(PYBIND11_INSTALL OFF)
+endif()
+
+include("${CMAKE_CURRENT_SOURCE_DIR}/tools/pybind11Common.cmake")
+# https://github.com/jtojnar/cmake-snips/#concatenating-paths-when-building-pkg-config-files
+# TODO: cmake 3.20 adds the cmake_path() function, which obsoletes this snippet
+include("${CMAKE_CURRENT_SOURCE_DIR}/tools/JoinPaths.cmake")
+
+# Relative directory setting
+if(USE_PYTHON_INCLUDE_DIR AND DEFINED Python_INCLUDE_DIRS)
+  file(RELATIVE_PATH CMAKE_INSTALL_INCLUDEDIR ${CMAKE_INSTALL_PREFIX} ${Python_INCLUDE_DIRS})
+elseif(USE_PYTHON_INCLUDE_DIR AND DEFINED PYTHON_INCLUDE_DIR)
+  file(RELATIVE_PATH CMAKE_INSTALL_INCLUDEDIR ${CMAKE_INSTALL_PREFIX} ${PYTHON_INCLUDE_DIRS})
+endif()
+
+if(PYBIND11_INSTALL)
+  install(DIRECTORY ${pybind11_INCLUDE_DIR}/pybind11 DESTINATION ${CMAKE_INSTALL_INCLUDEDIR})
+  set(PYBIND11_CMAKECONFIG_INSTALL_DIR
+      "${CMAKE_INSTALL_DATAROOTDIR}/cmake/${PROJECT_NAME}"
+      CACHE STRING "install path for pybind11Config.cmake")
+
+  if(IS_ABSOLUTE "${CMAKE_INSTALL_INCLUDEDIR}")
+    set(pybind11_INCLUDEDIR "${CMAKE_INSTALL_FULL_INCLUDEDIR}")
+  else()
+    set(pybind11_INCLUDEDIR "\$\{PACKAGE_PREFIX_DIR\}/${CMAKE_INSTALL_INCLUDEDIR}")
+  endif()
+
+  configure_package_config_file(
+    tools/${PROJECT_NAME}Config.cmake.in "${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}Config.cmake"
+    INSTALL_DESTINATION ${PYBIND11_CMAKECONFIG_INSTALL_DIR})
+
+  if(CMAKE_VERSION VERSION_LESS 3.14)
+    # Remove CMAKE_SIZEOF_VOID_P from ConfigVersion.cmake since the library does
+    # not depend on architecture specific settings or libraries.
+    set(_PYBIND11_CMAKE_SIZEOF_VOID_P ${CMAKE_SIZEOF_VOID_P})
+    unset(CMAKE_SIZEOF_VOID_P)
+
+    write_basic_package_version_file(
+      ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}ConfigVersion.cmake
+      VERSION ${PROJECT_VERSION}
+      COMPATIBILITY AnyNewerVersion)
+
+    set(CMAKE_SIZEOF_VOID_P ${_PYBIND11_CMAKE_SIZEOF_VOID_P})
+  else()
+    # CMake 3.14+ natively supports header-only libraries
+    write_basic_package_version_file(
+      ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}ConfigVersion.cmake
+      VERSION ${PROJECT_VERSION}
+      COMPATIBILITY AnyNewerVersion ARCH_INDEPENDENT)
+  endif()
+
+  install(
+    FILES ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}Config.cmake
+          ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}ConfigVersion.cmake
+          tools/FindPythonLibsNew.cmake
+          tools/pybind11Common.cmake
+          tools/pybind11Tools.cmake
+          tools/pybind11NewTools.cmake
+    DESTINATION ${PYBIND11_CMAKECONFIG_INSTALL_DIR})
+
+  if(NOT PYBIND11_EXPORT_NAME)
+    set(PYBIND11_EXPORT_NAME "${PROJECT_NAME}Targets")
+  endif()
+
+  install(TARGETS pybind11_headers EXPORT "${PYBIND11_EXPORT_NAME}")
+
+  install(
+    EXPORT "${PYBIND11_EXPORT_NAME}"
+    NAMESPACE "pybind11::"
+    DESTINATION ${PYBIND11_CMAKECONFIG_INSTALL_DIR})
+
+  # pkg-config support
+  if(NOT prefix_for_pc_file)
+    if(IS_ABSOLUTE "${CMAKE_INSTALL_DATAROOTDIR}")
+      set(prefix_for_pc_file "${CMAKE_INSTALL_PREFIX}")
+    else()
+      set(pc_datarootdir "${CMAKE_INSTALL_DATAROOTDIR}")
+      if(CMAKE_VERSION VERSION_LESS 3.20)
+        set(prefix_for_pc_file "\${pcfiledir}/..")
+        while(pc_datarootdir)
+          get_filename_component(pc_datarootdir "${pc_datarootdir}" DIRECTORY)
+          string(APPEND prefix_for_pc_file "/..")
+        endwhile()
+      else()
+        cmake_path(RELATIVE_PATH CMAKE_INSTALL_PREFIX BASE_DIRECTORY CMAKE_INSTALL_DATAROOTDIR
+                   OUTPUT_VARIABLE prefix_for_pc_file)
+      endif()
+    endif()
+  endif()
+  join_paths(includedir_for_pc_file "\${prefix}" "${CMAKE_INSTALL_INCLUDEDIR}")
+  configure_file("${CMAKE_CURRENT_SOURCE_DIR}/tools/pybind11.pc.in"
+                 "${CMAKE_CURRENT_BINARY_DIR}/pybind11.pc" @ONLY)
+  install(FILES "${CMAKE_CURRENT_BINARY_DIR}/pybind11.pc"
+          DESTINATION "${CMAKE_INSTALL_DATAROOTDIR}/pkgconfig/")
+
+  # Uninstall target
+  if(PYBIND11_MASTER_PROJECT)
+    configure_file("${CMAKE_CURRENT_SOURCE_DIR}/tools/cmake_uninstall.cmake.in"
+                   "${CMAKE_CURRENT_BINARY_DIR}/cmake_uninstall.cmake" IMMEDIATE @ONLY)
+
+    add_custom_target(uninstall COMMAND ${CMAKE_COMMAND} -P
+                                        ${CMAKE_CURRENT_BINARY_DIR}/cmake_uninstall.cmake)
+  endif()
+endif()
+
+# BUILD_TESTING takes priority, but only if this is the master project
+if(PYBIND11_MASTER_PROJECT AND DEFINED BUILD_TESTING)
+  if(BUILD_TESTING)
+    if(_pybind11_nopython)
+      message(FATAL_ERROR "Cannot activate tests in NOPYTHON mode")
+    else()
+      add_subdirectory(tests)
+    endif()
+  endif()
+else()
+  if(PYBIND11_TEST)
+    if(_pybind11_nopython)
+      message(FATAL_ERROR "Cannot activate tests in NOPYTHON mode")
+    else()
+      add_subdirectory(tests)
+    endif()
+  endif()
+endif()
+
+# Better symmetry with find_package(pybind11 CONFIG) mode.
+if(NOT PYBIND11_MASTER_PROJECT)
+  set(pybind11_FOUND
+      TRUE
+      CACHE INTERNAL "True if pybind11 and all required components found on the system")
+endif()

third_party/CityFlow/extern/pybind11/LICENSE

@@ -1,29 +1,29 @@
-Copyright (c) 2016 Wenzel Jakob <wenzel.jakob@epfl.ch>, All rights reserved.
-
-Redistribution and use in source and binary forms, with or without
-modification, are permitted provided that the following conditions are met:
-
-1. Redistributions of source code must retain the above copyright notice, this
-   list of conditions and the following disclaimer.
-
-2. Redistributions in binary form must reproduce the above copyright notice,
-   this list of conditions and the following disclaimer in the documentation
-   and/or other materials provided with the distribution.
-
-3. Neither the name of the copyright holder nor the names of its contributors
-   may be used to endorse or promote products derived from this software
-   without specific prior written permission.
-
-THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
-ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
-WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
-DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
-FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
-DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
-SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
-CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
-OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
-OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-
-Please also refer to the file .github/CONTRIBUTING.md, which clarifies licensing of
-external contributions to this project including patches, pull requests, etc.
+Copyright (c) 2016 Wenzel Jakob <wenzel.jakob@epfl.ch>, All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions are met:
+
+1. Redistributions of source code must retain the above copyright notice, this
+   list of conditions and the following disclaimer.
+
+2. Redistributions in binary form must reproduce the above copyright notice,
+   this list of conditions and the following disclaimer in the documentation
+   and/or other materials provided with the distribution.
+
+3. Neither the name of the copyright holder nor the names of its contributors
+   may be used to endorse or promote products derived from this software
+   without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
+ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
+FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
+OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+Please also refer to the file .github/CONTRIBUTING.md, which clarifies licensing of
+external contributions to this project including patches, pull requests, etc.

third_party/CityFlow/extern/pybind11/MANIFEST.in

@@ -1,6 +1,6 @@
-prune tests
-recursive-include pybind11/include/pybind11 *.h
-recursive-include pybind11 *.py
-recursive-include pybind11 py.typed
-include pybind11/share/cmake/pybind11/*.cmake
-include LICENSE README.rst SECURITY.md pyproject.toml setup.py setup.cfg
+prune tests
+recursive-include pybind11/include/pybind11 *.h
+recursive-include pybind11 *.py
+recursive-include pybind11 py.typed
+include pybind11/share/cmake/pybind11/*.cmake
+include LICENSE README.rst SECURITY.md pyproject.toml setup.py setup.cfg

third_party/CityFlow/extern/pybind11/README.rst

@@ -1,181 +1,181 @@
-.. figure:: https://github.com/pybind/pybind11/raw/master/docs/pybind11-logo.png
-   :alt: pybind11 logo
-
-**pybind11 — Seamless operability between C++11 and Python**
-
-|Latest Documentation Status| |Stable Documentation Status| |Gitter chat| |GitHub Discussions| |CI| |Build status|
-
-|Repology| |PyPI package| |Conda-forge| |Python Versions|
-
-`Setuptools example <https://github.com/pybind/python_example>`_
-• `Scikit-build example <https://github.com/pybind/scikit_build_example>`_
-• `CMake example <https://github.com/pybind/cmake_example>`_
-
-.. start
-
-
-**pybind11** is a lightweight header-only library that exposes C++ types
-in Python and vice versa, mainly to create Python bindings of existing
-C++ code. Its goals and syntax are similar to the excellent
-`Boost.Python <http://www.boost.org/doc/libs/1_58_0/libs/python/doc/>`_
-library by David Abrahams: to minimize boilerplate code in traditional
-extension modules by inferring type information using compile-time
-introspection.
-
-The main issue with Boost.Python—and the reason for creating such a
-similar project—is Boost. Boost is an enormously large and complex suite
-of utility libraries that works with almost every C++ compiler in
-existence. This compatibility has its cost: arcane template tricks and
-workarounds are necessary to support the oldest and buggiest of compiler
-specimens. Now that C++11-compatible compilers are widely available,
-this heavy machinery has become an excessively large and unnecessary
-dependency.
-
-Think of this library as a tiny self-contained version of Boost.Python
-with everything stripped away that isn't relevant for binding
-generation. Without comments, the core header files only require ~4K
-lines of code and depend on Python (3.6+, or PyPy) and the C++
-standard library. This compact implementation was possible thanks to
-some C++11 language features (specifically: tuples, lambda functions and
-variadic templates). Since its creation, this library has grown beyond
-Boost.Python in many ways, leading to dramatically simpler binding code in many
-common situations.
-
-Tutorial and reference documentation is provided at
-`pybind11.readthedocs.io <https://pybind11.readthedocs.io/en/latest>`_.
-A PDF version of the manual is available
-`here <https://pybind11.readthedocs.io/_/downloads/en/latest/pdf/>`_.
-And the source code is always available at
-`github.com/pybind/pybind11 <https://github.com/pybind/pybind11>`_.
-
-
-Core features
--------------
-
-
-pybind11 can map the following core C++ features to Python:
-
-- Functions accepting and returning custom data structures per value,
-  reference, or pointer
-- Instance methods and static methods
-- Overloaded functions
-- Instance attributes and static attributes
-- Arbitrary exception types
-- Enumerations
-- Callbacks
-- Iterators and ranges
-- Custom operators
-- Single and multiple inheritance
-- STL data structures
-- Smart pointers with reference counting like ``std::shared_ptr``
-- Internal references with correct reference counting
-- C++ classes with virtual (and pure virtual) methods can be extended
-  in Python
-- Integrated NumPy support (NumPy 2 requires pybind11 2.12+)
-
-Goodies
--------
-
-In addition to the core functionality, pybind11 provides some extra
-goodies:
-
-- Python 3.6+, and PyPy3 7.3 are supported with an implementation-agnostic
-  interface (pybind11 2.9 was the last version to support Python 2 and 3.5).
-
-- It is possible to bind C++11 lambda functions with captured
-  variables. The lambda capture data is stored inside the resulting
-  Python function object.
-
-- pybind11 uses C++11 move constructors and move assignment operators
-  whenever possible to efficiently transfer custom data types.
-
-- It's easy to expose the internal storage of custom data types through
-  Pythons' buffer protocols. This is handy e.g. for fast conversion
-  between C++ matrix classes like Eigen and NumPy without expensive
-  copy operations.
-
-- pybind11 can automatically vectorize functions so that they are
-  transparently applied to all entries of one or more NumPy array
-  arguments.
-
-- Python's slice-based access and assignment operations can be
-  supported with just a few lines of code.
-
-- Everything is contained in just a few header files; there is no need
-  to link against any additional libraries.
-
-- Binaries are generally smaller by a factor of at least 2 compared to
-  equivalent bindings generated by Boost.Python. A recent pybind11
-  conversion of PyRosetta, an enormous Boost.Python binding project,
-  `reported <https://graylab.jhu.edu/Sergey/2016.RosettaCon/PyRosetta-4.pdf>`_
-  a binary size reduction of **5.4x** and compile time reduction by
-  **5.8x**.
-
-- Function signatures are precomputed at compile time (using
-  ``constexpr``), leading to smaller binaries.
-
-- With little extra effort, C++ types can be pickled and unpickled
-  similar to regular Python objects.
-
-Supported compilers
--------------------
-
-1. Clang/LLVM 3.3 or newer (for Apple Xcode's clang, this is 5.0.0 or
-   newer)
-2. GCC 4.8 or newer
-3. Microsoft Visual Studio 2017 or newer
-4. Intel classic C++ compiler 18 or newer (ICC 20.2 tested in CI)
-5. Cygwin/GCC (previously tested on 2.5.1)
-6. NVCC (CUDA 11.0 tested in CI)
-7. NVIDIA PGI (20.9 tested in CI)
-
-About
------
-
-This project was created by `Wenzel
-Jakob <http://rgl.epfl.ch/people/wjakob>`_. Significant features and/or
-improvements to the code were contributed by Jonas Adler, Lori A. Burns,
-Sylvain Corlay, Eric Cousineau, Aaron Gokaslan, Ralf Grosse-Kunstleve, Trent Houliston, Axel
-Huebl, @hulucc, Yannick Jadoul, Sergey Lyskov, Johan Mabille, Tomasz Miąsko,
-Dean Moldovan, Ben Pritchard, Jason Rhinelander, Boris Schäling, Pim
-Schellart, Henry Schreiner, Ivan Smirnov, Boris Staletic, and Patrick Stewart.
-
-We thank Google for a generous financial contribution to the continuous
-integration infrastructure used by this project.
-
-
-Contributing
-~~~~~~~~~~~~
-
-See the `contributing
-guide <https://github.com/pybind/pybind11/blob/master/.github/CONTRIBUTING.md>`_
-for information on building and contributing to pybind11.
-
-License
-~~~~~~~
-
-pybind11 is provided under a BSD-style license that can be found in the
-`LICENSE <https://github.com/pybind/pybind11/blob/master/LICENSE>`_
-file. By using, distributing, or contributing to this project, you agree
-to the terms and conditions of this license.
-
-.. |Latest Documentation Status| image:: https://readthedocs.org/projects/pybind11/badge?version=latest
-   :target: http://pybind11.readthedocs.org/en/latest
-.. |Stable Documentation Status| image:: https://img.shields.io/badge/docs-stable-blue.svg
-   :target: http://pybind11.readthedocs.org/en/stable
-.. |Gitter chat| image:: https://img.shields.io/gitter/room/gitterHQ/gitter.svg
-   :target: https://gitter.im/pybind/Lobby
-.. |CI| image:: https://github.com/pybind/pybind11/workflows/CI/badge.svg
-   :target: https://github.com/pybind/pybind11/actions
-.. |Build status| image:: https://ci.appveyor.com/api/projects/status/riaj54pn4h08xy40?svg=true
-   :target: https://ci.appveyor.com/project/wjakob/pybind11
-.. |PyPI package| image:: https://img.shields.io/pypi/v/pybind11.svg
-   :target: https://pypi.org/project/pybind11/
-.. |Conda-forge| image:: https://img.shields.io/conda/vn/conda-forge/pybind11.svg
-   :target: https://github.com/conda-forge/pybind11-feedstock
-.. |Repology| image:: https://repology.org/badge/latest-versions/python:pybind11.svg
-   :target: https://repology.org/project/python:pybind11/versions
-.. |Python Versions| image:: https://img.shields.io/pypi/pyversions/pybind11.svg
-   :target: https://pypi.org/project/pybind11/
-.. |GitHub Discussions| image:: https://img.shields.io/static/v1?label=Discussions&message=Ask&color=blue&logo=github
-   :target: https://github.com/pybind/pybind11/discussions
+.. figure:: https://github.com/pybind/pybind11/raw/master/docs/pybind11-logo.png
+   :alt: pybind11 logo
+
+**pybind11 — Seamless operability between C++11 and Python**
+
+|Latest Documentation Status| |Stable Documentation Status| |Gitter chat| |GitHub Discussions| |CI| |Build status|
+
+|Repology| |PyPI package| |Conda-forge| |Python Versions|
+
+`Setuptools example <https://github.com/pybind/python_example>`_
+• `Scikit-build example <https://github.com/pybind/scikit_build_example>`_
+• `CMake example <https://github.com/pybind/cmake_example>`_
+
+.. start
+
+
+**pybind11** is a lightweight header-only library that exposes C++ types
+in Python and vice versa, mainly to create Python bindings of existing
+C++ code. Its goals and syntax are similar to the excellent
+`Boost.Python <http://www.boost.org/doc/libs/1_58_0/libs/python/doc/>`_
+library by David Abrahams: to minimize boilerplate code in traditional
+extension modules by inferring type information using compile-time
+introspection.
+
+The main issue with Boost.Python—and the reason for creating such a
+similar project—is Boost. Boost is an enormously large and complex suite
+of utility libraries that works with almost every C++ compiler in
+existence. This compatibility has its cost: arcane template tricks and
+workarounds are necessary to support the oldest and buggiest of compiler
+specimens. Now that C++11-compatible compilers are widely available,
+this heavy machinery has become an excessively large and unnecessary
+dependency.
+
+Think of this library as a tiny self-contained version of Boost.Python
+with everything stripped away that isn't relevant for binding
+generation. Without comments, the core header files only require ~4K
+lines of code and depend on Python (3.6+, or PyPy) and the C++
+standard library. This compact implementation was possible thanks to
+some C++11 language features (specifically: tuples, lambda functions and
+variadic templates). Since its creation, this library has grown beyond
+Boost.Python in many ways, leading to dramatically simpler binding code in many
+common situations.
+
+Tutorial and reference documentation is provided at
+`pybind11.readthedocs.io <https://pybind11.readthedocs.io/en/latest>`_.
+A PDF version of the manual is available
+`here <https://pybind11.readthedocs.io/_/downloads/en/latest/pdf/>`_.
+And the source code is always available at
+`github.com/pybind/pybind11 <https://github.com/pybind/pybind11>`_.
+
+
+Core features
+-------------
+
+
+pybind11 can map the following core C++ features to Python:
+
+- Functions accepting and returning custom data structures per value,
+  reference, or pointer
+- Instance methods and static methods
+- Overloaded functions
+- Instance attributes and static attributes
+- Arbitrary exception types
+- Enumerations
+- Callbacks
+- Iterators and ranges
+- Custom operators
+- Single and multiple inheritance
+- STL data structures
+- Smart pointers with reference counting like ``std::shared_ptr``
+- Internal references with correct reference counting
+- C++ classes with virtual (and pure virtual) methods can be extended
+  in Python
+- Integrated NumPy support (NumPy 2 requires pybind11 2.12+)
+
+Goodies
+-------
+
+In addition to the core functionality, pybind11 provides some extra
+goodies:
+
+- Python 3.6+, and PyPy3 7.3 are supported with an implementation-agnostic
+  interface (pybind11 2.9 was the last version to support Python 2 and 3.5).
+
+- It is possible to bind C++11 lambda functions with captured
+  variables. The lambda capture data is stored inside the resulting
+  Python function object.
+
+- pybind11 uses C++11 move constructors and move assignment operators
+  whenever possible to efficiently transfer custom data types.
+
+- It's easy to expose the internal storage of custom data types through
+  Pythons' buffer protocols. This is handy e.g. for fast conversion
+  between C++ matrix classes like Eigen and NumPy without expensive
+  copy operations.
+
+- pybind11 can automatically vectorize functions so that they are
+  transparently applied to all entries of one or more NumPy array
+  arguments.
+
+- Python's slice-based access and assignment operations can be
+  supported with just a few lines of code.
+
+- Everything is contained in just a few header files; there is no need
+  to link against any additional libraries.
+
+- Binaries are generally smaller by a factor of at least 2 compared to
+  equivalent bindings generated by Boost.Python. A recent pybind11
+  conversion of PyRosetta, an enormous Boost.Python binding project,
+  `reported <https://graylab.jhu.edu/Sergey/2016.RosettaCon/PyRosetta-4.pdf>`_
+  a binary size reduction of **5.4x** and compile time reduction by
+  **5.8x**.
+
+- Function signatures are precomputed at compile time (using
+  ``constexpr``), leading to smaller binaries.
+
+- With little extra effort, C++ types can be pickled and unpickled
+  similar to regular Python objects.
+
+Supported compilers
+-------------------
+
+1. Clang/LLVM 3.3 or newer (for Apple Xcode's clang, this is 5.0.0 or
+   newer)
+2. GCC 4.8 or newer
+3. Microsoft Visual Studio 2017 or newer
+4. Intel classic C++ compiler 18 or newer (ICC 20.2 tested in CI)
+5. Cygwin/GCC (previously tested on 2.5.1)
+6. NVCC (CUDA 11.0 tested in CI)
+7. NVIDIA PGI (20.9 tested in CI)
+
+About
+-----
+
+This project was created by `Wenzel
+Jakob <http://rgl.epfl.ch/people/wjakob>`_. Significant features and/or
+improvements to the code were contributed by Jonas Adler, Lori A. Burns,
+Sylvain Corlay, Eric Cousineau, Aaron Gokaslan, Ralf Grosse-Kunstleve, Trent Houliston, Axel
+Huebl, @hulucc, Yannick Jadoul, Sergey Lyskov, Johan Mabille, Tomasz Miąsko,
+Dean Moldovan, Ben Pritchard, Jason Rhinelander, Boris Schäling, Pim
+Schellart, Henry Schreiner, Ivan Smirnov, Boris Staletic, and Patrick Stewart.
+
+We thank Google for a generous financial contribution to the continuous
+integration infrastructure used by this project.
+
+
+Contributing
+~~~~~~~~~~~~
+
+See the `contributing
+guide <https://github.com/pybind/pybind11/blob/master/.github/CONTRIBUTING.md>`_
+for information on building and contributing to pybind11.
+
+License
+~~~~~~~
+
+pybind11 is provided under a BSD-style license that can be found in the
+`LICENSE <https://github.com/pybind/pybind11/blob/master/LICENSE>`_
+file. By using, distributing, or contributing to this project, you agree
+to the terms and conditions of this license.
+
+.. |Latest Documentation Status| image:: https://readthedocs.org/projects/pybind11/badge?version=latest
+   :target: http://pybind11.readthedocs.org/en/latest
+.. |Stable Documentation Status| image:: https://img.shields.io/badge/docs-stable-blue.svg
+   :target: http://pybind11.readthedocs.org/en/stable
+.. |Gitter chat| image:: https://img.shields.io/gitter/room/gitterHQ/gitter.svg
+   :target: https://gitter.im/pybind/Lobby
+.. |CI| image:: https://github.com/pybind/pybind11/workflows/CI/badge.svg
+   :target: https://github.com/pybind/pybind11/actions
+.. |Build status| image:: https://ci.appveyor.com/api/projects/status/riaj54pn4h08xy40?svg=true
+   :target: https://ci.appveyor.com/project/wjakob/pybind11
+.. |PyPI package| image:: https://img.shields.io/pypi/v/pybind11.svg
+   :target: https://pypi.org/project/pybind11/
+.. |Conda-forge| image:: https://img.shields.io/conda/vn/conda-forge/pybind11.svg
+   :target: https://github.com/conda-forge/pybind11-feedstock
+.. |Repology| image:: https://repology.org/badge/latest-versions/python:pybind11.svg
+   :target: https://repology.org/project/python:pybind11/versions
+.. |Python Versions| image:: https://img.shields.io/pypi/pyversions/pybind11.svg
+   :target: https://pypi.org/project/pybind11/
+.. |GitHub Discussions| image:: https://img.shields.io/static/v1?label=Discussions&message=Ask&color=blue&logo=github
+   :target: https://github.com/pybind/pybind11/discussions

third_party/CityFlow/extern/pybind11/SECURITY.md

@@ -1,13 +1,13 @@
-# Security Policy
-
-## Supported Versions
-
-Security updates are applied only to the latest release.
-
-## Reporting a Vulnerability
-
-If you have discovered a security vulnerability in this project, please report it privately. **Do not disclose it as a public issue.** This gives us time to work with you to fix the issue before public exposure, reducing the chance that the exploit will be used before a patch is released.
-
-Please disclose it at [security advisory](https://github.com/pybind/pybind11/security/advisories/new).
-
-This project is maintained by a team of volunteers on a reasonable-effort basis. As such, please give us at least 90 days to work on a fix before public exposure.
+# Security Policy
+
+## Supported Versions
+
+Security updates are applied only to the latest release.
+
+## Reporting a Vulnerability
+
+If you have discovered a security vulnerability in this project, please report it privately. **Do not disclose it as a public issue.** This gives us time to work with you to fix the issue before public exposure, reducing the chance that the exploit will be used before a patch is released.
+
+Please disclose it at [security advisory](https://github.com/pybind/pybind11/security/advisories/new).
+
+This project is maintained by a team of volunteers on a reasonable-effort basis. As such, please give us at least 90 days to work on a fix before public exposure.

third_party/CityFlow/extern/pybind11/docs/Doxyfile

@@ -1,21 +1,21 @@
-PROJECT_NAME           = pybind11
-INPUT                  = ../include/pybind11/
-RECURSIVE              = YES
-
-GENERATE_HTML          = NO
-GENERATE_LATEX         = NO
-GENERATE_XML           = YES
-XML_OUTPUT             = .build/doxygenxml
-XML_PROGRAMLISTING     = YES
-
-MACRO_EXPANSION        = YES
-EXPAND_ONLY_PREDEF     = YES
-EXPAND_AS_DEFINED      = PYBIND11_RUNTIME_EXCEPTION
-
-ALIASES                = "rst=\verbatim embed:rst"
-ALIASES               += "endrst=\endverbatim"
-
-QUIET                  = YES
-WARNINGS               = YES
-WARN_IF_UNDOCUMENTED   = NO
-PREDEFINED             = PYBIND11_NOINLINE
+PROJECT_NAME           = pybind11
+INPUT                  = ../include/pybind11/
+RECURSIVE              = YES
+
+GENERATE_HTML          = NO
+GENERATE_LATEX         = NO
+GENERATE_XML           = YES
+XML_OUTPUT             = .build/doxygenxml
+XML_PROGRAMLISTING     = YES
+
+MACRO_EXPANSION        = YES
+EXPAND_ONLY_PREDEF     = YES
+EXPAND_AS_DEFINED      = PYBIND11_RUNTIME_EXCEPTION
+
+ALIASES                = "rst=\verbatim embed:rst"
+ALIASES               += "endrst=\endverbatim"
+
+QUIET                  = YES
+WARNINGS               = YES
+WARN_IF_UNDOCUMENTED   = NO
+PREDEFINED             = PYBIND11_NOINLINE

third_party/CityFlow/extern/pybind11/docs/basics.rst

@@ -1,307 +1,307 @@
-.. _basics:
-
-First steps
-###########
-
-This sections demonstrates the basic features of pybind11. Before getting
-started, make sure that development environment is set up to compile the
-included set of test cases.
-
-
-Compiling the test cases
-========================
-
-Linux/macOS
------------
-
-On Linux  you'll need to install the **python-dev** or **python3-dev** packages as
-well as **cmake**. On macOS, the included python version works out of the box,
-but **cmake** must still be installed.
-
-After installing the prerequisites, run
-
-.. code-block:: bash
-
-   mkdir build
-   cd build
-   cmake ..
-   make check -j 4
-
-The last line will both compile and run the tests.
-
-Windows
--------
-
-On Windows, only **Visual Studio 2017** and newer are supported.
-
-.. Note::
-
-    To use the C++17 in Visual Studio 2017 (MSVC 14.1), pybind11 requires the flag
-    ``/permissive-`` to be passed to the compiler `to enforce standard conformance`_. When
-    building with Visual Studio 2019, this is not strictly necessary, but still advised.
-
-..  _`to enforce standard conformance`: https://docs.microsoft.com/en-us/cpp/build/reference/permissive-standards-conformance?view=vs-2017
-
-To compile and run the tests:
-
-.. code-block:: batch
-
-   mkdir build
-   cd build
-   cmake ..
-   cmake --build . --config Release --target check
-
-This will create a Visual Studio project, compile and run the target, all from the
-command line.
-
-.. Note::
-
-    If all tests fail, make sure that the Python binary and the testcases are compiled
-    for the same processor type and bitness (i.e. either **i386** or **x86_64**). You
-    can specify **x86_64** as the target architecture for the generated Visual Studio
-    project using ``cmake -A x64 ..``.
-
-.. seealso::
-
-    Advanced users who are already familiar with Boost.Python may want to skip
-    the tutorial and look at the test cases in the :file:`tests` directory,
-    which exercise all features of pybind11.
-
-Header and namespace conventions
-================================
-
-For brevity, all code examples assume that the following two lines are present:
-
-.. code-block:: cpp
-
-    #include <pybind11/pybind11.h>
-
-    namespace py = pybind11;
-
-Some features may require additional headers, but those will be specified as needed.
-
-.. _simple_example:
-
-Creating bindings for a simple function
-=======================================
-
-Let's start by creating Python bindings for an extremely simple function, which
-adds two numbers and returns their result:
-
-.. code-block:: cpp
-
-    int add(int i, int j) {
-        return i + j;
-    }
-
-For simplicity [#f1]_, we'll put both this function and the binding code into
-a file named :file:`example.cpp` with the following contents:
-
-.. code-block:: cpp
-
-    #include <pybind11/pybind11.h>
-
-    int add(int i, int j) {
-        return i + j;
-    }
-
-    PYBIND11_MODULE(example, m) {
-        m.doc() = "pybind11 example plugin"; // optional module docstring
-
-        m.def("add", &add, "A function that adds two numbers");
-    }
-
-.. [#f1] In practice, implementation and binding code will generally be located
-         in separate files.
-
-The :func:`PYBIND11_MODULE` macro creates a function that will be called when an
-``import`` statement is issued from within Python. The module name (``example``)
-is given as the first macro argument (it should not be in quotes). The second
-argument (``m``) defines a variable of type :class:`py::module_ <module>` which
-is the main interface for creating bindings. The method :func:`module_::def`
-generates binding code that exposes the ``add()`` function to Python.
-
-.. note::
-
-    Notice how little code was needed to expose our function to Python: all
-    details regarding the function's parameters and return value were
-    automatically inferred using template metaprogramming. This overall
-    approach and the used syntax are borrowed from Boost.Python, though the
-    underlying implementation is very different.
-
-pybind11 is a header-only library, hence it is not necessary to link against
-any special libraries and there are no intermediate (magic) translation steps.
-On Linux, the above example can be compiled using the following command:
-
-.. code-block:: bash
-
-    $ c++ -O3 -Wall -shared -std=c++11 -fPIC $(python3 -m pybind11 --includes) example.cpp -o example$(python3-config --extension-suffix)
-
-.. note::
-
-    If you used :ref:`include_as_a_submodule` to get the pybind11 source, then
-    use ``$(python3-config --includes) -Iextern/pybind11/include`` instead of
-    ``$(python3 -m pybind11 --includes)`` in the above compilation, as
-    explained in :ref:`building_manually`.
-
-For more details on the required compiler flags on Linux and macOS, see
-:ref:`building_manually`. For complete cross-platform compilation instructions,
-refer to the :ref:`compiling` page.
-
-The `python_example`_ and `cmake_example`_ repositories are also a good place
-to start. They are both complete project examples with cross-platform build
-systems. The only difference between the two is that `python_example`_ uses
-Python's ``setuptools`` to build the module, while `cmake_example`_ uses CMake
-(which may be preferable for existing C++ projects).
-
-.. _python_example: https://github.com/pybind/python_example
-.. _cmake_example: https://github.com/pybind/cmake_example
-
-Building the above C++ code will produce a binary module file that can be
-imported to Python. Assuming that the compiled module is located in the
-current directory, the following interactive Python session shows how to
-load and execute the example:
-
-.. code-block:: pycon
-
-    $ python
-    Python 3.9.10 (main, Jan 15 2022, 11:48:04)
-    [Clang 13.0.0 (clang-1300.0.29.3)] on darwin
-    Type "help", "copyright", "credits" or "license" for more information.
-    >>> import example
-    >>> example.add(1, 2)
-    3
-    >>>
-
-.. _keyword_args:
-
-Keyword arguments
-=================
-
-With a simple code modification, it is possible to inform Python about the
-names of the arguments ("i" and "j" in this case).
-
-.. code-block:: cpp
-
-    m.def("add", &add, "A function which adds two numbers",
-          py::arg("i"), py::arg("j"));
-
-:class:`arg` is one of several special tag classes which can be used to pass
-metadata into :func:`module_::def`. With this modified binding code, we can now
-call the function using keyword arguments, which is a more readable alternative
-particularly for functions taking many parameters:
-
-.. code-block:: pycon
-
-    >>> import example
-    >>> example.add(i=1, j=2)
-    3L
-
-The keyword names also appear in the function signatures within the documentation.
-
-.. code-block:: pycon
-
-    >>> help(example)
-
-    ....
-
-    FUNCTIONS
-        add(...)
-            Signature : (i: int, j: int) -> int
-
-            A function which adds two numbers
-
-A shorter notation for named arguments is also available:
-
-.. code-block:: cpp
-
-    // regular notation
-    m.def("add1", &add, py::arg("i"), py::arg("j"));
-    // shorthand
-    using namespace pybind11::literals;
-    m.def("add2", &add, "i"_a, "j"_a);
-
-The :var:`_a` suffix forms a C++11 literal which is equivalent to :class:`arg`.
-Note that the literal operator must first be made visible with the directive
-``using namespace pybind11::literals``. This does not bring in anything else
-from the ``pybind11`` namespace except for literals.
-
-.. _default_args:
-
-Default arguments
-=================
-
-Suppose now that the function to be bound has default arguments, e.g.:
-
-.. code-block:: cpp
-
-    int add(int i = 1, int j = 2) {
-        return i + j;
-    }
-
-Unfortunately, pybind11 cannot automatically extract these parameters, since they
-are not part of the function's type information. However, they are simple to specify
-using an extension of :class:`arg`:
-
-.. code-block:: cpp
-
-    m.def("add", &add, "A function which adds two numbers",
-          py::arg("i") = 1, py::arg("j") = 2);
-
-The default values also appear within the documentation.
-
-.. code-block:: pycon
-
-    >>> help(example)
-
-    ....
-
-    FUNCTIONS
-        add(...)
-            Signature : (i: int = 1, j: int = 2) -> int
-
-            A function which adds two numbers
-
-The shorthand notation is also available for default arguments:
-
-.. code-block:: cpp
-
-    // regular notation
-    m.def("add1", &add, py::arg("i") = 1, py::arg("j") = 2);
-    // shorthand
-    m.def("add2", &add, "i"_a=1, "j"_a=2);
-
-Exporting variables
-===================
-
-To expose a value from C++, use the ``attr`` function to register it in a
-module as shown below. Built-in types and general objects (more on that later)
-are automatically converted when assigned as attributes, and can be explicitly
-converted using the function ``py::cast``.
-
-.. code-block:: cpp
-
-    PYBIND11_MODULE(example, m) {
-        m.attr("the_answer") = 42;
-        py::object world = py::cast("World");
-        m.attr("what") = world;
-    }
-
-These are then accessible from Python:
-
-.. code-block:: pycon
-
-    >>> import example
-    >>> example.the_answer
-    42
-    >>> example.what
-    'World'
-
-.. _supported_types:
-
-Supported data types
-====================
-
-A large number of data types are supported out of the box and can be used
-seamlessly as functions arguments, return values or with ``py::cast`` in general.
-For a full overview, see the :doc:`advanced/cast/index` section.
+.. _basics:
+
+First steps
+###########
+
+This sections demonstrates the basic features of pybind11. Before getting
+started, make sure that development environment is set up to compile the
+included set of test cases.
+
+
+Compiling the test cases
+========================
+
+Linux/macOS
+-----------
+
+On Linux  you'll need to install the **python-dev** or **python3-dev** packages as
+well as **cmake**. On macOS, the included python version works out of the box,
+but **cmake** must still be installed.
+
+After installing the prerequisites, run
+
+.. code-block:: bash
+
+   mkdir build
+   cd build
+   cmake ..
+   make check -j 4
+
+The last line will both compile and run the tests.
+
+Windows
+-------
+
+On Windows, only **Visual Studio 2017** and newer are supported.
+
+.. Note::
+
+    To use the C++17 in Visual Studio 2017 (MSVC 14.1), pybind11 requires the flag
+    ``/permissive-`` to be passed to the compiler `to enforce standard conformance`_. When
+    building with Visual Studio 2019, this is not strictly necessary, but still advised.
+
+..  _`to enforce standard conformance`: https://docs.microsoft.com/en-us/cpp/build/reference/permissive-standards-conformance?view=vs-2017
+
+To compile and run the tests:
+
+.. code-block:: batch
+
+   mkdir build
+   cd build
+   cmake ..
+   cmake --build . --config Release --target check
+
+This will create a Visual Studio project, compile and run the target, all from the
+command line.
+
+.. Note::
+
+    If all tests fail, make sure that the Python binary and the testcases are compiled
+    for the same processor type and bitness (i.e. either **i386** or **x86_64**). You
+    can specify **x86_64** as the target architecture for the generated Visual Studio
+    project using ``cmake -A x64 ..``.
+
+.. seealso::
+
+    Advanced users who are already familiar with Boost.Python may want to skip
+    the tutorial and look at the test cases in the :file:`tests` directory,
+    which exercise all features of pybind11.
+
+Header and namespace conventions
+================================
+
+For brevity, all code examples assume that the following two lines are present:
+
+.. code-block:: cpp
+
+    #include <pybind11/pybind11.h>
+
+    namespace py = pybind11;
+
+Some features may require additional headers, but those will be specified as needed.
+
+.. _simple_example:
+
+Creating bindings for a simple function
+=======================================
+
+Let's start by creating Python bindings for an extremely simple function, which
+adds two numbers and returns their result:
+
+.. code-block:: cpp
+
+    int add(int i, int j) {
+        return i + j;
+    }
+
+For simplicity [#f1]_, we'll put both this function and the binding code into
+a file named :file:`example.cpp` with the following contents:
+
+.. code-block:: cpp
+
+    #include <pybind11/pybind11.h>
+
+    int add(int i, int j) {
+        return i + j;
+    }
+
+    PYBIND11_MODULE(example, m) {
+        m.doc() = "pybind11 example plugin"; // optional module docstring
+
+        m.def("add", &add, "A function that adds two numbers");
+    }
+
+.. [#f1] In practice, implementation and binding code will generally be located
+         in separate files.
+
+The :func:`PYBIND11_MODULE` macro creates a function that will be called when an
+``import`` statement is issued from within Python. The module name (``example``)
+is given as the first macro argument (it should not be in quotes). The second
+argument (``m``) defines a variable of type :class:`py::module_ <module>` which
+is the main interface for creating bindings. The method :func:`module_::def`
+generates binding code that exposes the ``add()`` function to Python.
+
+.. note::
+
+    Notice how little code was needed to expose our function to Python: all
+    details regarding the function's parameters and return value were
+    automatically inferred using template metaprogramming. This overall
+    approach and the used syntax are borrowed from Boost.Python, though the
+    underlying implementation is very different.
+
+pybind11 is a header-only library, hence it is not necessary to link against
+any special libraries and there are no intermediate (magic) translation steps.
+On Linux, the above example can be compiled using the following command:
+
+.. code-block:: bash
+
+    $ c++ -O3 -Wall -shared -std=c++11 -fPIC $(python3 -m pybind11 --includes) example.cpp -o example$(python3-config --extension-suffix)
+
+.. note::
+
+    If you used :ref:`include_as_a_submodule` to get the pybind11 source, then
+    use ``$(python3-config --includes) -Iextern/pybind11/include`` instead of
+    ``$(python3 -m pybind11 --includes)`` in the above compilation, as
+    explained in :ref:`building_manually`.
+
+For more details on the required compiler flags on Linux and macOS, see
+:ref:`building_manually`. For complete cross-platform compilation instructions,
+refer to the :ref:`compiling` page.
+
+The `python_example`_ and `cmake_example`_ repositories are also a good place
+to start. They are both complete project examples with cross-platform build
+systems. The only difference between the two is that `python_example`_ uses
+Python's ``setuptools`` to build the module, while `cmake_example`_ uses CMake
+(which may be preferable for existing C++ projects).
+
+.. _python_example: https://github.com/pybind/python_example
+.. _cmake_example: https://github.com/pybind/cmake_example
+
+Building the above C++ code will produce a binary module file that can be
+imported to Python. Assuming that the compiled module is located in the
+current directory, the following interactive Python session shows how to
+load and execute the example:
+
+.. code-block:: pycon
+
+    $ python
+    Python 3.9.10 (main, Jan 15 2022, 11:48:04)
+    [Clang 13.0.0 (clang-1300.0.29.3)] on darwin
+    Type "help", "copyright", "credits" or "license" for more information.
+    >>> import example
+    >>> example.add(1, 2)
+    3
+    >>>
+
+.. _keyword_args:
+
+Keyword arguments
+=================
+
+With a simple code modification, it is possible to inform Python about the
+names of the arguments ("i" and "j" in this case).
+
+.. code-block:: cpp
+
+    m.def("add", &add, "A function which adds two numbers",
+          py::arg("i"), py::arg("j"));
+
+:class:`arg` is one of several special tag classes which can be used to pass
+metadata into :func:`module_::def`. With this modified binding code, we can now
+call the function using keyword arguments, which is a more readable alternative
+particularly for functions taking many parameters:
+
+.. code-block:: pycon
+
+    >>> import example
+    >>> example.add(i=1, j=2)
+    3L
+
+The keyword names also appear in the function signatures within the documentation.
+
+.. code-block:: pycon
+
+    >>> help(example)
+
+    ....
+
+    FUNCTIONS
+        add(...)
+            Signature : (i: int, j: int) -> int
+
+            A function which adds two numbers
+
+A shorter notation for named arguments is also available:
+
+.. code-block:: cpp
+
+    // regular notation
+    m.def("add1", &add, py::arg("i"), py::arg("j"));
+    // shorthand
+    using namespace pybind11::literals;
+    m.def("add2", &add, "i"_a, "j"_a);
+
+The :var:`_a` suffix forms a C++11 literal which is equivalent to :class:`arg`.
+Note that the literal operator must first be made visible with the directive
+``using namespace pybind11::literals``. This does not bring in anything else
+from the ``pybind11`` namespace except for literals.
+
+.. _default_args:
+
+Default arguments
+=================
+
+Suppose now that the function to be bound has default arguments, e.g.:
+
+.. code-block:: cpp
+
+    int add(int i = 1, int j = 2) {
+        return i + j;
+    }
+
+Unfortunately, pybind11 cannot automatically extract these parameters, since they
+are not part of the function's type information. However, they are simple to specify
+using an extension of :class:`arg`:
+
+.. code-block:: cpp
+
+    m.def("add", &add, "A function which adds two numbers",
+          py::arg("i") = 1, py::arg("j") = 2);
+
+The default values also appear within the documentation.
+
+.. code-block:: pycon
+
+    >>> help(example)
+
+    ....
+
+    FUNCTIONS
+        add(...)
+            Signature : (i: int = 1, j: int = 2) -> int
+
+            A function which adds two numbers
+
+The shorthand notation is also available for default arguments:
+
+.. code-block:: cpp
+
+    // regular notation
+    m.def("add1", &add, py::arg("i") = 1, py::arg("j") = 2);
+    // shorthand
+    m.def("add2", &add, "i"_a=1, "j"_a=2);
+
+Exporting variables
+===================
+
+To expose a value from C++, use the ``attr`` function to register it in a
+module as shown below. Built-in types and general objects (more on that later)
+are automatically converted when assigned as attributes, and can be explicitly
+converted using the function ``py::cast``.
+
+.. code-block:: cpp
+
+    PYBIND11_MODULE(example, m) {
+        m.attr("the_answer") = 42;
+        py::object world = py::cast("World");
+        m.attr("what") = world;
+    }
+
+These are then accessible from Python:
+
+.. code-block:: pycon
+
+    >>> import example
+    >>> example.the_answer
+    42
+    >>> example.what
+    'World'
+
+.. _supported_types:
+
+Supported data types
+====================
+
+A large number of data types are supported out of the box and can be used
+seamlessly as functions arguments, return values or with ``py::cast`` in general.
+For a full overview, see the :doc:`advanced/cast/index` section.

third_party/CityFlow/extern/pybind11/docs/benchmark.py

@@ -1,87 +1,87 @@
-import datetime as dt
-import os
-import random
-
-nfns = 4  # Functions per class
-nargs = 4  # Arguments per function
-
-
-def generate_dummy_code_pybind11(nclasses=10):
-    decl = ""
-    bindings = ""
-
-    for cl in range(nclasses):
-        decl += f"class cl{cl:03};\n"
-    decl += "\n"
-
-    for cl in range(nclasses):
-        decl += f"class {cl:03} {{\n"
-        decl += "public:\n"
-        bindings += f'    py::class_<cl{cl:03}>(m, "cl{cl:03}")\n'
-        for fn in range(nfns):
-            ret = random.randint(0, nclasses - 1)
-            params = [random.randint(0, nclasses - 1) for i in range(nargs)]
-            decl += f"    cl{ret:03} *fn_{fn:03}("
-            decl += ", ".join(f"cl{p:03} *" for p in params)
-            decl += ");\n"
-            bindings += f'        .def("fn_{fn:03}", &cl{cl:03}::fn_{fn:03})\n'
-        decl += "};\n\n"
-        bindings += "        ;\n"
-
-    result = "#include <pybind11/pybind11.h>\n\n"
-    result += "namespace py = pybind11;\n\n"
-    result += decl + "\n"
-    result += "PYBIND11_MODULE(example, m) {\n"
-    result += bindings
-    result += "}"
-    return result
-
-
-def generate_dummy_code_boost(nclasses=10):
-    decl = ""
-    bindings = ""
-
-    for cl in range(nclasses):
-        decl += f"class cl{cl:03};\n"
-    decl += "\n"
-
-    for cl in range(nclasses):
-        decl += "class cl%03i {\n" % cl
-        decl += "public:\n"
-        bindings += f'    py::class_<cl{cl:03}>("cl{cl:03}")\n'
-        for fn in range(nfns):
-            ret = random.randint(0, nclasses - 1)
-            params = [random.randint(0, nclasses - 1) for i in range(nargs)]
-            decl += f"    cl{ret:03} *fn_{fn:03}("
-            decl += ", ".join(f"cl{p:03} *" for p in params)
-            decl += ");\n"
-            bindings += f'        .def("fn_{fn:03}", &cl{cl:03}::fn_{fn:03}, py::return_value_policy<py::manage_new_object>())\n'
-        decl += "};\n\n"
-        bindings += "        ;\n"
-
-    result = "#include <boost/python.hpp>\n\n"
-    result += "namespace py = boost::python;\n\n"
-    result += decl + "\n"
-    result += "BOOST_PYTHON_MODULE(example) {\n"
-    result += bindings
-    result += "}"
-    return result
-
-
-for codegen in [generate_dummy_code_pybind11, generate_dummy_code_boost]:
-    print("{")
-    for i in range(10):
-        nclasses = 2**i
-        with open("test.cpp", "w") as f:
-            f.write(codegen(nclasses))
-        n1 = dt.datetime.now()
-        os.system(
-            "g++ -Os -shared -rdynamic -undefined dynamic_lookup "
-            "-fvisibility=hidden -std=c++14 test.cpp -I include "
-            "-I /System/Library/Frameworks/Python.framework/Headers -o test.so"
-        )
-        n2 = dt.datetime.now()
-        elapsed = (n2 - n1).total_seconds()
-        size = os.stat("test.so").st_size
-        print("   {%i, %f, %i}," % (nclasses * nfns, elapsed, size))
-    print("}")
+import datetime as dt
+import os
+import random
+
+nfns = 4  # Functions per class
+nargs = 4  # Arguments per function
+
+
+def generate_dummy_code_pybind11(nclasses=10):
+    decl = ""
+    bindings = ""
+
+    for cl in range(nclasses):
+        decl += f"class cl{cl:03};\n"
+    decl += "\n"
+
+    for cl in range(nclasses):
+        decl += f"class {cl:03} {{\n"
+        decl += "public:\n"
+        bindings += f'    py::class_<cl{cl:03}>(m, "cl{cl:03}")\n'
+        for fn in range(nfns):
+            ret = random.randint(0, nclasses - 1)
+            params = [random.randint(0, nclasses - 1) for i in range(nargs)]
+            decl += f"    cl{ret:03} *fn_{fn:03}("
+            decl += ", ".join(f"cl{p:03} *" for p in params)
+            decl += ");\n"
+            bindings += f'        .def("fn_{fn:03}", &cl{cl:03}::fn_{fn:03})\n'
+        decl += "};\n\n"
+        bindings += "        ;\n"
+
+    result = "#include <pybind11/pybind11.h>\n\n"
+    result += "namespace py = pybind11;\n\n"
+    result += decl + "\n"
+    result += "PYBIND11_MODULE(example, m) {\n"
+    result += bindings
+    result += "}"
+    return result
+
+
+def generate_dummy_code_boost(nclasses=10):
+    decl = ""
+    bindings = ""
+
+    for cl in range(nclasses):
+        decl += f"class cl{cl:03};\n"
+    decl += "\n"
+
+    for cl in range(nclasses):
+        decl += "class cl%03i {\n" % cl
+        decl += "public:\n"
+        bindings += f'    py::class_<cl{cl:03}>("cl{cl:03}")\n'
+        for fn in range(nfns):
+            ret = random.randint(0, nclasses - 1)
+            params = [random.randint(0, nclasses - 1) for i in range(nargs)]
+            decl += f"    cl{ret:03} *fn_{fn:03}("
+            decl += ", ".join(f"cl{p:03} *" for p in params)
+            decl += ");\n"
+            bindings += f'        .def("fn_{fn:03}", &cl{cl:03}::fn_{fn:03}, py::return_value_policy<py::manage_new_object>())\n'
+        decl += "};\n\n"
+        bindings += "        ;\n"
+
+    result = "#include <boost/python.hpp>\n\n"
+    result += "namespace py = boost::python;\n\n"
+    result += decl + "\n"
+    result += "BOOST_PYTHON_MODULE(example) {\n"
+    result += bindings
+    result += "}"
+    return result
+
+
+for codegen in [generate_dummy_code_pybind11, generate_dummy_code_boost]:
+    print("{")
+    for i in range(10):
+        nclasses = 2**i
+        with open("test.cpp", "w") as f:
+            f.write(codegen(nclasses))
+        n1 = dt.datetime.now()
+        os.system(
+            "g++ -Os -shared -rdynamic -undefined dynamic_lookup "
+            "-fvisibility=hidden -std=c++14 test.cpp -I include "
+            "-I /System/Library/Frameworks/Python.framework/Headers -o test.so"
+        )
+        n2 = dt.datetime.now()
+        elapsed = (n2 - n1).total_seconds()
+        size = os.stat("test.so").st_size
+        print("   {%i, %f, %i}," % (nclasses * nfns, elapsed, size))
+    print("}")

third_party/CityFlow/extern/pybind11/docs/benchmark.rst

@@ -1,95 +1,95 @@
-Benchmark
-=========
-
-The following is the result of a synthetic benchmark comparing both compilation
-time and module size of pybind11 against Boost.Python. A detailed report about a
-Boost.Python to pybind11 conversion of a real project is available here: [#f1]_.
-
-.. [#f1] http://graylab.jhu.edu/RosettaCon2016/PyRosetta-4.pdf
-
-Setup
------
-
-A python script (see the ``docs/benchmark.py`` file) was used to generate a set
-of files with dummy classes whose count increases for each successive benchmark
-(between 1 and 2048 classes in powers of two). Each class has four methods with
-a randomly generated signature with a return value and four arguments. (There
-was no particular reason for this setup other than the desire to generate many
-unique function signatures whose count could be controlled in a simple way.)
-
-Here is an example of the binding code for one class:
-
-.. code-block:: cpp
-
-    ...
-    class cl034 {
-    public:
-        cl279 *fn_000(cl084 *, cl057 *, cl065 *, cl042 *);
-        cl025 *fn_001(cl098 *, cl262 *, cl414 *, cl121 *);
-        cl085 *fn_002(cl445 *, cl297 *, cl145 *, cl421 *);
-        cl470 *fn_003(cl200 *, cl323 *, cl332 *, cl492 *);
-    };
-    ...
-
-    PYBIND11_MODULE(example, m) {
-        ...
-        py::class_<cl034>(m, "cl034")
-            .def("fn_000", &cl034::fn_000)
-            .def("fn_001", &cl034::fn_001)
-            .def("fn_002", &cl034::fn_002)
-            .def("fn_003", &cl034::fn_003)
-        ...
-    }
-
-The Boost.Python version looks almost identical except that a return value
-policy had to be specified as an argument to ``def()``. For both libraries,
-compilation was done with
-
-.. code-block:: bash
-
-    Apple LLVM version 7.0.2 (clang-700.1.81)
-
-and the following compilation flags
-
-.. code-block:: bash
-
-    g++ -Os -shared -rdynamic -undefined dynamic_lookup -fvisibility=hidden -std=c++14
-
-Compilation time
-----------------
-
-The following log-log plot shows how the compilation time grows for an
-increasing number of class and function declarations. pybind11 includes many
-fewer headers, which initially leads to shorter compilation times, but the
-performance is ultimately fairly similar (pybind11 is 19.8 seconds faster for
-the largest largest file with 2048 classes and a total of 8192 methods -- a
-modest **1.2x** speedup relative to Boost.Python, which required 116.35
-seconds).
-
-.. only:: not latex
-
-    .. image:: pybind11_vs_boost_python1.svg
-
-.. only:: latex
-
-    .. image:: pybind11_vs_boost_python1.png
-
-Module size
------------
-
-Differences between the two libraries become much more pronounced when
-considering the file size of the generated Python plugin: for the largest file,
-the binary generated by Boost.Python required 16.8 MiB, which was **2.17
-times** / **9.1 megabytes** larger than the output generated by pybind11. For
-very small inputs, Boost.Python has an edge in the plot below -- however, note
-that it stores many definitions in an external library, whose size was not
-included here, hence the comparison is slightly shifted in Boost.Python's
-favor.
-
-.. only:: not latex
-
-    .. image:: pybind11_vs_boost_python2.svg
-
-.. only:: latex
-
-    .. image:: pybind11_vs_boost_python2.png
+Benchmark
+=========
+
+The following is the result of a synthetic benchmark comparing both compilation
+time and module size of pybind11 against Boost.Python. A detailed report about a
+Boost.Python to pybind11 conversion of a real project is available here: [#f1]_.
+
+.. [#f1] http://graylab.jhu.edu/RosettaCon2016/PyRosetta-4.pdf
+
+Setup
+-----
+
+A python script (see the ``docs/benchmark.py`` file) was used to generate a set
+of files with dummy classes whose count increases for each successive benchmark
+(between 1 and 2048 classes in powers of two). Each class has four methods with
+a randomly generated signature with a return value and four arguments. (There
+was no particular reason for this setup other than the desire to generate many
+unique function signatures whose count could be controlled in a simple way.)
+
+Here is an example of the binding code for one class:
+
+.. code-block:: cpp
+
+    ...
+    class cl034 {
+    public:
+        cl279 *fn_000(cl084 *, cl057 *, cl065 *, cl042 *);
+        cl025 *fn_001(cl098 *, cl262 *, cl414 *, cl121 *);
+        cl085 *fn_002(cl445 *, cl297 *, cl145 *, cl421 *);
+        cl470 *fn_003(cl200 *, cl323 *, cl332 *, cl492 *);
+    };
+    ...
+
+    PYBIND11_MODULE(example, m) {
+        ...
+        py::class_<cl034>(m, "cl034")
+            .def("fn_000", &cl034::fn_000)
+            .def("fn_001", &cl034::fn_001)
+            .def("fn_002", &cl034::fn_002)
+            .def("fn_003", &cl034::fn_003)
+        ...
+    }
+
+The Boost.Python version looks almost identical except that a return value
+policy had to be specified as an argument to ``def()``. For both libraries,
+compilation was done with
+
+.. code-block:: bash
+
+    Apple LLVM version 7.0.2 (clang-700.1.81)
+
+and the following compilation flags
+
+.. code-block:: bash
+
+    g++ -Os -shared -rdynamic -undefined dynamic_lookup -fvisibility=hidden -std=c++14
+
+Compilation time
+----------------
+
+The following log-log plot shows how the compilation time grows for an
+increasing number of class and function declarations. pybind11 includes many
+fewer headers, which initially leads to shorter compilation times, but the
+performance is ultimately fairly similar (pybind11 is 19.8 seconds faster for
+the largest largest file with 2048 classes and a total of 8192 methods -- a
+modest **1.2x** speedup relative to Boost.Python, which required 116.35
+seconds).
+
+.. only:: not latex
+
+    .. image:: pybind11_vs_boost_python1.svg
+
+.. only:: latex
+
+    .. image:: pybind11_vs_boost_python1.png
+
+Module size
+-----------
+
+Differences between the two libraries become much more pronounced when
+considering the file size of the generated Python plugin: for the largest file,
+the binary generated by Boost.Python required 16.8 MiB, which was **2.17
+times** / **9.1 megabytes** larger than the output generated by pybind11. For
+very small inputs, Boost.Python has an edge in the plot below -- however, note
+that it stores many definitions in an external library, whose size was not
+included here, hence the comparison is slightly shifted in Boost.Python's
+favor.
+
+.. only:: not latex
+
+    .. image:: pybind11_vs_boost_python2.svg
+
+.. only:: latex
+
+    .. image:: pybind11_vs_boost_python2.png

third_party/CityFlow/extern/pybind11/docs/classes.rst

@@ -1,555 +1,555 @@
-.. _classes:
-
-Object-oriented code
-####################
-
-Creating bindings for a custom type
-===================================
-
-Let's now look at a more complex example where we'll create bindings for a
-custom C++ data structure named ``Pet``. Its definition is given below:
-
-.. code-block:: cpp
-
-    struct Pet {
-        Pet(const std::string &name) : name(name) { }
-        void setName(const std::string &name_) { name = name_; }
-        const std::string &getName() const { return name; }
-
-        std::string name;
-    };
-
-The binding code for ``Pet`` looks as follows:
-
-.. code-block:: cpp
-
-    #include <pybind11/pybind11.h>
-
-    namespace py = pybind11;
-
-    PYBIND11_MODULE(example, m) {
-        py::class_<Pet>(m, "Pet")
-            .def(py::init<const std::string &>())
-            .def("setName", &Pet::setName)
-            .def("getName", &Pet::getName);
-    }
-
-:class:`class_` creates bindings for a C++ *class* or *struct*-style data
-structure. :func:`init` is a convenience function that takes the types of a
-constructor's parameters as template arguments and wraps the corresponding
-constructor (see the :ref:`custom_constructors` section for details). An
-interactive Python session demonstrating this example is shown below:
-
-.. code-block:: pycon
-
-    % python
-    >>> import example
-    >>> p = example.Pet("Molly")
-    >>> print(p)
-    <example.Pet object at 0x10cd98060>
-    >>> p.getName()
-    'Molly'
-    >>> p.setName("Charly")
-    >>> p.getName()
-    'Charly'
-
-.. seealso::
-
-    Static member functions can be bound in the same way using
-    :func:`class_::def_static`.
-
-.. note::
-
-    Binding C++ types in unnamed namespaces (also known as anonymous namespaces)
-    works reliably on many platforms, but not all. The `XFAIL_CONDITION` in
-    tests/test_unnamed_namespace_a.py encodes the currently known conditions.
-    For background see `#4319 <https://github.com/pybind/pybind11/pull/4319>`_.
-    If portability is a concern, it is therefore not recommended to bind C++
-    types in unnamed namespaces. It will be safest to manually pick unique
-    namespace names.
-
-Keyword and default arguments
-=============================
-It is possible to specify keyword and default arguments using the syntax
-discussed in the previous chapter. Refer to the sections :ref:`keyword_args`
-and :ref:`default_args` for details.
-
-Binding lambda functions
-========================
-
-Note how ``print(p)`` produced a rather useless summary of our data structure in the example above:
-
-.. code-block:: pycon
-
-    >>> print(p)
-    <example.Pet object at 0x10cd98060>
-
-To address this, we could bind a utility function that returns a human-readable
-summary to the special method slot named ``__repr__``. Unfortunately, there is no
-suitable functionality in the ``Pet`` data structure, and it would be nice if
-we did not have to change it. This can easily be accomplished by binding a
-Lambda function instead:
-
-.. code-block:: cpp
-
-        py::class_<Pet>(m, "Pet")
-            .def(py::init<const std::string &>())
-            .def("setName", &Pet::setName)
-            .def("getName", &Pet::getName)
-            .def("__repr__",
-                [](const Pet &a) {
-                    return "<example.Pet named '" + a.name + "'>";
-                }
-            );
-
-Both stateless [#f1]_ and stateful lambda closures are supported by pybind11.
-With the above change, the same Python code now produces the following output:
-
-.. code-block:: pycon
-
-    >>> print(p)
-    <example.Pet named 'Molly'>
-
-.. [#f1] Stateless closures are those with an empty pair of brackets ``[]`` as the capture object.
-
-.. _properties:
-
-Instance and static fields
-==========================
-
-We can also directly expose the ``name`` field using the
-:func:`class_::def_readwrite` method. A similar :func:`class_::def_readonly`
-method also exists for ``const`` fields.
-
-.. code-block:: cpp
-
-        py::class_<Pet>(m, "Pet")
-            .def(py::init<const std::string &>())
-            .def_readwrite("name", &Pet::name)
-            // ... remainder ...
-
-This makes it possible to write
-
-.. code-block:: pycon
-
-    >>> p = example.Pet("Molly")
-    >>> p.name
-    'Molly'
-    >>> p.name = "Charly"
-    >>> p.name
-    'Charly'
-
-Now suppose that ``Pet::name`` was a private internal variable
-that can only be accessed via setters and getters.
-
-.. code-block:: cpp
-
-    class Pet {
-    public:
-        Pet(const std::string &name) : name(name) { }
-        void setName(const std::string &name_) { name = name_; }
-        const std::string &getName() const { return name; }
-    private:
-        std::string name;
-    };
-
-In this case, the method :func:`class_::def_property`
-(:func:`class_::def_property_readonly` for read-only data) can be used to
-provide a field-like interface within Python that will transparently call
-the setter and getter functions:
-
-.. code-block:: cpp
-
-        py::class_<Pet>(m, "Pet")
-            .def(py::init<const std::string &>())
-            .def_property("name", &Pet::getName, &Pet::setName)
-            // ... remainder ...
-
-Write only properties can be defined by passing ``nullptr`` as the
-input for the read function.
-
-.. seealso::
-
-    Similar functions :func:`class_::def_readwrite_static`,
-    :func:`class_::def_readonly_static` :func:`class_::def_property_static`,
-    and :func:`class_::def_property_readonly_static` are provided for binding
-    static variables and properties. Please also see the section on
-    :ref:`static_properties` in the advanced part of the documentation.
-
-Dynamic attributes
-==================
-
-Native Python classes can pick up new attributes dynamically:
-
-.. code-block:: pycon
-
-    >>> class Pet:
-    ...     name = "Molly"
-    ...
-    >>> p = Pet()
-    >>> p.name = "Charly"  # overwrite existing
-    >>> p.age = 2  # dynamically add a new attribute
-
-By default, classes exported from C++ do not support this and the only writable
-attributes are the ones explicitly defined using :func:`class_::def_readwrite`
-or :func:`class_::def_property`.
-
-.. code-block:: cpp
-
-    py::class_<Pet>(m, "Pet")
-        .def(py::init<>())
-        .def_readwrite("name", &Pet::name);
-
-Trying to set any other attribute results in an error:
-
-.. code-block:: pycon
-
-    >>> p = example.Pet()
-    >>> p.name = "Charly"  # OK, attribute defined in C++
-    >>> p.age = 2  # fail
-    AttributeError: 'Pet' object has no attribute 'age'
-
-To enable dynamic attributes for C++ classes, the :class:`py::dynamic_attr` tag
-must be added to the :class:`py::class_` constructor:
-
-.. code-block:: cpp
-
-    py::class_<Pet>(m, "Pet", py::dynamic_attr())
-        .def(py::init<>())
-        .def_readwrite("name", &Pet::name);
-
-Now everything works as expected:
-
-.. code-block:: pycon
-
-    >>> p = example.Pet()
-    >>> p.name = "Charly"  # OK, overwrite value in C++
-    >>> p.age = 2  # OK, dynamically add a new attribute
-    >>> p.__dict__  # just like a native Python class
-    {'age': 2}
-
-Note that there is a small runtime cost for a class with dynamic attributes.
-Not only because of the addition of a ``__dict__``, but also because of more
-expensive garbage collection tracking which must be activated to resolve
-possible circular references. Native Python classes incur this same cost by
-default, so this is not anything to worry about. By default, pybind11 classes
-are more efficient than native Python classes. Enabling dynamic attributes
-just brings them on par.
-
-.. _inheritance:
-
-Inheritance and automatic downcasting
-=====================================
-
-Suppose now that the example consists of two data structures with an
-inheritance relationship:
-
-.. code-block:: cpp
-
-    struct Pet {
-        Pet(const std::string &name) : name(name) { }
-        std::string name;
-    };
-
-    struct Dog : Pet {
-        Dog(const std::string &name) : Pet(name) { }
-        std::string bark() const { return "woof!"; }
-    };
-
-There are two different ways of indicating a hierarchical relationship to
-pybind11: the first specifies the C++ base class as an extra template
-parameter of the :class:`class_`:
-
-.. code-block:: cpp
-
-    py::class_<Pet>(m, "Pet")
-       .def(py::init<const std::string &>())
-       .def_readwrite("name", &Pet::name);
-
-    // Method 1: template parameter:
-    py::class_<Dog, Pet /* <- specify C++ parent type */>(m, "Dog")
-        .def(py::init<const std::string &>())
-        .def("bark", &Dog::bark);
-
-Alternatively, we can also assign a name to the previously bound ``Pet``
-:class:`class_` object and reference it when binding the ``Dog`` class:
-
-.. code-block:: cpp
-
-    py::class_<Pet> pet(m, "Pet");
-    pet.def(py::init<const std::string &>())
-       .def_readwrite("name", &Pet::name);
-
-    // Method 2: pass parent class_ object:
-    py::class_<Dog>(m, "Dog", pet /* <- specify Python parent type */)
-        .def(py::init<const std::string &>())
-        .def("bark", &Dog::bark);
-
-Functionality-wise, both approaches are equivalent. Afterwards, instances will
-expose fields and methods of both types:
-
-.. code-block:: pycon
-
-    >>> p = example.Dog("Molly")
-    >>> p.name
-    'Molly'
-    >>> p.bark()
-    'woof!'
-
-The C++ classes defined above are regular non-polymorphic types with an
-inheritance relationship. This is reflected in Python:
-
-.. code-block:: cpp
-
-    // Return a base pointer to a derived instance
-    m.def("pet_store", []() { return std::unique_ptr<Pet>(new Dog("Molly")); });
-
-.. code-block:: pycon
-
-    >>> p = example.pet_store()
-    >>> type(p)  # `Dog` instance behind `Pet` pointer
-    Pet          # no pointer downcasting for regular non-polymorphic types
-    >>> p.bark()
-    AttributeError: 'Pet' object has no attribute 'bark'
-
-The function returned a ``Dog`` instance, but because it's a non-polymorphic
-type behind a base pointer, Python only sees a ``Pet``. In C++, a type is only
-considered polymorphic if it has at least one virtual function and pybind11
-will automatically recognize this:
-
-.. code-block:: cpp
-
-    struct PolymorphicPet {
-        virtual ~PolymorphicPet() = default;
-    };
-
-    struct PolymorphicDog : PolymorphicPet {
-        std::string bark() const { return "woof!"; }
-    };
-
-    // Same binding code
-    py::class_<PolymorphicPet>(m, "PolymorphicPet");
-    py::class_<PolymorphicDog, PolymorphicPet>(m, "PolymorphicDog")
-        .def(py::init<>())
-        .def("bark", &PolymorphicDog::bark);
-
-    // Again, return a base pointer to a derived instance
-    m.def("pet_store2", []() { return std::unique_ptr<PolymorphicPet>(new PolymorphicDog); });
-
-.. code-block:: pycon
-
-    >>> p = example.pet_store2()
-    >>> type(p)
-    PolymorphicDog  # automatically downcast
-    >>> p.bark()
-    'woof!'
-
-Given a pointer to a polymorphic base, pybind11 performs automatic downcasting
-to the actual derived type. Note that this goes beyond the usual situation in
-C++: we don't just get access to the virtual functions of the base, we get the
-concrete derived type including functions and attributes that the base type may
-not even be aware of.
-
-.. seealso::
-
-    For more information about polymorphic behavior see :ref:`overriding_virtuals`.
-
-
-Overloaded methods
-==================
-
-Sometimes there are several overloaded C++ methods with the same name taking
-different kinds of input arguments:
-
-.. code-block:: cpp
-
-    struct Pet {
-        Pet(const std::string &name, int age) : name(name), age(age) { }
-
-        void set(int age_) { age = age_; }
-        void set(const std::string &name_) { name = name_; }
-
-        std::string name;
-        int age;
-    };
-
-Attempting to bind ``Pet::set`` will cause an error since the compiler does not
-know which method the user intended to select. We can disambiguate by casting
-them to function pointers. Binding multiple functions to the same Python name
-automatically creates a chain of function overloads that will be tried in
-sequence.
-
-.. code-block:: cpp
-
-    py::class_<Pet>(m, "Pet")
-       .def(py::init<const std::string &, int>())
-       .def("set", static_cast<void (Pet::*)(int)>(&Pet::set), "Set the pet's age")
-       .def("set", static_cast<void (Pet::*)(const std::string &)>(&Pet::set), "Set the pet's name");
-
-The overload signatures are also visible in the method's docstring:
-
-.. code-block:: pycon
-
-    >>> help(example.Pet)
-
-    class Pet(__builtin__.object)
-     |  Methods defined here:
-     |
-     |  __init__(...)
-     |      Signature : (Pet, str, int) -> NoneType
-     |
-     |  set(...)
-     |      1. Signature : (Pet, int) -> NoneType
-     |
-     |      Set the pet's age
-     |
-     |      2. Signature : (Pet, str) -> NoneType
-     |
-     |      Set the pet's name
-
-If you have a C++14 compatible compiler [#cpp14]_, you can use an alternative
-syntax to cast the overloaded function:
-
-.. code-block:: cpp
-
-    py::class_<Pet>(m, "Pet")
-        .def("set", py::overload_cast<int>(&Pet::set), "Set the pet's age")
-        .def("set", py::overload_cast<const std::string &>(&Pet::set), "Set the pet's name");
-
-Here, ``py::overload_cast`` only requires the parameter types to be specified.
-The return type and class are deduced. This avoids the additional noise of
-``void (Pet::*)()`` as seen in the raw cast. If a function is overloaded based
-on constness, the ``py::const_`` tag should be used:
-
-.. code-block:: cpp
-
-    struct Widget {
-        int foo(int x, float y);
-        int foo(int x, float y) const;
-    };
-
-    py::class_<Widget>(m, "Widget")
-       .def("foo_mutable", py::overload_cast<int, float>(&Widget::foo))
-       .def("foo_const",   py::overload_cast<int, float>(&Widget::foo, py::const_));
-
-If you prefer the ``py::overload_cast`` syntax but have a C++11 compatible compiler only,
-you can use ``py::detail::overload_cast_impl`` with an additional set of parentheses:
-
-.. code-block:: cpp
-
-    template <typename... Args>
-    using overload_cast_ = pybind11::detail::overload_cast_impl<Args...>;
-
-    py::class_<Pet>(m, "Pet")
-        .def("set", overload_cast_<int>()(&Pet::set), "Set the pet's age")
-        .def("set", overload_cast_<const std::string &>()(&Pet::set), "Set the pet's name");
-
-.. [#cpp14] A compiler which supports the ``-std=c++14`` flag.
-
-.. note::
-
-    To define multiple overloaded constructors, simply declare one after the
-    other using the ``.def(py::init<...>())`` syntax. The existing machinery
-    for specifying keyword and default arguments also works.
-
-Enumerations and internal types
-===============================
-
-Let's now suppose that the example class contains internal types like enumerations, e.g.:
-
-.. code-block:: cpp
-
-    struct Pet {
-        enum Kind {
-            Dog = 0,
-            Cat
-        };
-
-        struct Attributes {
-            float age = 0;
-        };
-
-        Pet(const std::string &name, Kind type) : name(name), type(type) { }
-
-        std::string name;
-        Kind type;
-        Attributes attr;
-    };
-
-The binding code for this example looks as follows:
-
-.. code-block:: cpp
-
-    py::class_<Pet> pet(m, "Pet");
-
-    pet.def(py::init<const std::string &, Pet::Kind>())
-        .def_readwrite("name", &Pet::name)
-        .def_readwrite("type", &Pet::type)
-        .def_readwrite("attr", &Pet::attr);
-
-    py::enum_<Pet::Kind>(pet, "Kind")
-        .value("Dog", Pet::Kind::Dog)
-        .value("Cat", Pet::Kind::Cat)
-        .export_values();
-
-    py::class_<Pet::Attributes>(pet, "Attributes")
-        .def(py::init<>())
-        .def_readwrite("age", &Pet::Attributes::age);
-
-
-To ensure that the nested types ``Kind`` and ``Attributes`` are created within the scope of ``Pet``, the
-``pet`` :class:`class_` instance must be supplied to the :class:`enum_` and :class:`class_`
-constructor. The :func:`enum_::export_values` function exports the enum entries
-into the parent scope, which should be skipped for newer C++11-style strongly
-typed enums.
-
-.. code-block:: pycon
-
-    >>> p = Pet("Lucy", Pet.Cat)
-    >>> p.type
-    Kind.Cat
-    >>> int(p.type)
-    1L
-
-The entries defined by the enumeration type are exposed in the ``__members__`` property:
-
-.. code-block:: pycon
-
-    >>> Pet.Kind.__members__
-    {'Dog': Kind.Dog, 'Cat': Kind.Cat}
-
-The ``name`` property returns the name of the enum value as a unicode string.
-
-.. note::
-
-    It is also possible to use ``str(enum)``, however these accomplish different
-    goals. The following shows how these two approaches differ.
-
-    .. code-block:: pycon
-
-        >>> p = Pet("Lucy", Pet.Cat)
-        >>> pet_type = p.type
-        >>> pet_type
-        Pet.Cat
-        >>> str(pet_type)
-        'Pet.Cat'
-        >>> pet_type.name
-        'Cat'
-
-.. note::
-
-    When the special tag ``py::arithmetic()`` is specified to the ``enum_``
-    constructor, pybind11 creates an enumeration that also supports rudimentary
-    arithmetic and bit-level operations like comparisons, and, or, xor, negation,
-    etc.
-
-    .. code-block:: cpp
-
-        py::enum_<Pet::Kind>(pet, "Kind", py::arithmetic())
-           ...
-
-    By default, these are omitted to conserve space.
-
-.. warning::
-
-    Contrary to Python customs, enum values from the wrappers should not be compared using ``is``, but with ``==`` (see `#1177 <https://github.com/pybind/pybind11/issues/1177>`_ for background).
+.. _classes:
+
+Object-oriented code
+####################
+
+Creating bindings for a custom type
+===================================
+
+Let's now look at a more complex example where we'll create bindings for a
+custom C++ data structure named ``Pet``. Its definition is given below:
+
+.. code-block:: cpp
+
+    struct Pet {
+        Pet(const std::string &name) : name(name) { }
+        void setName(const std::string &name_) { name = name_; }
+        const std::string &getName() const { return name; }
+
+        std::string name;
+    };
+
+The binding code for ``Pet`` looks as follows:
+
+.. code-block:: cpp
+
+    #include <pybind11/pybind11.h>
+
+    namespace py = pybind11;
+
+    PYBIND11_MODULE(example, m) {
+        py::class_<Pet>(m, "Pet")
+            .def(py::init<const std::string &>())
+            .def("setName", &Pet::setName)
+            .def("getName", &Pet::getName);
+    }
+
+:class:`class_` creates bindings for a C++ *class* or *struct*-style data
+structure. :func:`init` is a convenience function that takes the types of a
+constructor's parameters as template arguments and wraps the corresponding
+constructor (see the :ref:`custom_constructors` section for details). An
+interactive Python session demonstrating this example is shown below:
+
+.. code-block:: pycon
+
+    % python
+    >>> import example
+    >>> p = example.Pet("Molly")
+    >>> print(p)
+    <example.Pet object at 0x10cd98060>
+    >>> p.getName()
+    'Molly'
+    >>> p.setName("Charly")
+    >>> p.getName()
+    'Charly'
+
+.. seealso::
+
+    Static member functions can be bound in the same way using
+    :func:`class_::def_static`.
+
+.. note::
+
+    Binding C++ types in unnamed namespaces (also known as anonymous namespaces)
+    works reliably on many platforms, but not all. The `XFAIL_CONDITION` in
+    tests/test_unnamed_namespace_a.py encodes the currently known conditions.
+    For background see `#4319 <https://github.com/pybind/pybind11/pull/4319>`_.
+    If portability is a concern, it is therefore not recommended to bind C++
+    types in unnamed namespaces. It will be safest to manually pick unique
+    namespace names.
+
+Keyword and default arguments
+=============================
+It is possible to specify keyword and default arguments using the syntax
+discussed in the previous chapter. Refer to the sections :ref:`keyword_args`
+and :ref:`default_args` for details.
+
+Binding lambda functions
+========================
+
+Note how ``print(p)`` produced a rather useless summary of our data structure in the example above:
+
+.. code-block:: pycon
+
+    >>> print(p)
+    <example.Pet object at 0x10cd98060>
+
+To address this, we could bind a utility function that returns a human-readable
+summary to the special method slot named ``__repr__``. Unfortunately, there is no
+suitable functionality in the ``Pet`` data structure, and it would be nice if
+we did not have to change it. This can easily be accomplished by binding a
+Lambda function instead:
+
+.. code-block:: cpp
+
+        py::class_<Pet>(m, "Pet")
+            .def(py::init<const std::string &>())
+            .def("setName", &Pet::setName)
+            .def("getName", &Pet::getName)
+            .def("__repr__",
+                [](const Pet &a) {
+                    return "<example.Pet named '" + a.name + "'>";
+                }
+            );
+
+Both stateless [#f1]_ and stateful lambda closures are supported by pybind11.
+With the above change, the same Python code now produces the following output:
+
+.. code-block:: pycon
+
+    >>> print(p)
+    <example.Pet named 'Molly'>
+
+.. [#f1] Stateless closures are those with an empty pair of brackets ``[]`` as the capture object.
+
+.. _properties:
+
+Instance and static fields
+==========================
+
+We can also directly expose the ``name`` field using the
+:func:`class_::def_readwrite` method. A similar :func:`class_::def_readonly`
+method also exists for ``const`` fields.
+
+.. code-block:: cpp
+
+        py::class_<Pet>(m, "Pet")
+            .def(py::init<const std::string &>())
+            .def_readwrite("name", &Pet::name)
+            // ... remainder ...
+
+This makes it possible to write
+
+.. code-block:: pycon
+
+    >>> p = example.Pet("Molly")
+    >>> p.name
+    'Molly'
+    >>> p.name = "Charly"
+    >>> p.name
+    'Charly'
+
+Now suppose that ``Pet::name`` was a private internal variable
+that can only be accessed via setters and getters.
+
+.. code-block:: cpp
+
+    class Pet {
+    public:
+        Pet(const std::string &name) : name(name) { }
+        void setName(const std::string &name_) { name = name_; }
+        const std::string &getName() const { return name; }
+    private:
+        std::string name;
+    };
+
+In this case, the method :func:`class_::def_property`
+(:func:`class_::def_property_readonly` for read-only data) can be used to
+provide a field-like interface within Python that will transparently call
+the setter and getter functions:
+
+.. code-block:: cpp
+
+        py::class_<Pet>(m, "Pet")
+            .def(py::init<const std::string &>())
+            .def_property("name", &Pet::getName, &Pet::setName)
+            // ... remainder ...
+
+Write only properties can be defined by passing ``nullptr`` as the
+input for the read function.
+
+.. seealso::
+
+    Similar functions :func:`class_::def_readwrite_static`,
+    :func:`class_::def_readonly_static` :func:`class_::def_property_static`,
+    and :func:`class_::def_property_readonly_static` are provided for binding
+    static variables and properties. Please also see the section on
+    :ref:`static_properties` in the advanced part of the documentation.
+
+Dynamic attributes
+==================
+
+Native Python classes can pick up new attributes dynamically:
+
+.. code-block:: pycon
+
+    >>> class Pet:
+    ...     name = "Molly"
+    ...
+    >>> p = Pet()
+    >>> p.name = "Charly"  # overwrite existing
+    >>> p.age = 2  # dynamically add a new attribute
+
+By default, classes exported from C++ do not support this and the only writable
+attributes are the ones explicitly defined using :func:`class_::def_readwrite`
+or :func:`class_::def_property`.
+
+.. code-block:: cpp
+
+    py::class_<Pet>(m, "Pet")
+        .def(py::init<>())
+        .def_readwrite("name", &Pet::name);
+
+Trying to set any other attribute results in an error:
+
+.. code-block:: pycon
+
+    >>> p = example.Pet()
+    >>> p.name = "Charly"  # OK, attribute defined in C++
+    >>> p.age = 2  # fail
+    AttributeError: 'Pet' object has no attribute 'age'
+
+To enable dynamic attributes for C++ classes, the :class:`py::dynamic_attr` tag
+must be added to the :class:`py::class_` constructor:
+
+.. code-block:: cpp
+
+    py::class_<Pet>(m, "Pet", py::dynamic_attr())
+        .def(py::init<>())
+        .def_readwrite("name", &Pet::name);
+
+Now everything works as expected:
+
+.. code-block:: pycon
+
+    >>> p = example.Pet()
+    >>> p.name = "Charly"  # OK, overwrite value in C++
+    >>> p.age = 2  # OK, dynamically add a new attribute
+    >>> p.__dict__  # just like a native Python class
+    {'age': 2}
+
+Note that there is a small runtime cost for a class with dynamic attributes.
+Not only because of the addition of a ``__dict__``, but also because of more
+expensive garbage collection tracking which must be activated to resolve
+possible circular references. Native Python classes incur this same cost by
+default, so this is not anything to worry about. By default, pybind11 classes
+are more efficient than native Python classes. Enabling dynamic attributes
+just brings them on par.
+
+.. _inheritance:
+
+Inheritance and automatic downcasting
+=====================================
+
+Suppose now that the example consists of two data structures with an
+inheritance relationship:
+
+.. code-block:: cpp
+
+    struct Pet {
+        Pet(const std::string &name) : name(name) { }
+        std::string name;
+    };
+
+    struct Dog : Pet {
+        Dog(const std::string &name) : Pet(name) { }
+        std::string bark() const { return "woof!"; }
+    };
+
+There are two different ways of indicating a hierarchical relationship to
+pybind11: the first specifies the C++ base class as an extra template
+parameter of the :class:`class_`:
+
+.. code-block:: cpp
+
+    py::class_<Pet>(m, "Pet")
+       .def(py::init<const std::string &>())
+       .def_readwrite("name", &Pet::name);
+
+    // Method 1: template parameter:
+    py::class_<Dog, Pet /* <- specify C++ parent type */>(m, "Dog")
+        .def(py::init<const std::string &>())
+        .def("bark", &Dog::bark);
+
+Alternatively, we can also assign a name to the previously bound ``Pet``
+:class:`class_` object and reference it when binding the ``Dog`` class:
+
+.. code-block:: cpp
+
+    py::class_<Pet> pet(m, "Pet");
+    pet.def(py::init<const std::string &>())
+       .def_readwrite("name", &Pet::name);
+
+    // Method 2: pass parent class_ object:
+    py::class_<Dog>(m, "Dog", pet /* <- specify Python parent type */)
+        .def(py::init<const std::string &>())
+        .def("bark", &Dog::bark);
+
+Functionality-wise, both approaches are equivalent. Afterwards, instances will
+expose fields and methods of both types:
+
+.. code-block:: pycon
+
+    >>> p = example.Dog("Molly")
+    >>> p.name
+    'Molly'
+    >>> p.bark()
+    'woof!'
+
+The C++ classes defined above are regular non-polymorphic types with an
+inheritance relationship. This is reflected in Python:
+
+.. code-block:: cpp
+
+    // Return a base pointer to a derived instance
+    m.def("pet_store", []() { return std::unique_ptr<Pet>(new Dog("Molly")); });
+
+.. code-block:: pycon
+
+    >>> p = example.pet_store()
+    >>> type(p)  # `Dog` instance behind `Pet` pointer
+    Pet          # no pointer downcasting for regular non-polymorphic types
+    >>> p.bark()
+    AttributeError: 'Pet' object has no attribute 'bark'
+
+The function returned a ``Dog`` instance, but because it's a non-polymorphic
+type behind a base pointer, Python only sees a ``Pet``. In C++, a type is only
+considered polymorphic if it has at least one virtual function and pybind11
+will automatically recognize this:
+
+.. code-block:: cpp
+
+    struct PolymorphicPet {
+        virtual ~PolymorphicPet() = default;
+    };
+
+    struct PolymorphicDog : PolymorphicPet {
+        std::string bark() const { return "woof!"; }
+    };
+
+    // Same binding code
+    py::class_<PolymorphicPet>(m, "PolymorphicPet");
+    py::class_<PolymorphicDog, PolymorphicPet>(m, "PolymorphicDog")
+        .def(py::init<>())
+        .def("bark", &PolymorphicDog::bark);
+
+    // Again, return a base pointer to a derived instance
+    m.def("pet_store2", []() { return std::unique_ptr<PolymorphicPet>(new PolymorphicDog); });
+
+.. code-block:: pycon
+
+    >>> p = example.pet_store2()
+    >>> type(p)
+    PolymorphicDog  # automatically downcast
+    >>> p.bark()
+    'woof!'
+
+Given a pointer to a polymorphic base, pybind11 performs automatic downcasting
+to the actual derived type. Note that this goes beyond the usual situation in
+C++: we don't just get access to the virtual functions of the base, we get the
+concrete derived type including functions and attributes that the base type may
+not even be aware of.
+
+.. seealso::
+
+    For more information about polymorphic behavior see :ref:`overriding_virtuals`.
+
+
+Overloaded methods
+==================
+
+Sometimes there are several overloaded C++ methods with the same name taking
+different kinds of input arguments:
+
+.. code-block:: cpp
+
+    struct Pet {
+        Pet(const std::string &name, int age) : name(name), age(age) { }
+
+        void set(int age_) { age = age_; }
+        void set(const std::string &name_) { name = name_; }
+
+        std::string name;
+        int age;
+    };
+
+Attempting to bind ``Pet::set`` will cause an error since the compiler does not
+know which method the user intended to select. We can disambiguate by casting
+them to function pointers. Binding multiple functions to the same Python name
+automatically creates a chain of function overloads that will be tried in
+sequence.
+
+.. code-block:: cpp
+
+    py::class_<Pet>(m, "Pet")
+       .def(py::init<const std::string &, int>())
+       .def("set", static_cast<void (Pet::*)(int)>(&Pet::set), "Set the pet's age")
+       .def("set", static_cast<void (Pet::*)(const std::string &)>(&Pet::set), "Set the pet's name");
+
+The overload signatures are also visible in the method's docstring:
+
+.. code-block:: pycon
+
+    >>> help(example.Pet)
+
+    class Pet(__builtin__.object)
+     |  Methods defined here:
+     |
+     |  __init__(...)
+     |      Signature : (Pet, str, int) -> NoneType
+     |
+     |  set(...)
+     |      1. Signature : (Pet, int) -> NoneType
+     |
+     |      Set the pet's age
+     |
+     |      2. Signature : (Pet, str) -> NoneType
+     |
+     |      Set the pet's name
+
+If you have a C++14 compatible compiler [#cpp14]_, you can use an alternative
+syntax to cast the overloaded function:
+
+.. code-block:: cpp
+
+    py::class_<Pet>(m, "Pet")
+        .def("set", py::overload_cast<int>(&Pet::set), "Set the pet's age")
+        .def("set", py::overload_cast<const std::string &>(&Pet::set), "Set the pet's name");
+
+Here, ``py::overload_cast`` only requires the parameter types to be specified.
+The return type and class are deduced. This avoids the additional noise of
+``void (Pet::*)()`` as seen in the raw cast. If a function is overloaded based
+on constness, the ``py::const_`` tag should be used:
+
+.. code-block:: cpp
+
+    struct Widget {
+        int foo(int x, float y);
+        int foo(int x, float y) const;
+    };
+
+    py::class_<Widget>(m, "Widget")
+       .def("foo_mutable", py::overload_cast<int, float>(&Widget::foo))
+       .def("foo_const",   py::overload_cast<int, float>(&Widget::foo, py::const_));
+
+If you prefer the ``py::overload_cast`` syntax but have a C++11 compatible compiler only,
+you can use ``py::detail::overload_cast_impl`` with an additional set of parentheses:
+
+.. code-block:: cpp
+
+    template <typename... Args>
+    using overload_cast_ = pybind11::detail::overload_cast_impl<Args...>;
+
+    py::class_<Pet>(m, "Pet")
+        .def("set", overload_cast_<int>()(&Pet::set), "Set the pet's age")
+        .def("set", overload_cast_<const std::string &>()(&Pet::set), "Set the pet's name");
+
+.. [#cpp14] A compiler which supports the ``-std=c++14`` flag.
+
+.. note::
+
+    To define multiple overloaded constructors, simply declare one after the
+    other using the ``.def(py::init<...>())`` syntax. The existing machinery
+    for specifying keyword and default arguments also works.
+
+Enumerations and internal types
+===============================
+
+Let's now suppose that the example class contains internal types like enumerations, e.g.:
+
+.. code-block:: cpp
+
+    struct Pet {
+        enum Kind {
+            Dog = 0,
+            Cat
+        };
+
+        struct Attributes {
+            float age = 0;
+        };
+
+        Pet(const std::string &name, Kind type) : name(name), type(type) { }
+
+        std::string name;
+        Kind type;
+        Attributes attr;
+    };
+
+The binding code for this example looks as follows:
+
+.. code-block:: cpp
+
+    py::class_<Pet> pet(m, "Pet");
+
+    pet.def(py::init<const std::string &, Pet::Kind>())
+        .def_readwrite("name", &Pet::name)
+        .def_readwrite("type", &Pet::type)
+        .def_readwrite("attr", &Pet::attr);
+
+    py::enum_<Pet::Kind>(pet, "Kind")
+        .value("Dog", Pet::Kind::Dog)
+        .value("Cat", Pet::Kind::Cat)
+        .export_values();
+
+    py::class_<Pet::Attributes>(pet, "Attributes")
+        .def(py::init<>())
+        .def_readwrite("age", &Pet::Attributes::age);
+
+
+To ensure that the nested types ``Kind`` and ``Attributes`` are created within the scope of ``Pet``, the
+``pet`` :class:`class_` instance must be supplied to the :class:`enum_` and :class:`class_`
+constructor. The :func:`enum_::export_values` function exports the enum entries
+into the parent scope, which should be skipped for newer C++11-style strongly
+typed enums.
+
+.. code-block:: pycon
+
+    >>> p = Pet("Lucy", Pet.Cat)
+    >>> p.type
+    Kind.Cat
+    >>> int(p.type)
+    1L
+
+The entries defined by the enumeration type are exposed in the ``__members__`` property:
+
+.. code-block:: pycon
+
+    >>> Pet.Kind.__members__
+    {'Dog': Kind.Dog, 'Cat': Kind.Cat}
+
+The ``name`` property returns the name of the enum value as a unicode string.
+
+.. note::
+
+    It is also possible to use ``str(enum)``, however these accomplish different
+    goals. The following shows how these two approaches differ.
+
+    .. code-block:: pycon
+
+        >>> p = Pet("Lucy", Pet.Cat)
+        >>> pet_type = p.type
+        >>> pet_type
+        Pet.Cat
+        >>> str(pet_type)
+        'Pet.Cat'
+        >>> pet_type.name
+        'Cat'
+
+.. note::
+
+    When the special tag ``py::arithmetic()`` is specified to the ``enum_``
+    constructor, pybind11 creates an enumeration that also supports rudimentary
+    arithmetic and bit-level operations like comparisons, and, or, xor, negation,
+    etc.
+
+    .. code-block:: cpp
+
+        py::enum_<Pet::Kind>(pet, "Kind", py::arithmetic())
+           ...
+
+    By default, these are omitted to conserve space.
+
+.. warning::
+
+    Contrary to Python customs, enum values from the wrappers should not be compared using ``is``, but with ``==`` (see `#1177 <https://github.com/pybind/pybind11/issues/1177>`_ for background).

third_party/CityFlow/extern/pybind11/docs/compiling.rst

@@ -1,649 +1,649 @@
-.. _compiling:
-
-Build systems
-#############
-
-.. _build-setuptools:
-
-Building with setuptools
-========================
-
-For projects on PyPI, building with setuptools is the way to go. Sylvain Corlay
-has kindly provided an example project which shows how to set up everything,
-including automatic generation of documentation using Sphinx. Please refer to
-the [python_example]_ repository.
-
-.. [python_example] https://github.com/pybind/python_example
-
-A helper file is provided with pybind11 that can simplify usage with setuptools.
-
-To use pybind11 inside your ``setup.py``, you have to have some system to
-ensure that ``pybind11`` is installed when you build your package. There are
-four possible ways to do this, and pybind11 supports all four: You can ask all
-users to install pybind11 beforehand (bad), you can use
-:ref:`setup_helpers-pep518` (good, but very new and requires Pip 10),
-:ref:`setup_helpers-setup_requires` (discouraged by Python packagers now that
-PEP 518 is available, but it still works everywhere), or you can
-:ref:`setup_helpers-copy-manually` (always works but you have to manually sync
-your copy to get updates).
-
-An example of a ``setup.py`` using pybind11's helpers:
-
-.. code-block:: python
-
-    from glob import glob
-    from setuptools import setup
-    from pybind11.setup_helpers import Pybind11Extension
-
-    ext_modules = [
-        Pybind11Extension(
-            "python_example",
-            sorted(glob("src/*.cpp")),  # Sort source files for reproducibility
-        ),
-    ]
-
-    setup(..., ext_modules=ext_modules)
-
-If you want to do an automatic search for the highest supported C++ standard,
-that is supported via a ``build_ext`` command override; it will only affect
-``Pybind11Extensions``:
-
-.. code-block:: python
-
-    from glob import glob
-    from setuptools import setup
-    from pybind11.setup_helpers import Pybind11Extension, build_ext
-
-    ext_modules = [
-        Pybind11Extension(
-            "python_example",
-            sorted(glob("src/*.cpp")),
-        ),
-    ]
-
-    setup(..., cmdclass={"build_ext": build_ext}, ext_modules=ext_modules)
-
-If you have single-file extension modules that are directly stored in the
-Python source tree (``foo.cpp`` in the same directory as where a ``foo.py``
-would be located), you can also generate ``Pybind11Extensions`` using
-``setup_helpers.intree_extensions``: ``intree_extensions(["path/to/foo.cpp",
-...])`` returns a list of ``Pybind11Extensions`` which can be passed to
-``ext_modules``, possibly after further customizing their attributes
-(``libraries``, ``include_dirs``, etc.).  By doing so, a ``foo.*.so`` extension
-module will be generated and made available upon installation.
-
-``intree_extension`` will automatically detect if you are using a ``src``-style
-layout (as long as no namespace packages are involved), but you can also
-explicitly pass ``package_dir`` to it (as in ``setuptools.setup``).
-
-Since pybind11 does not require NumPy when building, a light-weight replacement
-for NumPy's parallel compilation distutils tool is included. Use it like this:
-
-.. code-block:: python
-
-    from pybind11.setup_helpers import ParallelCompile
-
-    # Optional multithreaded build
-    ParallelCompile("NPY_NUM_BUILD_JOBS").install()
-
-    setup(...)
-
-The argument is the name of an environment variable to control the number of
-threads, such as ``NPY_NUM_BUILD_JOBS`` (as used by NumPy), though you can set
-something different if you want; ``CMAKE_BUILD_PARALLEL_LEVEL`` is another choice
-a user might expect. You can also pass ``default=N`` to set the default number
-of threads (0 will take the number of threads available) and ``max=N``, the
-maximum number of threads; if you have a large extension you may want set this
-to a memory dependent number.
-
-If you are developing rapidly and have a lot of C++ files, you may want to
-avoid rebuilding files that have not changed. For simple cases were you are
-using ``pip install -e .`` and do not have local headers, you can skip the
-rebuild if an object file is newer than its source (headers are not checked!)
-with the following:
-
-.. code-block:: python
-
-    from pybind11.setup_helpers import ParallelCompile, naive_recompile
-
-    ParallelCompile("NPY_NUM_BUILD_JOBS", needs_recompile=naive_recompile).install()
-
-
-If you have a more complex build, you can implement a smarter function and pass
-it to ``needs_recompile``, or you can use [Ccache]_ instead. ``CXX="cache g++"
-pip install -e .`` would be the way to use it with GCC, for example. Unlike the
-simple solution, this even works even when not compiling in editable mode, but
-it does require Ccache to be installed.
-
-Keep in mind that Pip will not even attempt to rebuild if it thinks it has
-already built a copy of your code, which it deduces from the version number.
-One way to avoid this is to use [setuptools_scm]_, which will generate a
-version number that includes the number of commits since your last tag and a
-hash for a dirty directory. Another way to force a rebuild is purge your cache
-or use Pip's ``--no-cache-dir`` option.
-
-.. [Ccache] https://ccache.dev
-
-.. [setuptools_scm] https://github.com/pypa/setuptools_scm
-
-.. _setup_helpers-pep518:
-
-PEP 518 requirements (Pip 10+ required)
----------------------------------------
-
-If you use `PEP 518's <https://www.python.org/dev/peps/pep-0518/>`_
-``pyproject.toml`` file, you can ensure that ``pybind11`` is available during
-the compilation of your project.  When this file exists, Pip will make a new
-virtual environment, download just the packages listed here in ``requires=``,
-and build a wheel (binary Python package). It will then throw away the
-environment, and install your wheel.
-
-Your ``pyproject.toml`` file will likely look something like this:
-
-.. code-block:: toml
-
-    [build-system]
-    requires = ["setuptools>=42", "pybind11>=2.6.1"]
-    build-backend = "setuptools.build_meta"
-
-.. note::
-
-    The main drawback to this method is that a `PEP 517`_ compliant build tool,
-    such as Pip 10+, is required for this approach to work; older versions of
-    Pip completely ignore this file. If you distribute binaries (called wheels
-    in Python) using something like `cibuildwheel`_, remember that ``setup.py``
-    and ``pyproject.toml`` are not even contained in the wheel, so this high
-    Pip requirement is only for source builds, and will not affect users of
-    your binary wheels. If you are building SDists and wheels, then
-    `pypa-build`_ is the recommended official tool.
-
-.. _PEP 517: https://www.python.org/dev/peps/pep-0517/
-.. _cibuildwheel: https://cibuildwheel.readthedocs.io
-.. _pypa-build: https://pypa-build.readthedocs.io/en/latest/
-
-.. _setup_helpers-setup_requires:
-
-Classic ``setup_requires``
---------------------------
-
-If you want to support old versions of Pip with the classic
-``setup_requires=["pybind11"]`` keyword argument to setup, which triggers a
-two-phase ``setup.py`` run, then you will need to use something like this to
-ensure the first pass works (which has not yet installed the ``setup_requires``
-packages, since it can't install something it does not know about):
-
-.. code-block:: python
-
-    try:
-        from pybind11.setup_helpers import Pybind11Extension
-    except ImportError:
-        from setuptools import Extension as Pybind11Extension
-
-
-It doesn't matter that the Extension class is not the enhanced subclass for the
-first pass run; and the second pass will have the ``setup_requires``
-requirements.
-
-This is obviously more of a hack than the PEP 518 method, but it supports
-ancient versions of Pip.
-
-.. _setup_helpers-copy-manually:
-
-Copy manually
--------------
-
-You can also copy ``setup_helpers.py`` directly to your project; it was
-designed to be usable standalone, like the old example ``setup.py``. You can
-set ``include_pybind11=False`` to skip including the pybind11 package headers,
-so you can use it with git submodules and a specific git version. If you use
-this, you will need to import from a local file in ``setup.py`` and ensure the
-helper file is part of your MANIFEST.
-
-
-Closely related, if you include pybind11 as a subproject, you can run the
-``setup_helpers.py`` inplace. If loaded correctly, this should even pick up
-the correct include for pybind11, though you can turn it off as shown above if
-you want to input it manually.
-
-Suggested usage if you have pybind11 as a submodule in ``extern/pybind11``:
-
-.. code-block:: python
-
-    DIR = os.path.abspath(os.path.dirname(__file__))
-
-    sys.path.append(os.path.join(DIR, "extern", "pybind11"))
-    from pybind11.setup_helpers import Pybind11Extension  # noqa: E402
-
-    del sys.path[-1]
-
-
-.. versionchanged:: 2.6
-
-    Added ``setup_helpers`` file.
-
-Building with cppimport
-========================
-
-[cppimport]_ is a small Python import hook that determines whether there is a C++
-source file whose name matches the requested module. If there is, the file is
-compiled as a Python extension using pybind11 and placed in the same folder as
-the C++ source file. Python is then able to find the module and load it.
-
-.. [cppimport] https://github.com/tbenthompson/cppimport
-
-.. _cmake:
-
-Building with CMake
-===================
-
-For C++ codebases that have an existing CMake-based build system, a Python
-extension module can be created with just a few lines of code:
-
-.. code-block:: cmake
-
-    cmake_minimum_required(VERSION 3.5...3.27)
-    project(example LANGUAGES CXX)
-
-    add_subdirectory(pybind11)
-    pybind11_add_module(example example.cpp)
-
-This assumes that the pybind11 repository is located in a subdirectory named
-:file:`pybind11` and that the code is located in a file named :file:`example.cpp`.
-The CMake command ``add_subdirectory`` will import the pybind11 project which
-provides the ``pybind11_add_module`` function. It will take care of all the
-details needed to build a Python extension module on any platform.
-
-A working sample project, including a way to invoke CMake from :file:`setup.py` for
-PyPI integration, can be found in the [cmake_example]_  repository.
-
-.. [cmake_example] https://github.com/pybind/cmake_example
-
-.. versionchanged:: 2.6
-   CMake 3.4+ is required.
-
-.. versionchanged:: 2.11
-   CMake 3.5+ is required.
-
-Further information can be found at :doc:`cmake/index`.
-
-pybind11_add_module
--------------------
-
-To ease the creation of Python extension modules, pybind11 provides a CMake
-function with the following signature:
-
-.. code-block:: cmake
-
-    pybind11_add_module(<name> [MODULE | SHARED] [EXCLUDE_FROM_ALL]
-                        [NO_EXTRAS] [THIN_LTO] [OPT_SIZE] source1 [source2 ...])
-
-This function behaves very much like CMake's builtin ``add_library`` (in fact,
-it's a wrapper function around that command). It will add a library target
-called ``<name>`` to be built from the listed source files. In addition, it
-will take care of all the Python-specific compiler and linker flags as well
-as the OS- and Python-version-specific file extension. The produced target
-``<name>`` can be further manipulated with regular CMake commands.
-
-``MODULE`` or ``SHARED`` may be given to specify the type of library. If no
-type is given, ``MODULE`` is used by default which ensures the creation of a
-Python-exclusive module. Specifying ``SHARED`` will create a more traditional
-dynamic library which can also be linked from elsewhere. ``EXCLUDE_FROM_ALL``
-removes this target from the default build (see CMake docs for details).
-
-Since pybind11 is a template library, ``pybind11_add_module`` adds compiler
-flags to ensure high quality code generation without bloat arising from long
-symbol names and duplication of code in different translation units. It
-sets default visibility to *hidden*, which is required for some pybind11
-features and functionality when attempting to load multiple pybind11 modules
-compiled under different pybind11 versions.  It also adds additional flags
-enabling LTO (Link Time Optimization) and strip unneeded symbols. See the
-:ref:`FAQ entry <faq:symhidden>` for a more detailed explanation. These
-latter optimizations are never applied in ``Debug`` mode.  If ``NO_EXTRAS`` is
-given, they will always be disabled, even in ``Release`` mode. However, this
-will result in code bloat and is generally not recommended.
-
-As stated above, LTO is enabled by default. Some newer compilers also support
-different flavors of LTO such as `ThinLTO`_. Setting ``THIN_LTO`` will cause
-the function to prefer this flavor if available. The function falls back to
-regular LTO if ``-flto=thin`` is not available. If
-``CMAKE_INTERPROCEDURAL_OPTIMIZATION`` is set (either ``ON`` or ``OFF``), then
-that will be respected instead of the built-in flag search.
-
-.. note::
-
-   If you want to set the property form on targets or the
-   ``CMAKE_INTERPROCEDURAL_OPTIMIZATION_<CONFIG>`` versions of this, you should
-   still use ``set(CMAKE_INTERPROCEDURAL_OPTIMIZATION OFF)`` (otherwise a
-   no-op) to disable pybind11's ipo flags.
-
-The ``OPT_SIZE`` flag enables size-based optimization equivalent to the
-standard ``/Os`` or ``-Os`` compiler flags and the ``MinSizeRel`` build type,
-which avoid optimizations that that can substantially increase the size of the
-resulting binary. This flag is particularly useful in projects that are split
-into performance-critical parts and associated bindings. In this case, we can
-compile the project in release mode (and hence, optimize performance globally),
-and specify ``OPT_SIZE`` for the binding target, where size might be the main
-concern as performance is often less critical here. A ~25% size reduction has
-been observed in practice. This flag only changes the optimization behavior at
-a per-target level and takes precedence over the global CMake build type
-(``Release``, ``RelWithDebInfo``) except for ``Debug`` builds, where
-optimizations remain disabled.
-
-.. _ThinLTO: http://clang.llvm.org/docs/ThinLTO.html
-
-Configuration variables
------------------------
-
-By default, pybind11 will compile modules with the compiler default or the
-minimum standard required by pybind11, whichever is higher.  You can set the
-standard explicitly with
-`CMAKE_CXX_STANDARD <https://cmake.org/cmake/help/latest/variable/CMAKE_CXX_STANDARD.html>`_:
-
-.. code-block:: cmake
-
-    set(CMAKE_CXX_STANDARD 14 CACHE STRING "C++ version selection")  # or 11, 14, 17, 20
-    set(CMAKE_CXX_STANDARD_REQUIRED ON)  # optional, ensure standard is supported
-    set(CMAKE_CXX_EXTENSIONS OFF)  # optional, keep compiler extensions off
-
-The variables can also be set when calling CMake from the command line using
-the ``-D<variable>=<value>`` flag. You can also manually set ``CXX_STANDARD``
-on a target or use ``target_compile_features`` on your targets - anything that
-CMake supports.
-
-Classic Python support: The target Python version can be selected by setting
-``PYBIND11_PYTHON_VERSION`` or an exact Python installation can be specified
-with ``PYTHON_EXECUTABLE``.  For example:
-
-.. code-block:: bash
-
-    cmake -DPYBIND11_PYTHON_VERSION=3.6 ..
-
-    # Another method:
-    cmake -DPYTHON_EXECUTABLE=/path/to/python ..
-
-    # This often is a good way to get the current Python, works in environments:
-    cmake -DPYTHON_EXECUTABLE=$(python3 -c "import sys; print(sys.executable)") ..
-
-
-find_package vs. add_subdirectory
----------------------------------
-
-For CMake-based projects that don't include the pybind11 repository internally,
-an external installation can be detected through ``find_package(pybind11)``.
-See the `Config file`_ docstring for details of relevant CMake variables.
-
-.. code-block:: cmake
-
-    cmake_minimum_required(VERSION 3.4...3.18)
-    project(example LANGUAGES CXX)
-
-    find_package(pybind11 REQUIRED)
-    pybind11_add_module(example example.cpp)
-
-Note that ``find_package(pybind11)`` will only work correctly if pybind11
-has been correctly installed on the system, e. g. after downloading or cloning
-the pybind11 repository  :
-
-.. code-block:: bash
-
-    # Classic CMake
-    cd pybind11
-    mkdir build
-    cd build
-    cmake ..
-    make install
-
-    # CMake 3.15+
-    cd pybind11
-    cmake -S . -B build
-    cmake --build build -j 2  # Build on 2 cores
-    cmake --install build
-
-Once detected, the aforementioned ``pybind11_add_module`` can be employed as
-before. The function usage and configuration variables are identical no matter
-if pybind11 is added as a subdirectory or found as an installed package. You
-can refer to the same [cmake_example]_ repository for a full sample project
--- just swap out ``add_subdirectory`` for ``find_package``.
-
-.. _Config file: https://github.com/pybind/pybind11/blob/master/tools/pybind11Config.cmake.in
-
-
-.. _find-python-mode:
-
-FindPython mode
----------------
-
-CMake 3.12+ (3.15+ recommended, 3.18.2+ ideal) added a new module called
-FindPython that had a highly improved search algorithm and modern targets
-and tools. If you use FindPython, pybind11 will detect this and use the
-existing targets instead:
-
-.. code-block:: cmake
-
-    cmake_minimum_required(VERSION 3.15...3.22)
-    project(example LANGUAGES CXX)
-
-    find_package(Python 3.6 COMPONENTS Interpreter Development REQUIRED)
-    find_package(pybind11 CONFIG REQUIRED)
-    # or add_subdirectory(pybind11)
-
-    pybind11_add_module(example example.cpp)
-
-You can also use the targets (as listed below) with FindPython. If you define
-``PYBIND11_FINDPYTHON``, pybind11 will perform the FindPython step for you
-(mostly useful when building pybind11's own tests, or as a way to change search
-algorithms from the CMake invocation, with ``-DPYBIND11_FINDPYTHON=ON``.
-
-.. warning::
-
-    If you use FindPython to multi-target Python versions, use the individual
-    targets listed below, and avoid targets that directly include Python parts.
-
-There are `many ways to hint or force a discovery of a specific Python
-installation <https://cmake.org/cmake/help/latest/module/FindPython.html>`_),
-setting ``Python_ROOT_DIR`` may be the most common one (though with
-virtualenv/venv support, and Conda support, this tends to find the correct
-Python version more often than the old system did).
-
-.. warning::
-
-    When the Python libraries (i.e. ``libpythonXX.a`` and ``libpythonXX.so``
-    on Unix) are not available, as is the case on a manylinux image, the
-    ``Development`` component will not be resolved by ``FindPython``. When not
-    using the embedding functionality, CMake 3.18+ allows you to specify
-    ``Development.Module`` instead of ``Development`` to resolve this issue.
-
-.. versionadded:: 2.6
-
-Advanced: interface library targets
------------------------------------
-
-Pybind11 supports modern CMake usage patterns with a set of interface targets,
-available in all modes. The targets provided are:
-
-   ``pybind11::headers``
-     Just the pybind11 headers and minimum compile requirements
-
-   ``pybind11::pybind11``
-     Python headers + ``pybind11::headers``
-
-   ``pybind11::python_link_helper``
-     Just the "linking" part of pybind11:module
-
-   ``pybind11::module``
-     Everything for extension modules - ``pybind11::pybind11`` + ``Python::Module`` (FindPython CMake 3.15+) or ``pybind11::python_link_helper``
-
-   ``pybind11::embed``
-     Everything for embedding the Python interpreter - ``pybind11::pybind11`` + ``Python::Python`` (FindPython) or Python libs
-
-   ``pybind11::lto`` / ``pybind11::thin_lto``
-     An alternative to `INTERPROCEDURAL_OPTIMIZATION` for adding link-time optimization.
-
-   ``pybind11::windows_extras``
-     ``/bigobj`` and ``/mp`` for MSVC.
-
-   ``pybind11::opt_size``
-     ``/Os`` for MSVC, ``-Os`` for other compilers. Does nothing for debug builds.
-
-Two helper functions are also provided:
-
-    ``pybind11_strip(target)``
-      Strips a target (uses ``CMAKE_STRIP`` after the target is built)
-
-    ``pybind11_extension(target)``
-      Sets the correct extension (with SOABI) for a target.
-
-You can use these targets to build complex applications. For example, the
-``add_python_module`` function is identical to:
-
-.. code-block:: cmake
-
-    cmake_minimum_required(VERSION 3.5...3.27)
-    project(example LANGUAGES CXX)
-
-    find_package(pybind11 REQUIRED)  # or add_subdirectory(pybind11)
-
-    add_library(example MODULE main.cpp)
-
-    target_link_libraries(example PRIVATE pybind11::module pybind11::lto pybind11::windows_extras)
-
-    pybind11_extension(example)
-    if(NOT MSVC AND NOT ${CMAKE_BUILD_TYPE} MATCHES Debug|RelWithDebInfo)
-        # Strip unnecessary sections of the binary on Linux/macOS
-        pybind11_strip(example)
-    endif()
-
-    set_target_properties(example PROPERTIES CXX_VISIBILITY_PRESET "hidden"
-                                             CUDA_VISIBILITY_PRESET "hidden")
-
-Instead of setting properties, you can set ``CMAKE_*`` variables to initialize these correctly.
-
-.. warning::
-
-    Since pybind11 is a metatemplate library, it is crucial that certain
-    compiler flags are provided to ensure high quality code generation. In
-    contrast to the ``pybind11_add_module()`` command, the CMake interface
-    provides a *composable* set of targets to ensure that you retain flexibility.
-    It can be especially important to provide or set these properties; the
-    :ref:`FAQ <faq:symhidden>` contains an explanation on why these are needed.
-
-.. versionadded:: 2.6
-
-.. _nopython-mode:
-
-Advanced: NOPYTHON mode
------------------------
-
-If you want complete control, you can set ``PYBIND11_NOPYTHON`` to completely
-disable Python integration (this also happens if you run ``FindPython2`` and
-``FindPython3`` without running ``FindPython``). This gives you complete
-freedom to integrate into an existing system (like `Scikit-Build's
-<https://scikit-build.readthedocs.io>`_ ``PythonExtensions``).
-``pybind11_add_module`` and ``pybind11_extension`` will be unavailable, and the
-targets will be missing any Python specific behavior.
-
-.. versionadded:: 2.6
-
-Embedding the Python interpreter
---------------------------------
-
-In addition to extension modules, pybind11 also supports embedding Python into
-a C++ executable or library. In CMake, simply link with the ``pybind11::embed``
-target. It provides everything needed to get the interpreter running. The Python
-headers and libraries are attached to the target. Unlike ``pybind11::module``,
-there is no need to manually set any additional properties here. For more
-information about usage in C++, see :doc:`/advanced/embedding`.
-
-.. code-block:: cmake
-
-    cmake_minimum_required(VERSION 3.5...3.27)
-    project(example LANGUAGES CXX)
-
-    find_package(pybind11 REQUIRED)  # or add_subdirectory(pybind11)
-
-    add_executable(example main.cpp)
-    target_link_libraries(example PRIVATE pybind11::embed)
-
-.. _building_manually:
-
-Building manually
-=================
-
-pybind11 is a header-only library, hence it is not necessary to link against
-any special libraries and there are no intermediate (magic) translation steps.
-
-On Linux, you can compile an example such as the one given in
-:ref:`simple_example` using the following command:
-
-.. code-block:: bash
-
-    $ c++ -O3 -Wall -shared -std=c++11 -fPIC $(python3 -m pybind11 --includes) example.cpp -o example$(python3-config --extension-suffix)
-
-The ``python3 -m pybind11 --includes`` command fetches the include paths for
-both pybind11 and Python headers. This assumes that pybind11 has been installed
-using ``pip`` or ``conda``. If it hasn't, you can also manually specify
-``-I <path-to-pybind11>/include`` together with the Python includes path
-``python3-config --includes``.
-
-On macOS: the build command is almost the same but it also requires passing
-the ``-undefined dynamic_lookup`` flag so as to ignore missing symbols when
-building the module:
-
-.. code-block:: bash
-
-    $ c++ -O3 -Wall -shared -std=c++11 -undefined dynamic_lookup $(python3 -m pybind11 --includes) example.cpp -o example$(python3-config --extension-suffix)
-
-In general, it is advisable to include several additional build parameters
-that can considerably reduce the size of the created binary. Refer to section
-:ref:`cmake` for a detailed example of a suitable cross-platform CMake-based
-build system that works on all platforms including Windows.
-
-.. note::
-
-    On Linux and macOS, it's better to (intentionally) not link against
-    ``libpython``. The symbols will be resolved when the extension library
-    is loaded into a Python binary. This is preferable because you might
-    have several different installations of a given Python version (e.g. the
-    system-provided Python, and one that ships with a piece of commercial
-    software). In this way, the plugin will work with both versions, instead
-    of possibly importing a second Python library into a process that already
-    contains one (which will lead to a segfault).
-
-
-Building with Bazel
-===================
-
-You can build with the Bazel build system using the `pybind11_bazel
-<https://github.com/pybind/pybind11_bazel>`_ repository.
-
-Generating binding code automatically
-=====================================
-
-The ``Binder`` project is a tool for automatic generation of pybind11 binding
-code by introspecting existing C++ codebases using LLVM/Clang. See the
-[binder]_ documentation for details.
-
-.. [binder] http://cppbinder.readthedocs.io/en/latest/about.html
-
-[AutoWIG]_ is a Python library that wraps automatically compiled libraries into
-high-level languages. It parses C++ code using LLVM/Clang technologies and
-generates the wrappers using the Mako templating engine. The approach is automatic,
-extensible, and applies to very complex C++ libraries, composed of thousands of
-classes or incorporating modern meta-programming constructs.
-
-.. [AutoWIG] https://github.com/StatisKit/AutoWIG
-
-[robotpy-build]_ is a is a pure python, cross platform build tool that aims to
-simplify creation of python wheels for pybind11 projects, and provide
-cross-project dependency management. Additionally, it is able to autogenerate
-customizable pybind11-based wrappers by parsing C++ header files.
-
-.. [robotpy-build] https://robotpy-build.readthedocs.io
-
-[litgen]_ is an automatic python bindings generator with a focus on generating
-documented and discoverable bindings: bindings will nicely reproduce the documentation
-found in headers. It is is based on srcML (srcml.org), a highly scalable, multi-language
-parsing tool with a developer centric approach. The API that you want to expose to python
-must be C++14 compatible (but your implementation can use more modern constructs).
-
-.. [litgen] https://pthom.github.io/litgen
+.. _compiling:
+
+Build systems
+#############
+
+.. _build-setuptools:
+
+Building with setuptools
+========================
+
+For projects on PyPI, building with setuptools is the way to go. Sylvain Corlay
+has kindly provided an example project which shows how to set up everything,
+including automatic generation of documentation using Sphinx. Please refer to
+the [python_example]_ repository.
+
+.. [python_example] https://github.com/pybind/python_example
+
+A helper file is provided with pybind11 that can simplify usage with setuptools.
+
+To use pybind11 inside your ``setup.py``, you have to have some system to
+ensure that ``pybind11`` is installed when you build your package. There are
+four possible ways to do this, and pybind11 supports all four: You can ask all
+users to install pybind11 beforehand (bad), you can use
+:ref:`setup_helpers-pep518` (good, but very new and requires Pip 10),
+:ref:`setup_helpers-setup_requires` (discouraged by Python packagers now that
+PEP 518 is available, but it still works everywhere), or you can
+:ref:`setup_helpers-copy-manually` (always works but you have to manually sync
+your copy to get updates).
+
+An example of a ``setup.py`` using pybind11's helpers:
+
+.. code-block:: python
+
+    from glob import glob
+    from setuptools import setup
+    from pybind11.setup_helpers import Pybind11Extension
+
+    ext_modules = [
+        Pybind11Extension(
+            "python_example",
+            sorted(glob("src/*.cpp")),  # Sort source files for reproducibility
+        ),
+    ]
+
+    setup(..., ext_modules=ext_modules)
+
+If you want to do an automatic search for the highest supported C++ standard,
+that is supported via a ``build_ext`` command override; it will only affect
+``Pybind11Extensions``:
+
+.. code-block:: python
+
+    from glob import glob
+    from setuptools import setup
+    from pybind11.setup_helpers import Pybind11Extension, build_ext
+
+    ext_modules = [
+        Pybind11Extension(
+            "python_example",
+            sorted(glob("src/*.cpp")),
+        ),
+    ]
+
+    setup(..., cmdclass={"build_ext": build_ext}, ext_modules=ext_modules)
+
+If you have single-file extension modules that are directly stored in the
+Python source tree (``foo.cpp`` in the same directory as where a ``foo.py``
+would be located), you can also generate ``Pybind11Extensions`` using
+``setup_helpers.intree_extensions``: ``intree_extensions(["path/to/foo.cpp",
+...])`` returns a list of ``Pybind11Extensions`` which can be passed to
+``ext_modules``, possibly after further customizing their attributes
+(``libraries``, ``include_dirs``, etc.).  By doing so, a ``foo.*.so`` extension
+module will be generated and made available upon installation.
+
+``intree_extension`` will automatically detect if you are using a ``src``-style
+layout (as long as no namespace packages are involved), but you can also
+explicitly pass ``package_dir`` to it (as in ``setuptools.setup``).
+
+Since pybind11 does not require NumPy when building, a light-weight replacement
+for NumPy's parallel compilation distutils tool is included. Use it like this:
+
+.. code-block:: python
+
+    from pybind11.setup_helpers import ParallelCompile
+
+    # Optional multithreaded build
+    ParallelCompile("NPY_NUM_BUILD_JOBS").install()
+
+    setup(...)
+
+The argument is the name of an environment variable to control the number of
+threads, such as ``NPY_NUM_BUILD_JOBS`` (as used by NumPy), though you can set
+something different if you want; ``CMAKE_BUILD_PARALLEL_LEVEL`` is another choice
+a user might expect. You can also pass ``default=N`` to set the default number
+of threads (0 will take the number of threads available) and ``max=N``, the
+maximum number of threads; if you have a large extension you may want set this
+to a memory dependent number.
+
+If you are developing rapidly and have a lot of C++ files, you may want to
+avoid rebuilding files that have not changed. For simple cases were you are
+using ``pip install -e .`` and do not have local headers, you can skip the
+rebuild if an object file is newer than its source (headers are not checked!)
+with the following:
+
+.. code-block:: python
+
+    from pybind11.setup_helpers import ParallelCompile, naive_recompile
+
+    ParallelCompile("NPY_NUM_BUILD_JOBS", needs_recompile=naive_recompile).install()
+
+
+If you have a more complex build, you can implement a smarter function and pass
+it to ``needs_recompile``, or you can use [Ccache]_ instead. ``CXX="cache g++"
+pip install -e .`` would be the way to use it with GCC, for example. Unlike the
+simple solution, this even works even when not compiling in editable mode, but
+it does require Ccache to be installed.
+
+Keep in mind that Pip will not even attempt to rebuild if it thinks it has
+already built a copy of your code, which it deduces from the version number.
+One way to avoid this is to use [setuptools_scm]_, which will generate a
+version number that includes the number of commits since your last tag and a
+hash for a dirty directory. Another way to force a rebuild is purge your cache
+or use Pip's ``--no-cache-dir`` option.
+
+.. [Ccache] https://ccache.dev
+
+.. [setuptools_scm] https://github.com/pypa/setuptools_scm
+
+.. _setup_helpers-pep518:
+
+PEP 518 requirements (Pip 10+ required)
+---------------------------------------
+
+If you use `PEP 518's <https://www.python.org/dev/peps/pep-0518/>`_
+``pyproject.toml`` file, you can ensure that ``pybind11`` is available during
+the compilation of your project.  When this file exists, Pip will make a new
+virtual environment, download just the packages listed here in ``requires=``,
+and build a wheel (binary Python package). It will then throw away the
+environment, and install your wheel.
+
+Your ``pyproject.toml`` file will likely look something like this:
+
+.. code-block:: toml
+
+    [build-system]
+    requires = ["setuptools>=42", "pybind11>=2.6.1"]
+    build-backend = "setuptools.build_meta"
+
+.. note::
+
+    The main drawback to this method is that a `PEP 517`_ compliant build tool,
+    such as Pip 10+, is required for this approach to work; older versions of
+    Pip completely ignore this file. If you distribute binaries (called wheels
+    in Python) using something like `cibuildwheel`_, remember that ``setup.py``
+    and ``pyproject.toml`` are not even contained in the wheel, so this high
+    Pip requirement is only for source builds, and will not affect users of
+    your binary wheels. If you are building SDists and wheels, then
+    `pypa-build`_ is the recommended official tool.
+
+.. _PEP 517: https://www.python.org/dev/peps/pep-0517/
+.. _cibuildwheel: https://cibuildwheel.readthedocs.io
+.. _pypa-build: https://pypa-build.readthedocs.io/en/latest/
+
+.. _setup_helpers-setup_requires:
+
+Classic ``setup_requires``
+--------------------------
+
+If you want to support old versions of Pip with the classic
+``setup_requires=["pybind11"]`` keyword argument to setup, which triggers a
+two-phase ``setup.py`` run, then you will need to use something like this to
+ensure the first pass works (which has not yet installed the ``setup_requires``
+packages, since it can't install something it does not know about):
+
+.. code-block:: python
+
+    try:
+        from pybind11.setup_helpers import Pybind11Extension
+    except ImportError:
+        from setuptools import Extension as Pybind11Extension
+
+
+It doesn't matter that the Extension class is not the enhanced subclass for the
+first pass run; and the second pass will have the ``setup_requires``
+requirements.
+
+This is obviously more of a hack than the PEP 518 method, but it supports
+ancient versions of Pip.
+
+.. _setup_helpers-copy-manually:
+
+Copy manually
+-------------
+
+You can also copy ``setup_helpers.py`` directly to your project; it was
+designed to be usable standalone, like the old example ``setup.py``. You can
+set ``include_pybind11=False`` to skip including the pybind11 package headers,
+so you can use it with git submodules and a specific git version. If you use
+this, you will need to import from a local file in ``setup.py`` and ensure the
+helper file is part of your MANIFEST.
+
+
+Closely related, if you include pybind11 as a subproject, you can run the
+``setup_helpers.py`` inplace. If loaded correctly, this should even pick up
+the correct include for pybind11, though you can turn it off as shown above if
+you want to input it manually.
+
+Suggested usage if you have pybind11 as a submodule in ``extern/pybind11``:
+
+.. code-block:: python
+
+    DIR = os.path.abspath(os.path.dirname(__file__))
+
+    sys.path.append(os.path.join(DIR, "extern", "pybind11"))
+    from pybind11.setup_helpers import Pybind11Extension  # noqa: E402
+
+    del sys.path[-1]
+
+
+.. versionchanged:: 2.6
+
+    Added ``setup_helpers`` file.
+
+Building with cppimport
+========================
+
+[cppimport]_ is a small Python import hook that determines whether there is a C++
+source file whose name matches the requested module. If there is, the file is
+compiled as a Python extension using pybind11 and placed in the same folder as
+the C++ source file. Python is then able to find the module and load it.
+
+.. [cppimport] https://github.com/tbenthompson/cppimport
+
+.. _cmake:
+
+Building with CMake
+===================
+
+For C++ codebases that have an existing CMake-based build system, a Python
+extension module can be created with just a few lines of code:
+
+.. code-block:: cmake
+
+    cmake_minimum_required(VERSION 3.5...3.27)
+    project(example LANGUAGES CXX)
+
+    add_subdirectory(pybind11)
+    pybind11_add_module(example example.cpp)
+
+This assumes that the pybind11 repository is located in a subdirectory named
+:file:`pybind11` and that the code is located in a file named :file:`example.cpp`.
+The CMake command ``add_subdirectory`` will import the pybind11 project which
+provides the ``pybind11_add_module`` function. It will take care of all the
+details needed to build a Python extension module on any platform.
+
+A working sample project, including a way to invoke CMake from :file:`setup.py` for
+PyPI integration, can be found in the [cmake_example]_  repository.
+
+.. [cmake_example] https://github.com/pybind/cmake_example
+
+.. versionchanged:: 2.6
+   CMake 3.4+ is required.
+
+.. versionchanged:: 2.11
+   CMake 3.5+ is required.
+
+Further information can be found at :doc:`cmake/index`.
+
+pybind11_add_module
+-------------------
+
+To ease the creation of Python extension modules, pybind11 provides a CMake
+function with the following signature:
+
+.. code-block:: cmake
+
+    pybind11_add_module(<name> [MODULE | SHARED] [EXCLUDE_FROM_ALL]
+                        [NO_EXTRAS] [THIN_LTO] [OPT_SIZE] source1 [source2 ...])
+
+This function behaves very much like CMake's builtin ``add_library`` (in fact,
+it's a wrapper function around that command). It will add a library target
+called ``<name>`` to be built from the listed source files. In addition, it
+will take care of all the Python-specific compiler and linker flags as well
+as the OS- and Python-version-specific file extension. The produced target
+``<name>`` can be further manipulated with regular CMake commands.
+
+``MODULE`` or ``SHARED`` may be given to specify the type of library. If no
+type is given, ``MODULE`` is used by default which ensures the creation of a
+Python-exclusive module. Specifying ``SHARED`` will create a more traditional
+dynamic library which can also be linked from elsewhere. ``EXCLUDE_FROM_ALL``
+removes this target from the default build (see CMake docs for details).
+
+Since pybind11 is a template library, ``pybind11_add_module`` adds compiler
+flags to ensure high quality code generation without bloat arising from long
+symbol names and duplication of code in different translation units. It
+sets default visibility to *hidden*, which is required for some pybind11
+features and functionality when attempting to load multiple pybind11 modules
+compiled under different pybind11 versions.  It also adds additional flags
+enabling LTO (Link Time Optimization) and strip unneeded symbols. See the
+:ref:`FAQ entry <faq:symhidden>` for a more detailed explanation. These
+latter optimizations are never applied in ``Debug`` mode.  If ``NO_EXTRAS`` is
+given, they will always be disabled, even in ``Release`` mode. However, this
+will result in code bloat and is generally not recommended.
+
+As stated above, LTO is enabled by default. Some newer compilers also support
+different flavors of LTO such as `ThinLTO`_. Setting ``THIN_LTO`` will cause
+the function to prefer this flavor if available. The function falls back to
+regular LTO if ``-flto=thin`` is not available. If
+``CMAKE_INTERPROCEDURAL_OPTIMIZATION`` is set (either ``ON`` or ``OFF``), then
+that will be respected instead of the built-in flag search.
+
+.. note::
+
+   If you want to set the property form on targets or the
+   ``CMAKE_INTERPROCEDURAL_OPTIMIZATION_<CONFIG>`` versions of this, you should
+   still use ``set(CMAKE_INTERPROCEDURAL_OPTIMIZATION OFF)`` (otherwise a
+   no-op) to disable pybind11's ipo flags.
+
+The ``OPT_SIZE`` flag enables size-based optimization equivalent to the
+standard ``/Os`` or ``-Os`` compiler flags and the ``MinSizeRel`` build type,
+which avoid optimizations that that can substantially increase the size of the
+resulting binary. This flag is particularly useful in projects that are split
+into performance-critical parts and associated bindings. In this case, we can
+compile the project in release mode (and hence, optimize performance globally),
+and specify ``OPT_SIZE`` for the binding target, where size might be the main
+concern as performance is often less critical here. A ~25% size reduction has
+been observed in practice. This flag only changes the optimization behavior at
+a per-target level and takes precedence over the global CMake build type
+(``Release``, ``RelWithDebInfo``) except for ``Debug`` builds, where
+optimizations remain disabled.
+
+.. _ThinLTO: http://clang.llvm.org/docs/ThinLTO.html
+
+Configuration variables
+-----------------------
+
+By default, pybind11 will compile modules with the compiler default or the
+minimum standard required by pybind11, whichever is higher.  You can set the
+standard explicitly with
+`CMAKE_CXX_STANDARD <https://cmake.org/cmake/help/latest/variable/CMAKE_CXX_STANDARD.html>`_:
+
+.. code-block:: cmake
+
+    set(CMAKE_CXX_STANDARD 14 CACHE STRING "C++ version selection")  # or 11, 14, 17, 20
+    set(CMAKE_CXX_STANDARD_REQUIRED ON)  # optional, ensure standard is supported
+    set(CMAKE_CXX_EXTENSIONS OFF)  # optional, keep compiler extensions off
+
+The variables can also be set when calling CMake from the command line using
+the ``-D<variable>=<value>`` flag. You can also manually set ``CXX_STANDARD``
+on a target or use ``target_compile_features`` on your targets - anything that
+CMake supports.
+
+Classic Python support: The target Python version can be selected by setting
+``PYBIND11_PYTHON_VERSION`` or an exact Python installation can be specified
+with ``PYTHON_EXECUTABLE``.  For example:
+
+.. code-block:: bash
+
+    cmake -DPYBIND11_PYTHON_VERSION=3.6 ..
+
+    # Another method:
+    cmake -DPYTHON_EXECUTABLE=/path/to/python ..
+
+    # This often is a good way to get the current Python, works in environments:
+    cmake -DPYTHON_EXECUTABLE=$(python3 -c "import sys; print(sys.executable)") ..
+
+
+find_package vs. add_subdirectory
+---------------------------------
+
+For CMake-based projects that don't include the pybind11 repository internally,
+an external installation can be detected through ``find_package(pybind11)``.
+See the `Config file`_ docstring for details of relevant CMake variables.
+
+.. code-block:: cmake
+
+    cmake_minimum_required(VERSION 3.4...3.18)
+    project(example LANGUAGES CXX)
+
+    find_package(pybind11 REQUIRED)
+    pybind11_add_module(example example.cpp)
+
+Note that ``find_package(pybind11)`` will only work correctly if pybind11
+has been correctly installed on the system, e. g. after downloading or cloning
+the pybind11 repository  :
+
+.. code-block:: bash
+
+    # Classic CMake
+    cd pybind11
+    mkdir build
+    cd build
+    cmake ..
+    make install
+
+    # CMake 3.15+
+    cd pybind11
+    cmake -S . -B build
+    cmake --build build -j 2  # Build on 2 cores
+    cmake --install build
+
+Once detected, the aforementioned ``pybind11_add_module`` can be employed as
+before. The function usage and configuration variables are identical no matter
+if pybind11 is added as a subdirectory or found as an installed package. You
+can refer to the same [cmake_example]_ repository for a full sample project
+-- just swap out ``add_subdirectory`` for ``find_package``.
+
+.. _Config file: https://github.com/pybind/pybind11/blob/master/tools/pybind11Config.cmake.in
+
+
+.. _find-python-mode:
+
+FindPython mode
+---------------
+
+CMake 3.12+ (3.15+ recommended, 3.18.2+ ideal) added a new module called
+FindPython that had a highly improved search algorithm and modern targets
+and tools. If you use FindPython, pybind11 will detect this and use the
+existing targets instead:
+
+.. code-block:: cmake
+
+    cmake_minimum_required(VERSION 3.15...3.22)
+    project(example LANGUAGES CXX)
+
+    find_package(Python 3.6 COMPONENTS Interpreter Development REQUIRED)
+    find_package(pybind11 CONFIG REQUIRED)
+    # or add_subdirectory(pybind11)
+
+    pybind11_add_module(example example.cpp)
+
+You can also use the targets (as listed below) with FindPython. If you define
+``PYBIND11_FINDPYTHON``, pybind11 will perform the FindPython step for you
+(mostly useful when building pybind11's own tests, or as a way to change search
+algorithms from the CMake invocation, with ``-DPYBIND11_FINDPYTHON=ON``.
+
+.. warning::
+
+    If you use FindPython to multi-target Python versions, use the individual
+    targets listed below, and avoid targets that directly include Python parts.
+
+There are `many ways to hint or force a discovery of a specific Python
+installation <https://cmake.org/cmake/help/latest/module/FindPython.html>`_),
+setting ``Python_ROOT_DIR`` may be the most common one (though with
+virtualenv/venv support, and Conda support, this tends to find the correct
+Python version more often than the old system did).
+
+.. warning::
+
+    When the Python libraries (i.e. ``libpythonXX.a`` and ``libpythonXX.so``
+    on Unix) are not available, as is the case on a manylinux image, the
+    ``Development`` component will not be resolved by ``FindPython``. When not
+    using the embedding functionality, CMake 3.18+ allows you to specify
+    ``Development.Module`` instead of ``Development`` to resolve this issue.
+
+.. versionadded:: 2.6
+
+Advanced: interface library targets
+-----------------------------------
+
+Pybind11 supports modern CMake usage patterns with a set of interface targets,
+available in all modes. The targets provided are:
+
+   ``pybind11::headers``
+     Just the pybind11 headers and minimum compile requirements
+
+   ``pybind11::pybind11``
+     Python headers + ``pybind11::headers``
+
+   ``pybind11::python_link_helper``
+     Just the "linking" part of pybind11:module
+
+   ``pybind11::module``
+     Everything for extension modules - ``pybind11::pybind11`` + ``Python::Module`` (FindPython CMake 3.15+) or ``pybind11::python_link_helper``
+
+   ``pybind11::embed``
+     Everything for embedding the Python interpreter - ``pybind11::pybind11`` + ``Python::Python`` (FindPython) or Python libs
+
+   ``pybind11::lto`` / ``pybind11::thin_lto``
+     An alternative to `INTERPROCEDURAL_OPTIMIZATION` for adding link-time optimization.
+
+   ``pybind11::windows_extras``
+     ``/bigobj`` and ``/mp`` for MSVC.
+
+   ``pybind11::opt_size``
+     ``/Os`` for MSVC, ``-Os`` for other compilers. Does nothing for debug builds.
+
+Two helper functions are also provided:
+
+    ``pybind11_strip(target)``
+      Strips a target (uses ``CMAKE_STRIP`` after the target is built)
+
+    ``pybind11_extension(target)``
+      Sets the correct extension (with SOABI) for a target.
+
+You can use these targets to build complex applications. For example, the
+``add_python_module`` function is identical to:
+
+.. code-block:: cmake
+
+    cmake_minimum_required(VERSION 3.5...3.27)
+    project(example LANGUAGES CXX)
+
+    find_package(pybind11 REQUIRED)  # or add_subdirectory(pybind11)
+
+    add_library(example MODULE main.cpp)
+
+    target_link_libraries(example PRIVATE pybind11::module pybind11::lto pybind11::windows_extras)
+
+    pybind11_extension(example)
+    if(NOT MSVC AND NOT ${CMAKE_BUILD_TYPE} MATCHES Debug|RelWithDebInfo)
+        # Strip unnecessary sections of the binary on Linux/macOS
+        pybind11_strip(example)
+    endif()
+
+    set_target_properties(example PROPERTIES CXX_VISIBILITY_PRESET "hidden"
+                                             CUDA_VISIBILITY_PRESET "hidden")
+
+Instead of setting properties, you can set ``CMAKE_*`` variables to initialize these correctly.
+
+.. warning::
+
+    Since pybind11 is a metatemplate library, it is crucial that certain
+    compiler flags are provided to ensure high quality code generation. In
+    contrast to the ``pybind11_add_module()`` command, the CMake interface
+    provides a *composable* set of targets to ensure that you retain flexibility.
+    It can be especially important to provide or set these properties; the
+    :ref:`FAQ <faq:symhidden>` contains an explanation on why these are needed.
+
+.. versionadded:: 2.6
+
+.. _nopython-mode:
+
+Advanced: NOPYTHON mode
+-----------------------
+
+If you want complete control, you can set ``PYBIND11_NOPYTHON`` to completely
+disable Python integration (this also happens if you run ``FindPython2`` and
+``FindPython3`` without running ``FindPython``). This gives you complete
+freedom to integrate into an existing system (like `Scikit-Build's
+<https://scikit-build.readthedocs.io>`_ ``PythonExtensions``).
+``pybind11_add_module`` and ``pybind11_extension`` will be unavailable, and the
+targets will be missing any Python specific behavior.
+
+.. versionadded:: 2.6
+
+Embedding the Python interpreter
+--------------------------------
+
+In addition to extension modules, pybind11 also supports embedding Python into
+a C++ executable or library. In CMake, simply link with the ``pybind11::embed``
+target. It provides everything needed to get the interpreter running. The Python
+headers and libraries are attached to the target. Unlike ``pybind11::module``,
+there is no need to manually set any additional properties here. For more
+information about usage in C++, see :doc:`/advanced/embedding`.
+
+.. code-block:: cmake
+
+    cmake_minimum_required(VERSION 3.5...3.27)
+    project(example LANGUAGES CXX)
+
+    find_package(pybind11 REQUIRED)  # or add_subdirectory(pybind11)
+
+    add_executable(example main.cpp)
+    target_link_libraries(example PRIVATE pybind11::embed)
+
+.. _building_manually:
+
+Building manually
+=================
+
+pybind11 is a header-only library, hence it is not necessary to link against
+any special libraries and there are no intermediate (magic) translation steps.
+
+On Linux, you can compile an example such as the one given in
+:ref:`simple_example` using the following command:
+
+.. code-block:: bash
+
+    $ c++ -O3 -Wall -shared -std=c++11 -fPIC $(python3 -m pybind11 --includes) example.cpp -o example$(python3-config --extension-suffix)
+
+The ``python3 -m pybind11 --includes`` command fetches the include paths for
+both pybind11 and Python headers. This assumes that pybind11 has been installed
+using ``pip`` or ``conda``. If it hasn't, you can also manually specify
+``-I <path-to-pybind11>/include`` together with the Python includes path
+``python3-config --includes``.
+
+On macOS: the build command is almost the same but it also requires passing
+the ``-undefined dynamic_lookup`` flag so as to ignore missing symbols when
+building the module:
+
+.. code-block:: bash
+
+    $ c++ -O3 -Wall -shared -std=c++11 -undefined dynamic_lookup $(python3 -m pybind11 --includes) example.cpp -o example$(python3-config --extension-suffix)
+
+In general, it is advisable to include several additional build parameters
+that can considerably reduce the size of the created binary. Refer to section
+:ref:`cmake` for a detailed example of a suitable cross-platform CMake-based
+build system that works on all platforms including Windows.
+
+.. note::
+
+    On Linux and macOS, it's better to (intentionally) not link against
+    ``libpython``. The symbols will be resolved when the extension library
+    is loaded into a Python binary. This is preferable because you might
+    have several different installations of a given Python version (e.g. the
+    system-provided Python, and one that ships with a piece of commercial
+    software). In this way, the plugin will work with both versions, instead
+    of possibly importing a second Python library into a process that already
+    contains one (which will lead to a segfault).
+
+
+Building with Bazel
+===================
+
+You can build with the Bazel build system using the `pybind11_bazel
+<https://github.com/pybind/pybind11_bazel>`_ repository.
+
+Generating binding code automatically
+=====================================
+
+The ``Binder`` project is a tool for automatic generation of pybind11 binding
+code by introspecting existing C++ codebases using LLVM/Clang. See the
+[binder]_ documentation for details.
+
+.. [binder] http://cppbinder.readthedocs.io/en/latest/about.html
+
+[AutoWIG]_ is a Python library that wraps automatically compiled libraries into
+high-level languages. It parses C++ code using LLVM/Clang technologies and
+generates the wrappers using the Mako templating engine. The approach is automatic,
+extensible, and applies to very complex C++ libraries, composed of thousands of
+classes or incorporating modern meta-programming constructs.
+
+.. [AutoWIG] https://github.com/StatisKit/AutoWIG
+
+[robotpy-build]_ is a is a pure python, cross platform build tool that aims to
+simplify creation of python wheels for pybind11 projects, and provide
+cross-project dependency management. Additionally, it is able to autogenerate
+customizable pybind11-based wrappers by parsing C++ header files.
+
+.. [robotpy-build] https://robotpy-build.readthedocs.io
+
+[litgen]_ is an automatic python bindings generator with a focus on generating
+documented and discoverable bindings: bindings will nicely reproduce the documentation
+found in headers. It is is based on srcML (srcml.org), a highly scalable, multi-language
+parsing tool with a developer centric approach. The API that you want to expose to python
+must be C++14 compatible (but your implementation can use more modern constructs).
+
+.. [litgen] https://pthom.github.io/litgen

third_party/CityFlow/extern/pybind11/docs/conf.py

@@ -1,368 +1,368 @@
-#!/usr/bin/env python3
-#
-# pybind11 documentation build configuration file, created by
-# sphinx-quickstart on Sun Oct 11 19:23:48 2015.
-#
-# 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 os
-import re
-import subprocess
-import sys
-from pathlib import Path
-
-DIR = Path(__file__).parent.resolve()
-
-# 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 = [
-    "breathe",
-    "sphinx_copybutton",
-    "sphinxcontrib.rsvgconverter",
-    "sphinxcontrib.moderncmakedomain",
-]
-
-breathe_projects = {"pybind11": ".build/doxygenxml/"}
-breathe_default_project = "pybind11"
-breathe_domain_by_extension = {"h": "cpp"}
-
-# 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 = "pybind11"
-copyright = "2017, Wenzel Jakob"
-author = "Wenzel Jakob"
-
-# 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.
-
-# Read the listed version
-with open("../pybind11/_version.py") as f:
-    code = compile(f.read(), "../pybind11/_version.py", "exec")
-loc = {}
-exec(code, loc)
-
-# The full version, including alpha/beta/rc tags.
-version = loc["__version__"]
-
-# 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 = [".build", "release.rst"]
-
-# The reST default role (used for this markup: `text`) to use for all
-# documents.
-default_role = "any"
-
-# 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 = 'monokai'
-
-# 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 = False
-
-
-# -- 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 = "furo"
-
-# 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 = []
-
-# The name for this set of Sphinx documents.  If None, it defaults to
-# "<project> v<version> 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 (within the static path) to use as 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"]
-
-html_css_files = [
-    "css/custom.css",
-]
-
-# 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 = "pybind11doc"
-
-# -- Options for LaTeX output ---------------------------------------------
-
-latex_engine = "pdflatex"
-
-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.
-    # remove blank pages (between the title page and the TOC, etc.)
-    "classoptions": ",openany,oneside",
-    "preamble": r"""
-\usepackage{fontawesome}
-\usepackage{textgreek}
-\DeclareUnicodeCharacter{00A0}{}
-\DeclareUnicodeCharacter{2194}{\faArrowsH}
-\DeclareUnicodeCharacter{1F382}{\faBirthdayCake}
-\DeclareUnicodeCharacter{1F355}{\faAdjust}
-\DeclareUnicodeCharacter{0301}{'}
-\DeclareUnicodeCharacter{03C0}{\textpi}
-
-""",
-    # 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, "pybind11.tex", "pybind11 Documentation", "Wenzel Jakob", "manual"),
-]
-
-# The name of an image file (relative to this directory) to place at the top of
-# the title page.
-# latex_logo = 'pybind11-logo.png'
-
-# 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, "pybind11", "pybind11 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,
-        "pybind11",
-        "pybind11 Documentation",
-        author,
-        "pybind11",
-        "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
-
-primary_domain = "cpp"
-highlight_language = "cpp"
-
-
-def generate_doxygen_xml(app):
-    build_dir = os.path.join(app.confdir, ".build")
-    if not os.path.exists(build_dir):
-        os.mkdir(build_dir)
-
-    try:
-        subprocess.call(["doxygen", "--version"])
-        retcode = subprocess.call(["doxygen"], cwd=app.confdir)
-        if retcode < 0:
-            sys.stderr.write(f"doxygen error code: {-retcode}\n")
-    except OSError as e:
-        sys.stderr.write(f"doxygen execution failed: {e}\n")
-
-
-def prepare(app):
-    with open(DIR.parent / "README.rst") as f:
-        contents = f.read()
-
-    if app.builder.name == "latex":
-        # Remove badges and stuff from start
-        contents = contents[contents.find(r".. start") :]
-
-        # Filter out section titles for index.rst for LaTeX
-        contents = re.sub(r"^(.*)\n[-~]{3,}$", r"**\1**", contents, flags=re.MULTILINE)
-
-    with open(DIR / "readme.rst", "w") as f:
-        f.write(contents)
-
-
-def clean_up(app, exception):  # noqa: ARG001
-    (DIR / "readme.rst").unlink()
-
-
-def setup(app):
-    # Add hook for building doxygen xml when needed
-    app.connect("builder-inited", generate_doxygen_xml)
-
-    # Copy the readme in
-    app.connect("builder-inited", prepare)
-
-    # Clean up the generated readme
-    app.connect("build-finished", clean_up)
+#!/usr/bin/env python3
+#
+# pybind11 documentation build configuration file, created by
+# sphinx-quickstart on Sun Oct 11 19:23:48 2015.
+#
+# 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 os
+import re
+import subprocess
+import sys
+from pathlib import Path
+
+DIR = Path(__file__).parent.resolve()
+
+# 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 = [
+    "breathe",
+    "sphinx_copybutton",
+    "sphinxcontrib.rsvgconverter",
+    "sphinxcontrib.moderncmakedomain",
+]
+
+breathe_projects = {"pybind11": ".build/doxygenxml/"}
+breathe_default_project = "pybind11"
+breathe_domain_by_extension = {"h": "cpp"}
+
+# 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 = "pybind11"
+copyright = "2017, Wenzel Jakob"
+author = "Wenzel Jakob"
+
+# 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.
+
+# Read the listed version
+with open("../pybind11/_version.py") as f:
+    code = compile(f.read(), "../pybind11/_version.py", "exec")
+loc = {}
+exec(code, loc)
+
+# The full version, including alpha/beta/rc tags.
+version = loc["__version__"]
+
+# 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 = [".build", "release.rst"]
+
+# The reST default role (used for this markup: `text`) to use for all
+# documents.
+default_role = "any"
+
+# 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 = 'monokai'
+
+# 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 = False
+
+
+# -- 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 = "furo"
+
+# 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 = []
+
+# The name for this set of Sphinx documents.  If None, it defaults to
+# "<project> v<version> 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 (within the static path) to use as 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"]
+
+html_css_files = [
+    "css/custom.css",
+]
+
+# 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 = "pybind11doc"
+
+# -- Options for LaTeX output ---------------------------------------------
+
+latex_engine = "pdflatex"
+
+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.
+    # remove blank pages (between the title page and the TOC, etc.)
+    "classoptions": ",openany,oneside",
+    "preamble": r"""
+\usepackage{fontawesome}
+\usepackage{textgreek}
+\DeclareUnicodeCharacter{00A0}{}
+\DeclareUnicodeCharacter{2194}{\faArrowsH}
+\DeclareUnicodeCharacter{1F382}{\faBirthdayCake}
+\DeclareUnicodeCharacter{1F355}{\faAdjust}
+\DeclareUnicodeCharacter{0301}{'}
+\DeclareUnicodeCharacter{03C0}{\textpi}
+
+""",
+    # 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, "pybind11.tex", "pybind11 Documentation", "Wenzel Jakob", "manual"),
+]
+
+# The name of an image file (relative to this directory) to place at the top of
+# the title page.
+# latex_logo = 'pybind11-logo.png'
+
+# 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, "pybind11", "pybind11 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,
+        "pybind11",
+        "pybind11 Documentation",
+        author,
+        "pybind11",
+        "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
+
+primary_domain = "cpp"
+highlight_language = "cpp"
+
+
+def generate_doxygen_xml(app):
+    build_dir = os.path.join(app.confdir, ".build")
+    if not os.path.exists(build_dir):
+        os.mkdir(build_dir)
+
+    try:
+        subprocess.call(["doxygen", "--version"])
+        retcode = subprocess.call(["doxygen"], cwd=app.confdir)
+        if retcode < 0:
+            sys.stderr.write(f"doxygen error code: {-retcode}\n")
+    except OSError as e:
+        sys.stderr.write(f"doxygen execution failed: {e}\n")
+
+
+def prepare(app):
+    with open(DIR.parent / "README.rst") as f:
+        contents = f.read()
+
+    if app.builder.name == "latex":
+        # Remove badges and stuff from start
+        contents = contents[contents.find(r".. start") :]
+
+        # Filter out section titles for index.rst for LaTeX
+        contents = re.sub(r"^(.*)\n[-~]{3,}$", r"**\1**", contents, flags=re.MULTILINE)
+
+    with open(DIR / "readme.rst", "w") as f:
+        f.write(contents)
+
+
+def clean_up(app, exception):  # noqa: ARG001
+    (DIR / "readme.rst").unlink()
+
+
+def setup(app):
+    # Add hook for building doxygen xml when needed
+    app.connect("builder-inited", generate_doxygen_xml)
+
+    # Copy the readme in
+    app.connect("builder-inited", prepare)
+
+    # Clean up the generated readme
+    app.connect("build-finished", clean_up)

third_party/CityFlow/extern/pybind11/docs/faq.rst

@@ -1,308 +1,308 @@
-Frequently asked questions
-##########################
-
-"ImportError: dynamic module does not define init function"
-===========================================================
-
-1. Make sure that the name specified in PYBIND11_MODULE is identical to the
-filename of the extension library (without suffixes such as ``.so``).
-
-2. If the above did not fix the issue, you are likely using an incompatible
-version of Python that does not match what you compiled with.
-
-"Symbol not found: ``__Py_ZeroStruct`` / ``_PyInstanceMethod_Type``"
-========================================================================
-
-See the first answer.
-
-"SystemError: dynamic module not initialized properly"
-======================================================
-
-See the first answer.
-
-The Python interpreter immediately crashes when importing my module
-===================================================================
-
-See the first answer.
-
-.. _faq_reference_arguments:
-
-Limitations involving reference arguments
-=========================================
-
-In C++, it's fairly common to pass arguments using mutable references or
-mutable pointers, which allows both read and write access to the value
-supplied by the caller. This is sometimes done for efficiency reasons, or to
-realize functions that have multiple return values. Here are two very basic
-examples:
-
-.. code-block:: cpp
-
-    void increment(int &i) { i++; }
-    void increment_ptr(int *i) { (*i)++; }
-
-In Python, all arguments are passed by reference, so there is no general
-issue in binding such code from Python.
-
-However, certain basic Python types (like ``str``, ``int``, ``bool``,
-``float``, etc.) are **immutable**. This means that the following attempt
-to port the function to Python doesn't have the same effect on the value
-provided by the caller -- in fact, it does nothing at all.
-
-.. code-block:: python
-
-    def increment(i):
-        i += 1  # nope..
-
-pybind11 is also affected by such language-level conventions, which means that
-binding ``increment`` or ``increment_ptr`` will also create Python functions
-that don't modify their arguments.
-
-Although inconvenient, one workaround is to encapsulate the immutable types in
-a custom type that does allow modifications.
-
-An other alternative involves binding a small wrapper lambda function that
-returns a tuple with all output arguments (see the remainder of the
-documentation for examples on binding lambda functions). An example:
-
-.. code-block:: cpp
-
-    int foo(int &i) { i++; return 123; }
-
-and the binding code
-
-.. code-block:: cpp
-
-   m.def("foo", [](int i) { int rv = foo(i); return std::make_tuple(rv, i); });
-
-
-How can I reduce the build time?
-================================
-
-It's good practice to split binding code over multiple files, as in the
-following example:
-
-:file:`example.cpp`:
-
-.. code-block:: cpp
-
-    void init_ex1(py::module_ &);
-    void init_ex2(py::module_ &);
-    /* ... */
-
-    PYBIND11_MODULE(example, m) {
-        init_ex1(m);
-        init_ex2(m);
-        /* ... */
-    }
-
-:file:`ex1.cpp`:
-
-.. code-block:: cpp
-
-    void init_ex1(py::module_ &m) {
-        m.def("add", [](int a, int b) { return a + b; });
-    }
-
-:file:`ex2.cpp`:
-
-.. code-block:: cpp
-
-    void init_ex2(py::module_ &m) {
-        m.def("sub", [](int a, int b) { return a - b; });
-    }
-
-:command:`python`:
-
-.. code-block:: pycon
-
-    >>> import example
-    >>> example.add(1, 2)
-    3
-    >>> example.sub(1, 1)
-    0
-
-As shown above, the various ``init_ex`` functions should be contained in
-separate files that can be compiled independently from one another, and then
-linked together into the same final shared object.  Following this approach
-will:
-
-1. reduce memory requirements per compilation unit.
-
-2. enable parallel builds (if desired).
-
-3. allow for faster incremental builds. For instance, when a single class
-   definition is changed, only a subset of the binding code will generally need
-   to be recompiled.
-
-"recursive template instantiation exceeded maximum depth of 256"
-================================================================
-
-If you receive an error about excessive recursive template evaluation, try
-specifying a larger value, e.g. ``-ftemplate-depth=1024`` on GCC/Clang. The
-culprit is generally the generation of function signatures at compile time
-using C++14 template metaprogramming.
-
-.. _`faq:hidden_visibility`:
-
-"'SomeClass' declared with greater visibility than the type of its field 'SomeClass::member' [-Wattributes]"
-============================================================================================================
-
-This error typically indicates that you are compiling without the required
-``-fvisibility`` flag.  pybind11 code internally forces hidden visibility on
-all internal code, but if non-hidden (and thus *exported*) code attempts to
-include a pybind type (for example, ``py::object`` or ``py::list``) you can run
-into this warning.
-
-To avoid it, make sure you are specifying ``-fvisibility=hidden`` when
-compiling pybind code.
-
-As to why ``-fvisibility=hidden`` is necessary, because pybind modules could
-have been compiled under different versions of pybind itself, it is also
-important that the symbols defined in one module do not clash with the
-potentially-incompatible symbols defined in another.  While Python extension
-modules are usually loaded with localized symbols (under POSIX systems
-typically using ``dlopen`` with the ``RTLD_LOCAL`` flag), this Python default
-can be changed, but even if it isn't it is not always enough to guarantee
-complete independence of the symbols involved when not using
-``-fvisibility=hidden``.
-
-Additionally, ``-fvisibility=hidden`` can deliver considerably binary size
-savings. (See the following section for more details.)
-
-
-.. _`faq:symhidden`:
-
-How can I create smaller binaries?
-==================================
-
-To do its job, pybind11 extensively relies on a programming technique known as
-*template metaprogramming*, which is a way of performing computation at compile
-time using type information. Template metaprogramming usually instantiates code
-involving significant numbers of deeply nested types that are either completely
-removed or reduced to just a few instructions during the compiler's optimization
-phase. However, due to the nested nature of these types, the resulting symbol
-names in the compiled extension library can be extremely long. For instance,
-the included test suite contains the following symbol:
-
-.. only:: html
-
-    .. code-block:: none
-
-        _​_​Z​N​8​p​y​b​i​n​d​1​1​1​2​c​p​p​_​f​u​n​c​t​i​o​n​C​1​I​v​8​E​x​a​m​p​l​e​2​J​R​N​S​t​3​_​_​1​6​v​e​c​t​o​r​I​N​S​3​_​1​2​b​a​s​i​c​_​s​t​r​i​n​g​I​w​N​S​3​_​1​1​c​h​a​r​_​t​r​a​i​t​s​I​w​E​E​N​S​3​_​9​a​l​l​o​c​a​t​o​r​I​w​E​E​E​E​N​S​8​_​I​S​A​_​E​E​E​E​E​J​N​S​_​4​n​a​m​e​E​N​S​_​7​s​i​b​l​i​n​g​E​N​S​_​9​i​s​_​m​e​t​h​o​d​E​A​2​8​_​c​E​E​E​M​T​0​_​F​T​_​D​p​T​1​_​E​D​p​R​K​T​2​_
-
-.. only:: not html
-
-    .. code-block:: cpp
-
-        __ZN8pybind1112cpp_functionC1Iv8Example2JRNSt3__16vectorINS3_12basic_stringIwNS3_11char_traitsIwEENS3_9allocatorIwEEEENS8_ISA_EEEEEJNS_4nameENS_7siblingENS_9is_methodEA28_cEEEMT0_FT_DpT1_EDpRKT2_
-
-which is the mangled form of the following function type:
-
-.. code-block:: cpp
-
-    pybind11::cpp_function::cpp_function<void, Example2, std::__1::vector<std::__1::basic_string<wchar_t, std::__1::char_traits<wchar_t>, std::__1::allocator<wchar_t> >, std::__1::allocator<std::__1::basic_string<wchar_t, std::__1::char_traits<wchar_t>, std::__1::allocator<wchar_t> > > >&, pybind11::name, pybind11::sibling, pybind11::is_method, char [28]>(void (Example2::*)(std::__1::vector<std::__1::basic_string<wchar_t, std::__1::char_traits<wchar_t>, std::__1::allocator<wchar_t> >, std::__1::allocator<std::__1::basic_string<wchar_t, std::__1::char_traits<wchar_t>, std::__1::allocator<wchar_t> > > >&), pybind11::name const&, pybind11::sibling const&, pybind11::is_method const&, char const (&) [28])
-
-The memory needed to store just the mangled name of this function (196 bytes)
-is larger than the actual piece of code (111 bytes) it represents! On the other
-hand, it's silly to even give this function a name -- after all, it's just a
-tiny cog in a bigger piece of machinery that is not exposed to the outside
-world. So we'll generally only want to export symbols for those functions which
-are actually called from the outside.
-
-This can be achieved by specifying the parameter ``-fvisibility=hidden`` to GCC
-and Clang, which sets the default symbol visibility to *hidden*, which has a
-tremendous impact on the final binary size of the resulting extension library.
-(On Visual Studio, symbols are already hidden by default, so nothing needs to
-be done there.)
-
-In addition to decreasing binary size, ``-fvisibility=hidden`` also avoids
-potential serious issues when loading multiple modules and is required for
-proper pybind operation.  See the previous FAQ entry for more details.
-
-How can I properly handle Ctrl-C in long-running functions?
-===========================================================
-
-Ctrl-C is received by the Python interpreter, and holds it until the GIL
-is released, so a long-running function won't be interrupted.
-
-To interrupt from inside your function, you can use the ``PyErr_CheckSignals()``
-function, that will tell if a signal has been raised on the Python side.  This
-function merely checks a flag, so its impact is negligible. When a signal has
-been received, you must either explicitly interrupt execution by throwing
-``py::error_already_set`` (which will propagate the existing
-``KeyboardInterrupt``), or clear the error (which you usually will not want):
-
-.. code-block:: cpp
-
-    PYBIND11_MODULE(example, m)
-    {
-        m.def("long running_func", []()
-        {
-            for (;;) {
-                if (PyErr_CheckSignals() != 0)
-                    throw py::error_already_set();
-                // Long running iteration
-            }
-        });
-    }
-
-CMake doesn't detect the right Python version
-=============================================
-
-The CMake-based build system will try to automatically detect the installed
-version of Python and link against that. When this fails, or when there are
-multiple versions of Python and it finds the wrong one, delete
-``CMakeCache.txt`` and then add ``-DPYTHON_EXECUTABLE=$(which python)`` to your
-CMake configure line. (Replace ``$(which python)`` with a path to python if
-your prefer.)
-
-You can alternatively try ``-DPYBIND11_FINDPYTHON=ON``, which will activate the
-new CMake FindPython support instead of pybind11's custom search. Requires
-CMake 3.12+, and 3.15+ or 3.18.2+ are even better. You can set this in your
-``CMakeLists.txt`` before adding or finding pybind11, as well.
-
-Inconsistent detection of Python version in CMake and pybind11
-==============================================================
-
-The functions ``find_package(PythonInterp)`` and ``find_package(PythonLibs)``
-provided by CMake for Python version detection are modified by pybind11 due to
-unreliability and limitations that make them unsuitable for pybind11's needs.
-Instead pybind11 provides its own, more reliable Python detection CMake code.
-Conflicts can arise, however, when using pybind11 in a project that *also* uses
-the CMake Python detection in a system with several Python versions installed.
-
-This difference may cause inconsistencies and errors if *both* mechanisms are
-used in the same project.
-
-There are three possible solutions:
-
-1. Avoid using ``find_package(PythonInterp)`` and ``find_package(PythonLibs)``
-   from CMake and rely on pybind11 in detecting Python version. If this is not
-   possible, the CMake machinery should be called *before* including pybind11.
-2. Set ``PYBIND11_FINDPYTHON`` to ``True`` or use ``find_package(Python
-   COMPONENTS Interpreter Development)`` on modern CMake (3.12+, 3.15+ better,
-   3.18.2+ best). Pybind11 in these cases uses the new CMake FindPython instead
-   of the old, deprecated search tools, and these modules are much better at
-   finding the correct Python. If FindPythonLibs/Interp are not available
-   (CMake 3.27+), then this will be ignored and FindPython will be used.
-3. Set ``PYBIND11_NOPYTHON`` to ``TRUE``. Pybind11 will not search for Python.
-   However, you will have to use the target-based system, and do more setup
-   yourself, because it does not know about or include things that depend on
-   Python, like ``pybind11_add_module``. This might be ideal for integrating
-   into an existing system, like scikit-build's Python helpers.
-
-How to cite this project?
-=========================
-
-We suggest the following BibTeX template to cite pybind11 in scientific
-discourse:
-
-.. code-block:: bash
-
-    @misc{pybind11,
-       author = {Wenzel Jakob and Jason Rhinelander and Dean Moldovan},
-       year = {2017},
-       note = {https://github.com/pybind/pybind11},
-       title = {pybind11 -- Seamless operability between C++11 and Python}
-    }
+Frequently asked questions
+##########################
+
+"ImportError: dynamic module does not define init function"
+===========================================================
+
+1. Make sure that the name specified in PYBIND11_MODULE is identical to the
+filename of the extension library (without suffixes such as ``.so``).
+
+2. If the above did not fix the issue, you are likely using an incompatible
+version of Python that does not match what you compiled with.
+
+"Symbol not found: ``__Py_ZeroStruct`` / ``_PyInstanceMethod_Type``"
+========================================================================
+
+See the first answer.
+
+"SystemError: dynamic module not initialized properly"
+======================================================
+
+See the first answer.
+
+The Python interpreter immediately crashes when importing my module
+===================================================================
+
+See the first answer.
+
+.. _faq_reference_arguments:
+
+Limitations involving reference arguments
+=========================================
+
+In C++, it's fairly common to pass arguments using mutable references or
+mutable pointers, which allows both read and write access to the value
+supplied by the caller. This is sometimes done for efficiency reasons, or to
+realize functions that have multiple return values. Here are two very basic
+examples:
+
+.. code-block:: cpp
+
+    void increment(int &i) { i++; }
+    void increment_ptr(int *i) { (*i)++; }
+
+In Python, all arguments are passed by reference, so there is no general
+issue in binding such code from Python.
+
+However, certain basic Python types (like ``str``, ``int``, ``bool``,
+``float``, etc.) are **immutable**. This means that the following attempt
+to port the function to Python doesn't have the same effect on the value
+provided by the caller -- in fact, it does nothing at all.
+
+.. code-block:: python
+
+    def increment(i):
+        i += 1  # nope..
+
+pybind11 is also affected by such language-level conventions, which means that
+binding ``increment`` or ``increment_ptr`` will also create Python functions
+that don't modify their arguments.
+
+Although inconvenient, one workaround is to encapsulate the immutable types in
+a custom type that does allow modifications.
+
+An other alternative involves binding a small wrapper lambda function that
+returns a tuple with all output arguments (see the remainder of the
+documentation for examples on binding lambda functions). An example:
+
+.. code-block:: cpp
+
+    int foo(int &i) { i++; return 123; }
+
+and the binding code
+
+.. code-block:: cpp
+
+   m.def("foo", [](int i) { int rv = foo(i); return std::make_tuple(rv, i); });
+
+
+How can I reduce the build time?
+================================
+
+It's good practice to split binding code over multiple files, as in the
+following example:
+
+:file:`example.cpp`:
+
+.. code-block:: cpp
+
+    void init_ex1(py::module_ &);
+    void init_ex2(py::module_ &);
+    /* ... */
+
+    PYBIND11_MODULE(example, m) {
+        init_ex1(m);
+        init_ex2(m);
+        /* ... */
+    }
+
+:file:`ex1.cpp`:
+
+.. code-block:: cpp
+
+    void init_ex1(py::module_ &m) {
+        m.def("add", [](int a, int b) { return a + b; });
+    }
+
+:file:`ex2.cpp`:
+
+.. code-block:: cpp
+
+    void init_ex2(py::module_ &m) {
+        m.def("sub", [](int a, int b) { return a - b; });
+    }
+
+:command:`python`:
+
+.. code-block:: pycon
+
+    >>> import example
+    >>> example.add(1, 2)
+    3
+    >>> example.sub(1, 1)
+    0
+
+As shown above, the various ``init_ex`` functions should be contained in
+separate files that can be compiled independently from one another, and then
+linked together into the same final shared object.  Following this approach
+will:
+
+1. reduce memory requirements per compilation unit.
+
+2. enable parallel builds (if desired).
+
+3. allow for faster incremental builds. For instance, when a single class
+   definition is changed, only a subset of the binding code will generally need
+   to be recompiled.
+
+"recursive template instantiation exceeded maximum depth of 256"
+================================================================
+
+If you receive an error about excessive recursive template evaluation, try
+specifying a larger value, e.g. ``-ftemplate-depth=1024`` on GCC/Clang. The
+culprit is generally the generation of function signatures at compile time
+using C++14 template metaprogramming.
+
+.. _`faq:hidden_visibility`:
+
+"'SomeClass' declared with greater visibility than the type of its field 'SomeClass::member' [-Wattributes]"
+============================================================================================================
+
+This error typically indicates that you are compiling without the required
+``-fvisibility`` flag.  pybind11 code internally forces hidden visibility on
+all internal code, but if non-hidden (and thus *exported*) code attempts to
+include a pybind type (for example, ``py::object`` or ``py::list``) you can run
+into this warning.
+
+To avoid it, make sure you are specifying ``-fvisibility=hidden`` when
+compiling pybind code.
+
+As to why ``-fvisibility=hidden`` is necessary, because pybind modules could
+have been compiled under different versions of pybind itself, it is also
+important that the symbols defined in one module do not clash with the
+potentially-incompatible symbols defined in another.  While Python extension
+modules are usually loaded with localized symbols (under POSIX systems
+typically using ``dlopen`` with the ``RTLD_LOCAL`` flag), this Python default
+can be changed, but even if it isn't it is not always enough to guarantee
+complete independence of the symbols involved when not using
+``-fvisibility=hidden``.
+
+Additionally, ``-fvisibility=hidden`` can deliver considerably binary size
+savings. (See the following section for more details.)
+
+
+.. _`faq:symhidden`:
+
+How can I create smaller binaries?
+==================================
+
+To do its job, pybind11 extensively relies on a programming technique known as
+*template metaprogramming*, which is a way of performing computation at compile
+time using type information. Template metaprogramming usually instantiates code
+involving significant numbers of deeply nested types that are either completely
+removed or reduced to just a few instructions during the compiler's optimization
+phase. However, due to the nested nature of these types, the resulting symbol
+names in the compiled extension library can be extremely long. For instance,
+the included test suite contains the following symbol:
+
+.. only:: html
+
+    .. code-block:: none
+
+        _​_​Z​N​8​p​y​b​i​n​d​1​1​1​2​c​p​p​_​f​u​n​c​t​i​o​n​C​1​I​v​8​E​x​a​m​p​l​e​2​J​R​N​S​t​3​_​_​1​6​v​e​c​t​o​r​I​N​S​3​_​1​2​b​a​s​i​c​_​s​t​r​i​n​g​I​w​N​S​3​_​1​1​c​h​a​r​_​t​r​a​i​t​s​I​w​E​E​N​S​3​_​9​a​l​l​o​c​a​t​o​r​I​w​E​E​E​E​N​S​8​_​I​S​A​_​E​E​E​E​E​J​N​S​_​4​n​a​m​e​E​N​S​_​7​s​i​b​l​i​n​g​E​N​S​_​9​i​s​_​m​e​t​h​o​d​E​A​2​8​_​c​E​E​E​M​T​0​_​F​T​_​D​p​T​1​_​E​D​p​R​K​T​2​_
+
+.. only:: not html
+
+    .. code-block:: cpp
+
+        __ZN8pybind1112cpp_functionC1Iv8Example2JRNSt3__16vectorINS3_12basic_stringIwNS3_11char_traitsIwEENS3_9allocatorIwEEEENS8_ISA_EEEEEJNS_4nameENS_7siblingENS_9is_methodEA28_cEEEMT0_FT_DpT1_EDpRKT2_
+
+which is the mangled form of the following function type:
+
+.. code-block:: cpp
+
+    pybind11::cpp_function::cpp_function<void, Example2, std::__1::vector<std::__1::basic_string<wchar_t, std::__1::char_traits<wchar_t>, std::__1::allocator<wchar_t> >, std::__1::allocator<std::__1::basic_string<wchar_t, std::__1::char_traits<wchar_t>, std::__1::allocator<wchar_t> > > >&, pybind11::name, pybind11::sibling, pybind11::is_method, char [28]>(void (Example2::*)(std::__1::vector<std::__1::basic_string<wchar_t, std::__1::char_traits<wchar_t>, std::__1::allocator<wchar_t> >, std::__1::allocator<std::__1::basic_string<wchar_t, std::__1::char_traits<wchar_t>, std::__1::allocator<wchar_t> > > >&), pybind11::name const&, pybind11::sibling const&, pybind11::is_method const&, char const (&) [28])
+
+The memory needed to store just the mangled name of this function (196 bytes)
+is larger than the actual piece of code (111 bytes) it represents! On the other
+hand, it's silly to even give this function a name -- after all, it's just a
+tiny cog in a bigger piece of machinery that is not exposed to the outside
+world. So we'll generally only want to export symbols for those functions which
+are actually called from the outside.
+
+This can be achieved by specifying the parameter ``-fvisibility=hidden`` to GCC
+and Clang, which sets the default symbol visibility to *hidden*, which has a
+tremendous impact on the final binary size of the resulting extension library.
+(On Visual Studio, symbols are already hidden by default, so nothing needs to
+be done there.)
+
+In addition to decreasing binary size, ``-fvisibility=hidden`` also avoids
+potential serious issues when loading multiple modules and is required for
+proper pybind operation.  See the previous FAQ entry for more details.
+
+How can I properly handle Ctrl-C in long-running functions?
+===========================================================
+
+Ctrl-C is received by the Python interpreter, and holds it until the GIL
+is released, so a long-running function won't be interrupted.
+
+To interrupt from inside your function, you can use the ``PyErr_CheckSignals()``
+function, that will tell if a signal has been raised on the Python side.  This
+function merely checks a flag, so its impact is negligible. When a signal has
+been received, you must either explicitly interrupt execution by throwing
+``py::error_already_set`` (which will propagate the existing
+``KeyboardInterrupt``), or clear the error (which you usually will not want):
+
+.. code-block:: cpp
+
+    PYBIND11_MODULE(example, m)
+    {
+        m.def("long running_func", []()
+        {
+            for (;;) {
+                if (PyErr_CheckSignals() != 0)
+                    throw py::error_already_set();
+                // Long running iteration
+            }
+        });
+    }
+
+CMake doesn't detect the right Python version
+=============================================
+
+The CMake-based build system will try to automatically detect the installed
+version of Python and link against that. When this fails, or when there are
+multiple versions of Python and it finds the wrong one, delete
+``CMakeCache.txt`` and then add ``-DPYTHON_EXECUTABLE=$(which python)`` to your
+CMake configure line. (Replace ``$(which python)`` with a path to python if
+your prefer.)
+
+You can alternatively try ``-DPYBIND11_FINDPYTHON=ON``, which will activate the
+new CMake FindPython support instead of pybind11's custom search. Requires
+CMake 3.12+, and 3.15+ or 3.18.2+ are even better. You can set this in your
+``CMakeLists.txt`` before adding or finding pybind11, as well.
+
+Inconsistent detection of Python version in CMake and pybind11
+==============================================================
+
+The functions ``find_package(PythonInterp)`` and ``find_package(PythonLibs)``
+provided by CMake for Python version detection are modified by pybind11 due to
+unreliability and limitations that make them unsuitable for pybind11's needs.
+Instead pybind11 provides its own, more reliable Python detection CMake code.
+Conflicts can arise, however, when using pybind11 in a project that *also* uses
+the CMake Python detection in a system with several Python versions installed.
+
+This difference may cause inconsistencies and errors if *both* mechanisms are
+used in the same project.
+
+There are three possible solutions:
+
+1. Avoid using ``find_package(PythonInterp)`` and ``find_package(PythonLibs)``
+   from CMake and rely on pybind11 in detecting Python version. If this is not
+   possible, the CMake machinery should be called *before* including pybind11.
+2. Set ``PYBIND11_FINDPYTHON`` to ``True`` or use ``find_package(Python
+   COMPONENTS Interpreter Development)`` on modern CMake (3.12+, 3.15+ better,
+   3.18.2+ best). Pybind11 in these cases uses the new CMake FindPython instead
+   of the old, deprecated search tools, and these modules are much better at
+   finding the correct Python. If FindPythonLibs/Interp are not available
+   (CMake 3.27+), then this will be ignored and FindPython will be used.
+3. Set ``PYBIND11_NOPYTHON`` to ``TRUE``. Pybind11 will not search for Python.
+   However, you will have to use the target-based system, and do more setup
+   yourself, because it does not know about or include things that depend on
+   Python, like ``pybind11_add_module``. This might be ideal for integrating
+   into an existing system, like scikit-build's Python helpers.
+
+How to cite this project?
+=========================
+
+We suggest the following BibTeX template to cite pybind11 in scientific
+discourse:
+
+.. code-block:: bash
+
+    @misc{pybind11,
+       author = {Wenzel Jakob and Jason Rhinelander and Dean Moldovan},
+       year = {2017},
+       note = {https://github.com/pybind/pybind11},
+       title = {pybind11 -- Seamless operability between C++11 and Python}
+    }

third_party/CityFlow/extern/pybind11/docs/index.rst

@@ -1,48 +1,48 @@
-.. only:: latex
-
-   Intro
-   =====
-
-.. include:: readme.rst
-
-.. only:: not latex
-
-    Contents:
-
-.. toctree::
-   :maxdepth: 1
-
-   changelog
-   upgrade
-
-.. toctree::
-   :caption: The Basics
-   :maxdepth: 2
-
-   installing
-   basics
-   classes
-   compiling
-
-.. toctree::
-   :caption: Advanced Topics
-   :maxdepth: 2
-
-   advanced/functions
-   advanced/classes
-   advanced/exceptions
-   advanced/smart_ptrs
-   advanced/cast/index
-   advanced/pycpp/index
-   advanced/embedding
-   advanced/misc
-
-.. toctree::
-   :caption: Extra Information
-   :maxdepth: 1
-
-   faq
-   benchmark
-   limitations
-   reference
-   cmake/index
+.. only:: latex
+
+   Intro
+   =====
+
+.. include:: readme.rst
+
+.. only:: not latex
+
+    Contents:
+
+.. toctree::
+   :maxdepth: 1
+
+   changelog
+   upgrade
+
+.. toctree::
+   :caption: The Basics
+   :maxdepth: 2
+
+   installing
+   basics
+   classes
+   compiling
+
+.. toctree::
+   :caption: Advanced Topics
+   :maxdepth: 2
+
+   advanced/functions
+   advanced/classes
+   advanced/exceptions
+   advanced/smart_ptrs
+   advanced/cast/index
+   advanced/pycpp/index
+   advanced/embedding
+   advanced/misc
+
+.. toctree::
+   :caption: Extra Information
+   :maxdepth: 1
+
+   faq
+   benchmark
+   limitations
+   reference
+   cmake/index

third_party/CityFlow/extern/pybind11/docs/installing.rst

@@ -1,105 +1,105 @@
-.. _installing:
-
-Installing the library
-######################
-
-There are several ways to get the pybind11 source, which lives at
-`pybind/pybind11 on GitHub <https://github.com/pybind/pybind11>`_. The pybind11
-developers recommend one of the first three ways listed here, submodule, PyPI,
-or conda-forge, for obtaining pybind11.
-
-.. _include_as_a_submodule:
-
-Include as a submodule
-======================
-
-When you are working on a project in Git, you can use the pybind11 repository
-as a submodule. From your git repository, use:
-
-.. code-block:: bash
-
-    git submodule add -b stable ../../pybind/pybind11 extern/pybind11
-    git submodule update --init
-
-This assumes you are placing your dependencies in ``extern/``, and that you are
-using GitHub; if you are not using GitHub, use the full https or ssh URL
-instead of the relative URL ``../../pybind/pybind11`` above. Some other servers
-also require the ``.git`` extension (GitHub does not).
-
-From here, you can now include ``extern/pybind11/include``, or you can use
-the various integration tools (see :ref:`compiling`) pybind11 provides directly
-from the local folder.
-
-Include with PyPI
-=================
-
-You can download the sources and CMake files as a Python package from PyPI
-using Pip. Just use:
-
-.. code-block:: bash
-
-    pip install pybind11
-
-This will provide pybind11 in a standard Python package format. If you want
-pybind11 available directly in your environment root, you can use:
-
-.. code-block:: bash
-
-    pip install "pybind11[global]"
-
-This is not recommended if you are installing with your system Python, as it
-will add files to ``/usr/local/include/pybind11`` and
-``/usr/local/share/cmake/pybind11``, so unless that is what you want, it is
-recommended only for use in virtual environments or your ``pyproject.toml``
-file (see :ref:`compiling`).
-
-Include with conda-forge
-========================
-
-You can use pybind11 with conda packaging via `conda-forge
-<https://github.com/conda-forge/pybind11-feedstock>`_:
-
-.. code-block:: bash
-
-    conda install -c conda-forge pybind11
-
-
-Include with vcpkg
-==================
-You can download and install pybind11 using the Microsoft `vcpkg
-<https://github.com/Microsoft/vcpkg/>`_ dependency manager:
-
-.. code-block:: bash
-
-    git clone https://github.com/Microsoft/vcpkg.git
-    cd vcpkg
-    ./bootstrap-vcpkg.sh
-    ./vcpkg integrate install
-    vcpkg install pybind11
-
-The pybind11 port in vcpkg is kept up to date by Microsoft team members and
-community contributors. If the version is out of date, please `create an issue
-or pull request <https://github.com/Microsoft/vcpkg/>`_ on the vcpkg
-repository.
-
-Global install with brew
-========================
-
-The brew package manager (Homebrew on macOS, or Linuxbrew on Linux) has a
-`pybind11 package
-<https://github.com/Homebrew/homebrew-core/blob/master/Formula/pybind11.rb>`_.
-To install:
-
-.. code-block:: bash
-
-    brew install pybind11
-
-.. We should list Conan, and possibly a few other C++ package managers (hunter,
-.. perhaps). Conan has a very clean CMake integration that would be good to show.
-
-Other options
-=============
-
-Other locations you can find pybind11 are `listed here
-<https://repology.org/project/python:pybind11/versions>`_; these are maintained
-by various packagers and the community.
+.. _installing:
+
+Installing the library
+######################
+
+There are several ways to get the pybind11 source, which lives at
+`pybind/pybind11 on GitHub <https://github.com/pybind/pybind11>`_. The pybind11
+developers recommend one of the first three ways listed here, submodule, PyPI,
+or conda-forge, for obtaining pybind11.
+
+.. _include_as_a_submodule:
+
+Include as a submodule
+======================
+
+When you are working on a project in Git, you can use the pybind11 repository
+as a submodule. From your git repository, use:
+
+.. code-block:: bash
+
+    git submodule add -b stable ../../pybind/pybind11 extern/pybind11
+    git submodule update --init
+
+This assumes you are placing your dependencies in ``extern/``, and that you are
+using GitHub; if you are not using GitHub, use the full https or ssh URL
+instead of the relative URL ``../../pybind/pybind11`` above. Some other servers
+also require the ``.git`` extension (GitHub does not).
+
+From here, you can now include ``extern/pybind11/include``, or you can use
+the various integration tools (see :ref:`compiling`) pybind11 provides directly
+from the local folder.
+
+Include with PyPI
+=================
+
+You can download the sources and CMake files as a Python package from PyPI
+using Pip. Just use:
+
+.. code-block:: bash
+
+    pip install pybind11
+
+This will provide pybind11 in a standard Python package format. If you want
+pybind11 available directly in your environment root, you can use:
+
+.. code-block:: bash
+
+    pip install "pybind11[global]"
+
+This is not recommended if you are installing with your system Python, as it
+will add files to ``/usr/local/include/pybind11`` and
+``/usr/local/share/cmake/pybind11``, so unless that is what you want, it is
+recommended only for use in virtual environments or your ``pyproject.toml``
+file (see :ref:`compiling`).
+
+Include with conda-forge
+========================
+
+You can use pybind11 with conda packaging via `conda-forge
+<https://github.com/conda-forge/pybind11-feedstock>`_:
+
+.. code-block:: bash
+
+    conda install -c conda-forge pybind11
+
+
+Include with vcpkg
+==================
+You can download and install pybind11 using the Microsoft `vcpkg
+<https://github.com/Microsoft/vcpkg/>`_ dependency manager:
+
+.. code-block:: bash
+
+    git clone https://github.com/Microsoft/vcpkg.git
+    cd vcpkg
+    ./bootstrap-vcpkg.sh
+    ./vcpkg integrate install
+    vcpkg install pybind11
+
+The pybind11 port in vcpkg is kept up to date by Microsoft team members and
+community contributors. If the version is out of date, please `create an issue
+or pull request <https://github.com/Microsoft/vcpkg/>`_ on the vcpkg
+repository.
+
+Global install with brew
+========================
+
+The brew package manager (Homebrew on macOS, or Linuxbrew on Linux) has a
+`pybind11 package
+<https://github.com/Homebrew/homebrew-core/blob/master/Formula/pybind11.rb>`_.
+To install:
+
+.. code-block:: bash
+
+    brew install pybind11
+
+.. We should list Conan, and possibly a few other C++ package managers (hunter,
+.. perhaps). Conan has a very clean CMake integration that would be good to show.
+
+Other options
+=============
+
+Other locations you can find pybind11 are `listed here
+<https://repology.org/project/python:pybind11/versions>`_; these are maintained
+by various packagers and the community.

third_party/CityFlow/extern/pybind11/docs/limitations.rst

@@ -1,72 +1,72 @@
-Limitations
-###########
-
-Design choices
-^^^^^^^^^^^^^^
-
-pybind11 strives to be a general solution to binding generation, but it also has
-certain limitations:
-
-- pybind11 casts away ``const``-ness in function arguments and return values.
-  This is in line with the Python language, which has no concept of ``const``
-  values. This means that some additional care is needed to avoid bugs that
-  would be caught by the type checker in a traditional C++ program.
-
-- The NumPy interface ``pybind11::array`` greatly simplifies accessing
-  numerical data from C++ (and vice versa), but it's not a full-blown array
-  class like ``Eigen::Array`` or ``boost.multi_array``. ``Eigen`` objects are
-  directly supported, however, with ``pybind11/eigen.h``.
-
-Large but useful features could be implemented in pybind11 but would lead to a
-significant increase in complexity. Pybind11 strives to be simple and compact.
-Users who require large new features are encouraged to write an extension to
-pybind11; see `pybind11_json <https://github.com/pybind/pybind11_json>`_ for an
-example.
-
-
-Known bugs
-^^^^^^^^^^
-
-These are issues that hopefully will one day be fixed, but currently are
-unsolved. If you know how to help with one of these issues, contributions
-are welcome!
-
-- Intel 20.2 is currently having an issue with the test suite.
-  `#2573 <https://github.com/pybind/pybind11/pull/2573>`_
-
-- Debug mode Python does not support 1-5 tests in the test suite currently.
-  `#2422 <https://github.com/pybind/pybind11/pull/2422>`_
-
-- PyPy3 7.3.1 and 7.3.2 have issues with several tests on 32-bit Windows.
-
-Known limitations
-^^^^^^^^^^^^^^^^^
-
-These are issues that are probably solvable, but have not been fixed yet. A
-clean, well written patch would likely be accepted to solve them.
-
-- Type casters are not kept alive recursively.
-  `#2527 <https://github.com/pybind/pybind11/issues/2527>`_
-  One consequence is that containers of ``char *`` are currently not supported.
-  `#2245 <https://github.com/pybind/pybind11/issues/2245>`_
-
-- The ``cpptest`` does not run on Windows with Python 3.8 or newer, due to DLL
-  loader changes. User code that is correctly installed should not be affected.
-  `#2560 <https://github.com/pybind/pybind11/issue/2560>`_
-
-Python 3.9.0 warning
-^^^^^^^^^^^^^^^^^^^^
-
-Combining older versions of pybind11 (< 2.6.0) with Python on exactly 3.9.0
-will trigger undefined behavior that typically manifests as crashes during
-interpreter shutdown (but could also destroy your data. **You have been
-warned**).
-
-This issue was `fixed in Python <https://github.com/python/cpython/pull/22670>`_.
-As a mitigation for this bug, pybind11 2.6.0 or newer includes a workaround
-specifically when Python 3.9.0 is detected at runtime, leaking about 50 bytes
-of memory when a callback function is garbage collected.  For reference, the
-pybind11 test suite has about 2,000 such callbacks, but only 49 are garbage
-collected before the end-of-process. Wheels (even if built with Python 3.9.0)
-will correctly avoid the leak when run in Python 3.9.1, and this does not
-affect other 3.X versions.
+Limitations
+###########
+
+Design choices
+^^^^^^^^^^^^^^
+
+pybind11 strives to be a general solution to binding generation, but it also has
+certain limitations:
+
+- pybind11 casts away ``const``-ness in function arguments and return values.
+  This is in line with the Python language, which has no concept of ``const``
+  values. This means that some additional care is needed to avoid bugs that
+  would be caught by the type checker in a traditional C++ program.
+
+- The NumPy interface ``pybind11::array`` greatly simplifies accessing
+  numerical data from C++ (and vice versa), but it's not a full-blown array
+  class like ``Eigen::Array`` or ``boost.multi_array``. ``Eigen`` objects are
+  directly supported, however, with ``pybind11/eigen.h``.
+
+Large but useful features could be implemented in pybind11 but would lead to a
+significant increase in complexity. Pybind11 strives to be simple and compact.
+Users who require large new features are encouraged to write an extension to
+pybind11; see `pybind11_json <https://github.com/pybind/pybind11_json>`_ for an
+example.
+
+
+Known bugs
+^^^^^^^^^^
+
+These are issues that hopefully will one day be fixed, but currently are
+unsolved. If you know how to help with one of these issues, contributions
+are welcome!
+
+- Intel 20.2 is currently having an issue with the test suite.
+  `#2573 <https://github.com/pybind/pybind11/pull/2573>`_
+
+- Debug mode Python does not support 1-5 tests in the test suite currently.
+  `#2422 <https://github.com/pybind/pybind11/pull/2422>`_
+
+- PyPy3 7.3.1 and 7.3.2 have issues with several tests on 32-bit Windows.
+
+Known limitations
+^^^^^^^^^^^^^^^^^
+
+These are issues that are probably solvable, but have not been fixed yet. A
+clean, well written patch would likely be accepted to solve them.
+
+- Type casters are not kept alive recursively.
+  `#2527 <https://github.com/pybind/pybind11/issues/2527>`_
+  One consequence is that containers of ``char *`` are currently not supported.
+  `#2245 <https://github.com/pybind/pybind11/issues/2245>`_
+
+- The ``cpptest`` does not run on Windows with Python 3.8 or newer, due to DLL
+  loader changes. User code that is correctly installed should not be affected.
+  `#2560 <https://github.com/pybind/pybind11/issue/2560>`_
+
+Python 3.9.0 warning
+^^^^^^^^^^^^^^^^^^^^
+
+Combining older versions of pybind11 (< 2.6.0) with Python on exactly 3.9.0
+will trigger undefined behavior that typically manifests as crashes during
+interpreter shutdown (but could also destroy your data. **You have been
+warned**).
+
+This issue was `fixed in Python <https://github.com/python/cpython/pull/22670>`_.
+As a mitigation for this bug, pybind11 2.6.0 or newer includes a workaround
+specifically when Python 3.9.0 is detected at runtime, leaking about 50 bytes
+of memory when a callback function is garbage collected.  For reference, the
+pybind11 test suite has about 2,000 such callbacks, but only 49 are garbage
+collected before the end-of-process. Wheels (even if built with Python 3.9.0)
+will correctly avoid the leak when run in Python 3.9.1, and this does not
+affect other 3.X versions.

third_party/CityFlow/extern/pybind11/docs/reference.rst

@@ -1,130 +1,130 @@
-.. _reference:
-
-.. warning::
-
-    Please be advised that the reference documentation discussing pybind11
-    internals is currently incomplete. Please refer to the previous sections
-    and the pybind11 header files for the nitty gritty details.
-
-Reference
-#########
-
-.. _macros:
-
-Macros
-======
-
-.. doxygendefine:: PYBIND11_MODULE
-
-.. _core_types:
-
-Convenience classes for arbitrary Python types
-==============================================
-
-Common member functions
------------------------
-
-.. doxygenclass:: object_api
-    :members:
-
-Without reference counting
---------------------------
-
-.. doxygenclass:: handle
-    :members:
-
-With reference counting
------------------------
-
-.. doxygenclass:: object
-    :members:
-
-.. doxygenfunction:: reinterpret_borrow
-
-.. doxygenfunction:: reinterpret_steal
-
-Convenience classes for specific Python types
-=============================================
-
-.. doxygenclass:: module_
-    :members:
-
-.. doxygengroup:: pytypes
-    :members:
-
-Convenience functions converting to Python types
-================================================
-
-.. doxygenfunction:: make_tuple(Args&&...)
-
-.. doxygenfunction:: make_iterator(Iterator, Sentinel, Extra &&...)
-.. doxygenfunction:: make_iterator(Type &, Extra&&...)
-
-.. doxygenfunction:: make_key_iterator(Iterator, Sentinel, Extra &&...)
-.. doxygenfunction:: make_key_iterator(Type &, Extra&&...)
-
-.. doxygenfunction:: make_value_iterator(Iterator, Sentinel, Extra &&...)
-.. doxygenfunction:: make_value_iterator(Type &, Extra&&...)
-
-.. _extras:
-
-Passing extra arguments to ``def`` or ``class_``
-================================================
-
-.. doxygengroup:: annotations
-    :members:
-
-Embedding the interpreter
-=========================
-
-.. doxygendefine:: PYBIND11_EMBEDDED_MODULE
-
-.. doxygenfunction:: initialize_interpreter
-
-.. doxygenfunction:: finalize_interpreter
-
-.. doxygenclass:: scoped_interpreter
-
-Redirecting C++ streams
-=======================
-
-.. doxygenclass:: scoped_ostream_redirect
-
-.. doxygenclass:: scoped_estream_redirect
-
-.. doxygenfunction:: add_ostream_redirect
-
-Python built-in functions
-=========================
-
-.. doxygengroup:: python_builtins
-    :members:
-
-Inheritance
-===========
-
-See :doc:`/classes` and :doc:`/advanced/classes` for more detail.
-
-.. doxygendefine:: PYBIND11_OVERRIDE
-
-.. doxygendefine:: PYBIND11_OVERRIDE_PURE
-
-.. doxygendefine:: PYBIND11_OVERRIDE_NAME
-
-.. doxygendefine:: PYBIND11_OVERRIDE_PURE_NAME
-
-.. doxygenfunction:: get_override
-
-Exceptions
-==========
-
-.. doxygenclass:: error_already_set
-    :members:
-
-.. doxygenclass:: builtin_exception
-    :members:
-
-Literals
-========
-
-.. doxygennamespace:: literals
+.. _reference:
+
+.. warning::
+
+    Please be advised that the reference documentation discussing pybind11
+    internals is currently incomplete. Please refer to the previous sections
+    and the pybind11 header files for the nitty gritty details.
+
+Reference
+#########
+
+.. _macros:
+
+Macros
+======
+
+.. doxygendefine:: PYBIND11_MODULE
+
+.. _core_types:
+
+Convenience classes for arbitrary Python types
+==============================================
+
+Common member functions
+-----------------------
+
+.. doxygenclass:: object_api
+    :members:
+
+Without reference counting
+--------------------------
+
+.. doxygenclass:: handle
+    :members:
+
+With reference counting
+-----------------------
+
+.. doxygenclass:: object
+    :members:
+
+.. doxygenfunction:: reinterpret_borrow
+
+.. doxygenfunction:: reinterpret_steal
+
+Convenience classes for specific Python types
+=============================================
+
+.. doxygenclass:: module_
+    :members:
+
+.. doxygengroup:: pytypes
+    :members:
+
+Convenience functions converting to Python types
+================================================
+
+.. doxygenfunction:: make_tuple(Args&&...)
+
+.. doxygenfunction:: make_iterator(Iterator, Sentinel, Extra &&...)
+.. doxygenfunction:: make_iterator(Type &, Extra&&...)
+
+.. doxygenfunction:: make_key_iterator(Iterator, Sentinel, Extra &&...)
+.. doxygenfunction:: make_key_iterator(Type &, Extra&&...)
+
+.. doxygenfunction:: make_value_iterator(Iterator, Sentinel, Extra &&...)
+.. doxygenfunction:: make_value_iterator(Type &, Extra&&...)
+
+.. _extras:
+
+Passing extra arguments to ``def`` or ``class_``
+================================================
+
+.. doxygengroup:: annotations
+    :members:
+
+Embedding the interpreter
+=========================
+
+.. doxygendefine:: PYBIND11_EMBEDDED_MODULE
+
+.. doxygenfunction:: initialize_interpreter
+
+.. doxygenfunction:: finalize_interpreter
+
+.. doxygenclass:: scoped_interpreter
+
+Redirecting C++ streams
+=======================
+
+.. doxygenclass:: scoped_ostream_redirect
+
+.. doxygenclass:: scoped_estream_redirect
+
+.. doxygenfunction:: add_ostream_redirect
+
+Python built-in functions
+=========================
+
+.. doxygengroup:: python_builtins
+    :members:
+
+Inheritance
+===========
+
+See :doc:`/classes` and :doc:`/advanced/classes` for more detail.
+
+.. doxygendefine:: PYBIND11_OVERRIDE
+
+.. doxygendefine:: PYBIND11_OVERRIDE_PURE
+
+.. doxygendefine:: PYBIND11_OVERRIDE_NAME
+
+.. doxygendefine:: PYBIND11_OVERRIDE_PURE_NAME
+
+.. doxygenfunction:: get_override
+
+Exceptions
+==========
+
+.. doxygenclass:: error_already_set
+    :members:
+
+.. doxygenclass:: builtin_exception
+    :members:
+
+Literals
+========
+
+.. doxygennamespace:: literals

third_party/CityFlow/extern/pybind11/docs/release.rst

@@ -1,143 +1,143 @@
-On version numbers
-^^^^^^^^^^^^^^^^^^
-
-The two version numbers (C++ and Python) must match when combined (checked when
-you build the PyPI package), and must be a valid `PEP 440
-<https://www.python.org/dev/peps/pep-0440>`_ version when combined.
-
-For example:
-
-.. code-block:: C++
-
-    #define PYBIND11_VERSION_MAJOR X
-    #define PYBIND11_VERSION_MINOR Y
-    #define PYBIND11_VERSION_PATCH Z.dev1
-
-For beta, ``PYBIND11_VERSION_PATCH`` should be ``Z.b1``. RC's can be ``Z.rc1``.
-Always include the dot (even though PEP 440 allows it to be dropped). For a
-final release, this must be a simple integer. There is also
-``PYBIND11_VERSION_HEX`` just below that needs to be updated.
-
-
-To release a new version of pybind11:
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-If you don't have nox, you should either use ``pipx run nox`` instead, or use
-``pipx install nox`` or ``brew install nox`` (Unix).
-
-- Update the version number
-
-  - Update ``PYBIND11_VERSION_MAJOR`` etc. in
-    ``include/pybind11/detail/common.h``. PATCH should be a simple integer.
-
-  - Update ``PYBIND11_VERSION_HEX`` just below as well.
-
-  - Update ``pybind11/_version.py`` (match above).
-
-  - Run ``nox -s tests_packaging`` to ensure this was done correctly.
-
-- Ensure that all the information in ``setup.cfg`` is up-to-date, like
-    supported Python versions.
-
-- Add release date in ``docs/changelog.rst`` and integrate the output of
-  ``nox -s make_changelog``.
-
-  - Note that the ``nox -s make_changelog`` command inspects
-    `needs changelog <https://github.com/pybind/pybind11/pulls?q=is%3Apr+is%3Aclosed+label%3A%22needs+changelog%22>`_.
-
-  - Manually clear the ``needs changelog`` labels using the GitHub web
-    interface (very easy: start by clicking the link above).
-
-- ``git add`` and ``git commit``, ``git push``. **Ensure CI passes**. (If it
-    fails due to a known flake issue, either ignore or restart CI.)
-
-- Add a release branch if this is a new MINOR version, or update the existing
-  release branch if it is a patch version
-
-  - New branch: ``git checkout -b vX.Y``, ``git push -u origin vX.Y``
-
-  - Update branch: ``git checkout vX.Y``, ``git merge <release branch>``, ``git push``
-
-- Update tags (optional; if you skip this, the GitHub release makes a
-  non-annotated tag for you)
-
-  - ``git tag -a vX.Y.Z -m 'vX.Y.Z release'``
-
-  - ``grep ^__version__ pybind11/_version.py``
-
-    - Last-minute consistency check: same as tag?
-
-  - ``git push --tags``
-
-- Update stable
-
-  - ``git checkout stable``
-
-  - ``git merge -X theirs vX.Y.Z``
-
-  - ``git diff vX.Y.Z``
-
-  - Carefully review and reconcile any diffs. There should be none.
-
-  - ``git push``
-
-- Make a GitHub release (this shows up in the UI, sends new release
-  notifications to users watching releases, and also uploads PyPI packages).
-  (Note: if you do not use an existing tag, this creates a new lightweight tag
-  for you, so you could skip the above step.)
-
-  - GUI method: Under `releases <https://github.com/pybind/pybind11/releases>`_
-    click "Draft a new release" on the far right, fill in the tag name
-    (if you didn't tag above, it will be made here), fill in a release name
-    like "Version X.Y.Z", and copy-and-paste the markdown-formatted (!) changelog
-    into the description. You can use ``cat docs/changelog.rst | pandoc -f rst -t gfm``,
-    then manually remove line breaks and strip links to PRs and issues,
-    e.g. to a bare ``#1234``, without the surrounding ``<...>_`` hyperlink markup.
-    Check "pre-release" if this is a beta/RC.
-
-  - CLI method: with ``gh`` installed, run ``gh release create vX.Y.Z -t "Version X.Y.Z"``
-    If this is a pre-release, add ``-p``.
-
-- Get back to work
-
-  - Make sure you are on master, not somewhere else: ``git checkout master``
-
-  - Update version macros in ``include/pybind11/detail/common.h`` (set PATCH to
-    ``0.dev1`` and increment MINOR).
-
-  - Update ``pybind11/_version.py`` to match.
-
-  - Run ``nox -s tests_packaging`` to ensure this was done correctly.
-
-  - If the release was a new MINOR version, add a new ``IN DEVELOPMENT``
-    section in ``docs/changelog.rst``.
-
-  - ``git add``, ``git commit``, ``git push``
-
-If a version branch is updated, remember to set PATCH to ``1.dev1``.
-
-If you'd like to bump homebrew, run:
-
-.. code-block:: console
-
-    brew bump-formula-pr --url https://github.com/pybind/pybind11/archive/vX.Y.Z.tar.gz
-
-Conda-forge should automatically make a PR in a few hours, and automatically
-merge it if there are no issues.
-
-
-Manual packaging
-^^^^^^^^^^^^^^^^
-
-If you need to manually upload releases, you can download the releases from
-the job artifacts and upload them with twine. You can also make the files
-locally (not recommended in general, as your local directory is more likely
-to be "dirty" and SDists love picking up random unrelated/hidden files);
-this is the procedure:
-
-.. code-block:: bash
-
-    nox -s build
-    twine upload dist/*
-
-This makes SDists and wheels, and the final line uploads them.
+On version numbers
+^^^^^^^^^^^^^^^^^^
+
+The two version numbers (C++ and Python) must match when combined (checked when
+you build the PyPI package), and must be a valid `PEP 440
+<https://www.python.org/dev/peps/pep-0440>`_ version when combined.
+
+For example:
+
+.. code-block:: C++
+
+    #define PYBIND11_VERSION_MAJOR X
+    #define PYBIND11_VERSION_MINOR Y
+    #define PYBIND11_VERSION_PATCH Z.dev1
+
+For beta, ``PYBIND11_VERSION_PATCH`` should be ``Z.b1``. RC's can be ``Z.rc1``.
+Always include the dot (even though PEP 440 allows it to be dropped). For a
+final release, this must be a simple integer. There is also
+``PYBIND11_VERSION_HEX`` just below that needs to be updated.
+
+
+To release a new version of pybind11:
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+If you don't have nox, you should either use ``pipx run nox`` instead, or use
+``pipx install nox`` or ``brew install nox`` (Unix).
+
+- Update the version number
+
+  - Update ``PYBIND11_VERSION_MAJOR`` etc. in
+    ``include/pybind11/detail/common.h``. PATCH should be a simple integer.
+
+  - Update ``PYBIND11_VERSION_HEX`` just below as well.
+
+  - Update ``pybind11/_version.py`` (match above).
+
+  - Run ``nox -s tests_packaging`` to ensure this was done correctly.
+
+- Ensure that all the information in ``setup.cfg`` is up-to-date, like
+    supported Python versions.
+
+- Add release date in ``docs/changelog.rst`` and integrate the output of
+  ``nox -s make_changelog``.
+
+  - Note that the ``nox -s make_changelog`` command inspects
+    `needs changelog <https://github.com/pybind/pybind11/pulls?q=is%3Apr+is%3Aclosed+label%3A%22needs+changelog%22>`_.
+
+  - Manually clear the ``needs changelog`` labels using the GitHub web
+    interface (very easy: start by clicking the link above).
+
+- ``git add`` and ``git commit``, ``git push``. **Ensure CI passes**. (If it
+    fails due to a known flake issue, either ignore or restart CI.)
+
+- Add a release branch if this is a new MINOR version, or update the existing
+  release branch if it is a patch version
+
+  - New branch: ``git checkout -b vX.Y``, ``git push -u origin vX.Y``
+
+  - Update branch: ``git checkout vX.Y``, ``git merge <release branch>``, ``git push``
+
+- Update tags (optional; if you skip this, the GitHub release makes a
+  non-annotated tag for you)
+
+  - ``git tag -a vX.Y.Z -m 'vX.Y.Z release'``
+
+  - ``grep ^__version__ pybind11/_version.py``
+
+    - Last-minute consistency check: same as tag?
+
+  - ``git push --tags``
+
+- Update stable
+
+  - ``git checkout stable``
+
+  - ``git merge -X theirs vX.Y.Z``
+
+  - ``git diff vX.Y.Z``
+
+  - Carefully review and reconcile any diffs. There should be none.
+
+  - ``git push``
+
+- Make a GitHub release (this shows up in the UI, sends new release
+  notifications to users watching releases, and also uploads PyPI packages).
+  (Note: if you do not use an existing tag, this creates a new lightweight tag
+  for you, so you could skip the above step.)
+
+  - GUI method: Under `releases <https://github.com/pybind/pybind11/releases>`_
+    click "Draft a new release" on the far right, fill in the tag name
+    (if you didn't tag above, it will be made here), fill in a release name
+    like "Version X.Y.Z", and copy-and-paste the markdown-formatted (!) changelog
+    into the description. You can use ``cat docs/changelog.rst | pandoc -f rst -t gfm``,
+    then manually remove line breaks and strip links to PRs and issues,
+    e.g. to a bare ``#1234``, without the surrounding ``<...>_`` hyperlink markup.
+    Check "pre-release" if this is a beta/RC.
+
+  - CLI method: with ``gh`` installed, run ``gh release create vX.Y.Z -t "Version X.Y.Z"``
+    If this is a pre-release, add ``-p``.
+
+- Get back to work
+
+  - Make sure you are on master, not somewhere else: ``git checkout master``
+
+  - Update version macros in ``include/pybind11/detail/common.h`` (set PATCH to
+    ``0.dev1`` and increment MINOR).
+
+  - Update ``pybind11/_version.py`` to match.
+
+  - Run ``nox -s tests_packaging`` to ensure this was done correctly.
+
+  - If the release was a new MINOR version, add a new ``IN DEVELOPMENT``
+    section in ``docs/changelog.rst``.
+
+  - ``git add``, ``git commit``, ``git push``
+
+If a version branch is updated, remember to set PATCH to ``1.dev1``.
+
+If you'd like to bump homebrew, run:
+
+.. code-block:: console
+
+    brew bump-formula-pr --url https://github.com/pybind/pybind11/archive/vX.Y.Z.tar.gz
+
+Conda-forge should automatically make a PR in a few hours, and automatically
+merge it if there are no issues.
+
+
+Manual packaging
+^^^^^^^^^^^^^^^^
+
+If you need to manually upload releases, you can download the releases from
+the job artifacts and upload them with twine. You can also make the files
+locally (not recommended in general, as your local directory is more likely
+to be "dirty" and SDists love picking up random unrelated/hidden files);
+this is the procedure:
+
+.. code-block:: bash
+
+    nox -s build
+    twine upload dist/*
+
+This makes SDists and wheels, and the final line uploads them.

third_party/CityFlow/extern/pybind11/docs/requirements.txt

@@ -1,6 +1,6 @@
-breathe==4.34.0
-furo==2022.6.21
-sphinx==5.0.2
-sphinx-copybutton==0.5.0
-sphinxcontrib-moderncmakedomain==3.21.4
-sphinxcontrib-svg2pdfconverter==1.2.0
+breathe==4.34.0
+furo==2022.6.21
+sphinx==5.0.2
+sphinx-copybutton==0.5.0
+sphinxcontrib-moderncmakedomain==3.21.4
+sphinxcontrib-svg2pdfconverter==1.2.0

third_party/CityFlow/extern/pybind11/docs/upgrade.rst

@@ -1,594 +1,594 @@
-Upgrade guide
-#############
-
-This is a companion guide to the :doc:`changelog`. While the changelog briefly
-lists all of the new features, improvements and bug fixes, this upgrade guide
-focuses only the subset which directly impacts your experience when upgrading
-to a new version. But it goes into more detail. This includes things like
-deprecated APIs and their replacements, build system changes, general code
-modernization and other useful information.
-
-.. _upgrade-guide-2.12:
-
-v2.12
-=====
-
-NumPy support has been upgraded to support the 2.x series too. The two relevant
-changes are that:
-
-* ``dtype.flags()`` is now a ``uint64`` and ``dtype.alignment()`` an
-  ``ssize_t`` (and NumPy may return an larger than integer value for
-  ``itemsize()`` in NumPy 2.x).
-
-* The long deprecated NumPy function ``PyArray_GetArrayParamsFromObject``
-  function is not available anymore.
-
-Due to NumPy changes, you may experience difficulties updating to NumPy 2.
-Please see the [NumPy 2 migration guide](https://numpy.org/devdocs/numpy_2_0_migration_guide.html) for details.
-For example, a more direct change could be that the default integer ``"int_"``
-(and ``"uint"``) is now ``ssize_t`` and not ``long`` (affects 64bit windows).
-
-If you want to only support NumPy 1.x for now and are having problems due to
-the two internal changes listed above, you can define
-``PYBIND11_NUMPY_1_ONLY`` to disable the new support for now. Make sure you
-define this on all pybind11 compile units, since it could be a source of ODR
-violations if used inconsistently. This option will be removed in the future,
-so adapting your code is highly recommended.
-
-
-.. _upgrade-guide-2.11:
-
-v2.11
-=====
-
-* The minimum version of CMake is now 3.5. A future version will likely move to
-  requiring something like CMake 3.15. Note that CMake 3.27 is removing the
-  long-deprecated support for ``FindPythonInterp`` if you set 3.27 as the
-  minimum or maximum supported version. To prepare for that future, CMake 3.15+
-  using ``FindPython`` or setting ``PYBIND11_FINDPYTHON`` is highly recommended,
-  otherwise pybind11 will automatically switch to using ``FindPython`` if
-  ``FindPythonInterp`` is not available.
-
-
-.. _upgrade-guide-2.9:
-
-v2.9
-====
-
-* Any usage of the recently added ``py::make_simple_namespace`` should be
-  converted to using ``py::module_::import("types").attr("SimpleNamespace")``
-  instead.
-
-* The use of ``_`` in custom type casters can now be replaced with the more
-  readable ``const_name`` instead. The old ``_`` shortcut has been retained
-  unless it is being used as a macro (like for gettext).
-
-
-.. _upgrade-guide-2.7:
-
-v2.7
-====
-
-*Before* v2.7, ``py::str`` can hold ``PyUnicodeObject`` or ``PyBytesObject``,
-and ``py::isinstance<str>()`` is ``true`` for both ``py::str`` and
-``py::bytes``. Starting with v2.7, ``py::str`` exclusively holds
-``PyUnicodeObject`` (`#2409 <https://github.com/pybind/pybind11/pull/2409>`_),
-and ``py::isinstance<str>()`` is ``true`` only for ``py::str``. To help in
-the transition of user code, the ``PYBIND11_STR_LEGACY_PERMISSIVE`` macro
-is provided as an escape hatch to go back to the legacy behavior. This macro
-will be removed in future releases. Two types of required fixes are expected
-to be common:
-
-* Accidental use of ``py::str`` instead of ``py::bytes``, masked by the legacy
-  behavior. These are probably very easy to fix, by changing from
-  ``py::str`` to ``py::bytes``.
-
-* Reliance on py::isinstance<str>(obj) being ``true`` for
-  ``py::bytes``. This is likely to be easy to fix in most cases by adding
-  ``|| py::isinstance<bytes>(obj)``, but a fix may be more involved, e.g. if
-  ``py::isinstance<T>`` appears in a template. Such situations will require
-  careful review and custom fixes.
-
-
-.. _upgrade-guide-2.6:
-
-v2.6
-====
-
-Usage of the ``PYBIND11_OVERLOAD*`` macros and ``get_overload`` function should
-be replaced by ``PYBIND11_OVERRIDE*`` and ``get_override``. In the future, the
-old macros may be deprecated and removed.
-
-``py::module`` has been renamed ``py::module_``, but a backward compatible
-typedef has been included. This change was to avoid a language change in C++20
-that requires unqualified ``module`` not be placed at the start of a logical
-line. Qualified usage is unaffected and the typedef will remain unless the
-C++ language rules change again.
-
-The public constructors of ``py::module_`` have been deprecated. Use
-``PYBIND11_MODULE`` or ``module_::create_extension_module`` instead.
-
-An error is now thrown when ``__init__`` is forgotten on subclasses. This was
-incorrect before, but was not checked. Add a call to ``__init__`` if it is
-missing.
-
-A ``py::type_error`` is now thrown when casting to a subclass (like
-``py::bytes`` from ``py::object``) if the conversion is not valid. Make a valid
-conversion instead.
-
-The undocumented ``h.get_type()`` method has been deprecated and replaced by
-``py::type::of(h)``.
-
-Enums now have a ``__str__`` method pre-defined; if you want to override it,
-the simplest fix is to add the new ``py::prepend()`` tag when defining
-``"__str__"``.
-
-If ``__eq__`` defined but not ``__hash__``, ``__hash__`` is now set to
-``None``, as in normal CPython. You should add ``__hash__`` if you intended the
-class to be hashable, possibly using the new ``py::hash`` shortcut.
-
-The constructors for ``py::array`` now always take signed integers for size,
-for consistency. This may lead to compiler warnings on some systems. Cast to
-``py::ssize_t`` instead of ``std::size_t``.
-
-The ``tools/clang`` submodule and ``tools/mkdoc.py`` have been moved to a
-standalone package, `pybind11-mkdoc`_. If you were using those tools, please
-use them via a pip install from the new location.
-
-The ``pybind11`` package on PyPI no longer fills the wheel "headers" slot - if
-you were using the headers from this slot, they are available by requesting the
-``global`` extra, that is, ``pip install "pybind11[global]"``. (Most users will
-be unaffected, as the ``pybind11/include`` location is reported by ``python -m
-pybind11 --includes`` and ``pybind11.get_include()`` is still correct and has
-not changed since 2.5).
-
-.. _pybind11-mkdoc: https://github.com/pybind/pybind11-mkdoc
-
-CMake support:
---------------
-
-The minimum required version of CMake is now 3.4.  Several details of the CMake
-support have been deprecated; warnings will be shown if you need to change
-something. The changes are:
-
-* ``PYBIND11_CPP_STANDARD=<platform-flag>`` is deprecated, please use
-  ``CMAKE_CXX_STANDARD=<number>`` instead, or any other valid CMake CXX or CUDA
-  standard selection method, like ``target_compile_features``.
-
-* If you do not request a standard, pybind11 targets will compile with the
-  compiler default, but not less than C++11, instead of forcing C++14 always.
-  If you depend on the old behavior, please use ``set(CMAKE_CXX_STANDARD 14 CACHE STRING "")``
-  instead.
-
-* Direct ``pybind11::module`` usage should always be accompanied by at least
-  ``set(CMAKE_CXX_VISIBILITY_PRESET hidden)`` or similar - it used to try to
-  manually force this compiler flag (but not correctly on all compilers or with
-  CUDA).
-
-* ``pybind11_add_module``'s ``SYSTEM`` argument is deprecated and does nothing;
-  linking now behaves like other imported libraries consistently in both
-  config and submodule mode, and behaves like a ``SYSTEM`` library by
-  default.
-
-* If ``PYTHON_EXECUTABLE`` is not set, virtual environments (``venv``,
-  ``virtualenv``, and ``conda``) are prioritized over the standard search
-  (similar to the new FindPython mode).
-
-In addition, the following changes may be of interest:
-
-* ``CMAKE_INTERPROCEDURAL_OPTIMIZATION`` will be respected by
-  ``pybind11_add_module`` if set instead of linking to ``pybind11::lto`` or
-  ``pybind11::thin_lto``.
-
-* Using ``find_package(Python COMPONENTS Interpreter Development)`` before
-  pybind11 will cause pybind11 to use the new Python mechanisms instead of its
-  own custom search, based on a patched version of classic ``FindPythonInterp``
-  / ``FindPythonLibs``. In the future, this may become the default. A recent
-  (3.15+ or 3.18.2+) version of CMake is recommended.
-
-
-
-v2.5
-====
-
-The Python package now includes the headers as data in the package itself, as
-well as in the "headers" wheel slot. ``pybind11 --includes`` and
-``pybind11.get_include()`` report the new location, which is always correct
-regardless of how pybind11 was installed, making the old ``user=`` argument
-meaningless. If you are not using the function to get the location already, you
-are encouraged to switch to the package location.
-
-
-v2.2
-====
-
-Deprecation of the ``PYBIND11_PLUGIN`` macro
---------------------------------------------
-
-``PYBIND11_MODULE`` is now the preferred way to create module entry points.
-The old macro emits a compile-time deprecation warning.
-
-.. code-block:: cpp
-
-    // old
-    PYBIND11_PLUGIN(example) {
-        py::module m("example", "documentation string");
-
-        m.def("add", [](int a, int b) { return a + b; });
-
-        return m.ptr();
-    }
-
-    // new
-    PYBIND11_MODULE(example, m) {
-        m.doc() = "documentation string"; // optional
-
-        m.def("add", [](int a, int b) { return a + b; });
-    }
-
-
-New API for defining custom constructors and pickling functions
----------------------------------------------------------------
-
-The old placement-new custom constructors have been deprecated. The new approach
-uses ``py::init()`` and factory functions to greatly improve type safety.
-
-Placement-new can be called accidentally with an incompatible type (without any
-compiler errors or warnings), or it can initialize the same object multiple times
-if not careful with the Python-side ``__init__`` calls. The new-style custom
-constructors prevent such mistakes. See :ref:`custom_constructors` for details.
-
-.. code-block:: cpp
-
-    // old -- deprecated (runtime warning shown only in debug mode)
-    py::class<Foo>(m, "Foo")
-        .def("__init__", [](Foo &self, ...) {
-            new (&self) Foo(...); // uses placement-new
-        });
-
-    // new
-    py::class<Foo>(m, "Foo")
-        .def(py::init([](...) { // Note: no `self` argument
-            return new Foo(...); // return by raw pointer
-            // or: return std::make_unique<Foo>(...); // return by holder
-            // or: return Foo(...); // return by value (move constructor)
-        }));
-
-Mirroring the custom constructor changes, ``py::pickle()`` is now the preferred
-way to get and set object state. See :ref:`pickling` for details.
-
-.. code-block:: cpp
-
-    // old -- deprecated (runtime warning shown only in debug mode)
-    py::class<Foo>(m, "Foo")
-        ...
-        .def("__getstate__", [](const Foo &self) {
-            return py::make_tuple(self.value1(), self.value2(), ...);
-        })
-        .def("__setstate__", [](Foo &self, py::tuple t) {
-            new (&self) Foo(t[0].cast<std::string>(), ...);
-        });
-
-    // new
-    py::class<Foo>(m, "Foo")
-        ...
-        .def(py::pickle(
-            [](const Foo &self) { // __getstate__
-                return py::make_tuple(self.value1(), self.value2(), ...); // unchanged
-            },
-            [](py::tuple t) { // __setstate__, note: no `self` argument
-                return new Foo(t[0].cast<std::string>(), ...);
-                // or: return std::make_unique<Foo>(...); // return by holder
-                // or: return Foo(...); // return by value (move constructor)
-            }
-        ));
-
-For both the constructors and pickling, warnings are shown at module
-initialization time (on import, not when the functions are called).
-They're only visible when compiled in debug mode. Sample warning:
-
-.. code-block:: none
-
-    pybind11-bound class 'mymodule.Foo' is using an old-style placement-new '__init__'
-    which has been deprecated. See the upgrade guide in pybind11's docs.
-
-
-Stricter enforcement of hidden symbol visibility for pybind11 modules
----------------------------------------------------------------------
-
-pybind11 now tries to actively enforce hidden symbol visibility for modules.
-If you're using either one of pybind11's :doc:`CMake or Python build systems
-<compiling>` (the two example repositories) and you haven't been exporting any
-symbols, there's nothing to be concerned about. All the changes have been done
-transparently in the background. If you were building manually or relied on
-specific default visibility, read on.
-
-Setting default symbol visibility to *hidden* has always been recommended for
-pybind11 (see :ref:`faq:symhidden`). On Linux and macOS, hidden symbol
-visibility (in conjunction with the ``strip`` utility) yields much smaller
-module binaries. `CPython's extension docs`_ also recommend hiding symbols
-by default, with the goal of avoiding symbol name clashes between modules.
-Starting with v2.2, pybind11 enforces this more strictly: (1) by declaring
-all symbols inside the ``pybind11`` namespace as hidden and (2) by including
-the ``-fvisibility=hidden`` flag on Linux and macOS (only for extension
-modules, not for embedding the interpreter).
-
-.. _CPython's extension docs: https://docs.python.org/3/extending/extending.html#providing-a-c-api-for-an-extension-module
-
-The namespace-scope hidden visibility is done automatically in pybind11's
-headers and it's generally transparent to users. It ensures that:
-
-* Modules compiled with different pybind11 versions don't clash with each other.
-
-* Some new features, like ``py::module_local`` bindings, can work as intended.
-
-The ``-fvisibility=hidden`` flag applies the same visibility to user bindings
-outside of the ``pybind11`` namespace. It's now set automatic by pybind11's
-CMake and Python build systems, but this needs to be done manually by users
-of other build systems. Adding this flag:
-
-* Minimizes the chances of symbol conflicts between modules. E.g. if two
-  unrelated modules were statically linked to different (ABI-incompatible)
-  versions of the same third-party library, a symbol clash would be likely
-  (and would end with unpredictable results).
-
-* Produces smaller binaries on Linux and macOS, as pointed out previously.
-
-Within pybind11's CMake build system, ``pybind11_add_module`` has always been
-setting the ``-fvisibility=hidden`` flag in release mode. From now on, it's
-being applied unconditionally, even in debug mode and it can no longer be opted
-out of with the ``NO_EXTRAS`` option. The ``pybind11::module`` target now also
-adds this flag to its interface. The ``pybind11::embed`` target is unchanged.
-
-The most significant change here is for the ``pybind11::module`` target. If you
-were previously relying on default visibility, i.e. if your Python module was
-doubling as a shared library with dependents, you'll need to either export
-symbols manually (recommended for cross-platform libraries) or factor out the
-shared library (and have the Python module link to it like the other
-dependents). As a temporary workaround, you can also restore default visibility
-using the CMake code below, but this is not recommended in the long run:
-
-.. code-block:: cmake
-
-    target_link_libraries(mymodule PRIVATE pybind11::module)
-
-    add_library(restore_default_visibility INTERFACE)
-    target_compile_options(restore_default_visibility INTERFACE -fvisibility=default)
-    target_link_libraries(mymodule PRIVATE restore_default_visibility)
-
-
-Local STL container bindings
-----------------------------
-
-Previous pybind11 versions could only bind types globally -- all pybind11
-modules, even unrelated ones, would have access to the same exported types.
-However, this would also result in a conflict if two modules exported the
-same C++ type, which is especially problematic for very common types, e.g.
-``std::vector<int>``. :ref:`module_local` were added to resolve this (see
-that section for a complete usage guide).
-
-``py::class_`` still defaults to global bindings (because these types are
-usually unique across modules), however in order to avoid clashes of opaque
-types, ``py::bind_vector`` and ``py::bind_map`` will now bind STL containers
-as ``py::module_local`` if their elements are: builtins (``int``, ``float``,
-etc.), not bound using ``py::class_``, or bound as ``py::module_local``. For
-example, this change allows multiple modules to bind ``std::vector<int>``
-without causing conflicts. See :ref:`stl_bind` for more details.
-
-When upgrading to this version, if you have multiple modules which depend on
-a single global binding of an STL container, note that all modules can still
-accept foreign  ``py::module_local`` types in the direction of Python-to-C++.
-The locality only affects the C++-to-Python direction. If this is needed in
-multiple modules, you'll need to either:
-
-* Add a copy of the same STL binding to all of the modules which need it.
-
-* Restore the global status of that single binding by marking it
-  ``py::module_local(false)``.
-
-The latter is an easy workaround, but in the long run it would be best to
-localize all common type bindings in order to avoid conflicts with
-third-party modules.
-
-
-Negative strides for Python buffer objects and numpy arrays
------------------------------------------------------------
-
-Support for negative strides required changing the integer type from unsigned
-to signed in the interfaces of ``py::buffer_info`` and ``py::array``. If you
-have compiler warnings enabled, you may notice some new conversion warnings
-after upgrading. These can be resolved using ``static_cast``.
-
-
-Deprecation of some ``py::object`` APIs
----------------------------------------
-
-To compare ``py::object`` instances by pointer, you should now use
-``obj1.is(obj2)`` which is equivalent to ``obj1 is obj2`` in Python.
-Previously, pybind11 used ``operator==`` for this (``obj1 == obj2``), but
-that could be confusing and is now deprecated (so that it can eventually
-be replaced with proper rich object comparison in a future release).
-
-For classes which inherit from ``py::object``, ``borrowed`` and ``stolen``
-were previously available as protected constructor tags. Now the types
-should be used directly instead: ``borrowed_t{}`` and ``stolen_t{}``
-(`#771 <https://github.com/pybind/pybind11/pull/771>`_).
-
-
-Stricter compile-time error checking
-------------------------------------
-
-Some error checks have been moved from run time to compile time. Notably,
-automatic conversion of ``std::shared_ptr<T>`` is not possible when ``T`` is
-not directly registered with ``py::class_<T>`` (e.g. ``std::shared_ptr<int>``
-or ``std::shared_ptr<std::vector<T>>`` are not automatically convertible).
-Attempting to bind a function with such arguments now results in a compile-time
-error instead of waiting to fail at run time.
-
-``py::init<...>()`` constructor definitions are also stricter and now prevent
-bindings which could cause unexpected behavior:
-
-.. code-block:: cpp
-
-    struct Example {
-        Example(int &);
-    };
-
-    py::class_<Example>(m, "Example")
-        .def(py::init<int &>()); // OK, exact match
-        // .def(py::init<int>()); // compile-time error, mismatch
-
-A non-``const`` lvalue reference is not allowed to bind to an rvalue. However,
-note that a constructor taking ``const T &`` can still be registered using
-``py::init<T>()`` because a ``const`` lvalue reference can bind to an rvalue.
-
-v2.1
-====
-
-Minimum compiler versions are enforced at compile time
-------------------------------------------------------
-
-The minimums also apply to v2.0 but the check is now explicit and a compile-time
-error is raised if the compiler does not meet the requirements:
-
-* GCC >= 4.8
-* clang >= 3.3 (appleclang >= 5.0)
-* MSVC >= 2015u3
-* Intel C++ >= 15.0
-
-
-The ``py::metaclass`` attribute is not required for static properties
----------------------------------------------------------------------
-
-Binding classes with static properties is now possible by default. The
-zero-parameter version of ``py::metaclass()`` is deprecated. However, a new
-one-parameter ``py::metaclass(python_type)`` version was added for rare
-cases when a custom metaclass is needed to override pybind11's default.
-
-.. code-block:: cpp
-
-    // old -- emits a deprecation warning
-    py::class_<Foo>(m, "Foo", py::metaclass())
-        .def_property_readonly_static("foo", ...);
-
-    // new -- static properties work without the attribute
-    py::class_<Foo>(m, "Foo")
-        .def_property_readonly_static("foo", ...);
-
-    // new -- advanced feature, override pybind11's default metaclass
-    py::class_<Bar>(m, "Bar", py::metaclass(custom_python_type))
-        ...
-
-
-v2.0
-====
-
-Breaking changes in ``py::class_``
-----------------------------------
-
-These changes were necessary to make type definitions in pybind11
-future-proof, to support PyPy via its ``cpyext`` mechanism (`#527
-<https://github.com/pybind/pybind11/pull/527>`_), and to improve efficiency
-(`rev. 86d825 <https://github.com/pybind/pybind11/commit/86d825>`_).
-
-1. Declarations of types that provide access via the buffer protocol must
-   now include the ``py::buffer_protocol()`` annotation as an argument to
-   the ``py::class_`` constructor.
-
-   .. code-block:: cpp
-
-       py::class_<Matrix>("Matrix", py::buffer_protocol())
-           .def(py::init<...>())
-           .def_buffer(...);
-
-2. Classes which include static properties (e.g. ``def_readwrite_static()``)
-   must now include the ``py::metaclass()`` attribute. Note: this requirement
-   has since been removed in v2.1. If you're upgrading from 1.x, it's
-   recommended to skip directly to v2.1 or newer.
-
-3. This version of pybind11 uses a redesigned mechanism for instantiating
-   trampoline classes that are used to override virtual methods from within
-   Python. This led to the following user-visible syntax change:
-
-   .. code-block:: cpp
-
-       // old v1.x syntax
-       py::class_<TrampolineClass>("MyClass")
-           .alias<MyClass>()
-           ...
-
-       // new v2.x syntax
-       py::class_<MyClass, TrampolineClass>("MyClass")
-           ...
-
-   Importantly, both the original and the trampoline class are now specified
-   as arguments to the ``py::class_`` template, and the ``alias<..>()`` call
-   is gone. The new scheme has zero overhead in cases when Python doesn't
-   override any functions of the underlying C++ class.
-   `rev. 86d825 <https://github.com/pybind/pybind11/commit/86d825>`_.
-
-   The class type must be the first template argument given to ``py::class_``
-   while the trampoline can be mixed in arbitrary order with other arguments
-   (see the following section).
-
-
-Deprecation of the ``py::base<T>()`` attribute
-----------------------------------------------
-
-``py::base<T>()`` was deprecated in favor of specifying ``T`` as a template
-argument to ``py::class_``. This new syntax also supports multiple inheritance.
-Note that, while the type being exported must be the first argument in the
-``py::class_<Class, ...>`` template, the order of the following types (bases,
-holder and/or trampoline) is not important.
-
-.. code-block:: cpp
-
-    // old v1.x
-    py::class_<Derived>("Derived", py::base<Base>());
-
-    // new v2.x
-    py::class_<Derived, Base>("Derived");
-
-    // new -- multiple inheritance
-    py::class_<Derived, Base1, Base2>("Derived");
-
-    // new -- apart from `Derived` the argument order can be arbitrary
-    py::class_<Derived, Base1, Holder, Base2, Trampoline>("Derived");
-
-
-Out-of-the-box support for ``std::shared_ptr``
-----------------------------------------------
-
-The relevant type caster is now built in, so it's no longer necessary to
-include a declaration of the form:
-
-.. code-block:: cpp
-
-    PYBIND11_DECLARE_HOLDER_TYPE(T, std::shared_ptr<T>)
-
-Continuing to do so won't cause an error or even a deprecation warning,
-but it's completely redundant.
-
-
-Deprecation of a few ``py::object`` APIs
-----------------------------------------
-
-All of the old-style calls emit deprecation warnings.
-
-+---------------------------------------+---------------------------------------------+
-|  Old syntax                           |  New syntax                                 |
-+=======================================+=============================================+
-| ``obj.call(args...)``                 | ``obj(args...)``                            |
-+---------------------------------------+---------------------------------------------+
-| ``obj.str()``                         | ``py::str(obj)``                            |
-+---------------------------------------+---------------------------------------------+
-| ``auto l = py::list(obj); l.check()`` | ``py::isinstance<py::list>(obj)``           |
-+---------------------------------------+---------------------------------------------+
-| ``py::object(ptr, true)``             | ``py::reinterpret_borrow<py::object>(ptr)`` |
-+---------------------------------------+---------------------------------------------+
-| ``py::object(ptr, false)``            | ``py::reinterpret_steal<py::object>(ptr)``  |
-+---------------------------------------+---------------------------------------------+
-| ``if (obj.attr("foo"))``              | ``if (py::hasattr(obj, "foo"))``            |
-+---------------------------------------+---------------------------------------------+
-| ``if (obj["bar"])``                   | ``if (obj.contains("bar"))``                |
-+---------------------------------------+---------------------------------------------+
+Upgrade guide
+#############
+
+This is a companion guide to the :doc:`changelog`. While the changelog briefly
+lists all of the new features, improvements and bug fixes, this upgrade guide
+focuses only the subset which directly impacts your experience when upgrading
+to a new version. But it goes into more detail. This includes things like
+deprecated APIs and their replacements, build system changes, general code
+modernization and other useful information.
+
+.. _upgrade-guide-2.12:
+
+v2.12
+=====
+
+NumPy support has been upgraded to support the 2.x series too. The two relevant
+changes are that:
+
+* ``dtype.flags()`` is now a ``uint64`` and ``dtype.alignment()`` an
+  ``ssize_t`` (and NumPy may return an larger than integer value for
+  ``itemsize()`` in NumPy 2.x).
+
+* The long deprecated NumPy function ``PyArray_GetArrayParamsFromObject``
+  function is not available anymore.
+
+Due to NumPy changes, you may experience difficulties updating to NumPy 2.
+Please see the [NumPy 2 migration guide](https://numpy.org/devdocs/numpy_2_0_migration_guide.html) for details.
+For example, a more direct change could be that the default integer ``"int_"``
+(and ``"uint"``) is now ``ssize_t`` and not ``long`` (affects 64bit windows).
+
+If you want to only support NumPy 1.x for now and are having problems due to
+the two internal changes listed above, you can define
+``PYBIND11_NUMPY_1_ONLY`` to disable the new support for now. Make sure you
+define this on all pybind11 compile units, since it could be a source of ODR
+violations if used inconsistently. This option will be removed in the future,
+so adapting your code is highly recommended.
+
+
+.. _upgrade-guide-2.11:
+
+v2.11
+=====
+
+* The minimum version of CMake is now 3.5. A future version will likely move to
+  requiring something like CMake 3.15. Note that CMake 3.27 is removing the
+  long-deprecated support for ``FindPythonInterp`` if you set 3.27 as the
+  minimum or maximum supported version. To prepare for that future, CMake 3.15+
+  using ``FindPython`` or setting ``PYBIND11_FINDPYTHON`` is highly recommended,
+  otherwise pybind11 will automatically switch to using ``FindPython`` if
+  ``FindPythonInterp`` is not available.
+
+
+.. _upgrade-guide-2.9:
+
+v2.9
+====
+
+* Any usage of the recently added ``py::make_simple_namespace`` should be
+  converted to using ``py::module_::import("types").attr("SimpleNamespace")``
+  instead.
+
+* The use of ``_`` in custom type casters can now be replaced with the more
+  readable ``const_name`` instead. The old ``_`` shortcut has been retained
+  unless it is being used as a macro (like for gettext).
+
+
+.. _upgrade-guide-2.7:
+
+v2.7
+====
+
+*Before* v2.7, ``py::str`` can hold ``PyUnicodeObject`` or ``PyBytesObject``,
+and ``py::isinstance<str>()`` is ``true`` for both ``py::str`` and
+``py::bytes``. Starting with v2.7, ``py::str`` exclusively holds
+``PyUnicodeObject`` (`#2409 <https://github.com/pybind/pybind11/pull/2409>`_),
+and ``py::isinstance<str>()`` is ``true`` only for ``py::str``. To help in
+the transition of user code, the ``PYBIND11_STR_LEGACY_PERMISSIVE`` macro
+is provided as an escape hatch to go back to the legacy behavior. This macro
+will be removed in future releases. Two types of required fixes are expected
+to be common:
+
+* Accidental use of ``py::str`` instead of ``py::bytes``, masked by the legacy
+  behavior. These are probably very easy to fix, by changing from
+  ``py::str`` to ``py::bytes``.
+
+* Reliance on py::isinstance<str>(obj) being ``true`` for
+  ``py::bytes``. This is likely to be easy to fix in most cases by adding
+  ``|| py::isinstance<bytes>(obj)``, but a fix may be more involved, e.g. if
+  ``py::isinstance<T>`` appears in a template. Such situations will require
+  careful review and custom fixes.
+
+
+.. _upgrade-guide-2.6:
+
+v2.6
+====
+
+Usage of the ``PYBIND11_OVERLOAD*`` macros and ``get_overload`` function should
+be replaced by ``PYBIND11_OVERRIDE*`` and ``get_override``. In the future, the
+old macros may be deprecated and removed.
+
+``py::module`` has been renamed ``py::module_``, but a backward compatible
+typedef has been included. This change was to avoid a language change in C++20
+that requires unqualified ``module`` not be placed at the start of a logical
+line. Qualified usage is unaffected and the typedef will remain unless the
+C++ language rules change again.
+
+The public constructors of ``py::module_`` have been deprecated. Use
+``PYBIND11_MODULE`` or ``module_::create_extension_module`` instead.
+
+An error is now thrown when ``__init__`` is forgotten on subclasses. This was
+incorrect before, but was not checked. Add a call to ``__init__`` if it is
+missing.
+
+A ``py::type_error`` is now thrown when casting to a subclass (like
+``py::bytes`` from ``py::object``) if the conversion is not valid. Make a valid
+conversion instead.
+
+The undocumented ``h.get_type()`` method has been deprecated and replaced by
+``py::type::of(h)``.
+
+Enums now have a ``__str__`` method pre-defined; if you want to override it,
+the simplest fix is to add the new ``py::prepend()`` tag when defining
+``"__str__"``.
+
+If ``__eq__`` defined but not ``__hash__``, ``__hash__`` is now set to
+``None``, as in normal CPython. You should add ``__hash__`` if you intended the
+class to be hashable, possibly using the new ``py::hash`` shortcut.
+
+The constructors for ``py::array`` now always take signed integers for size,
+for consistency. This may lead to compiler warnings on some systems. Cast to
+``py::ssize_t`` instead of ``std::size_t``.
+
+The ``tools/clang`` submodule and ``tools/mkdoc.py`` have been moved to a
+standalone package, `pybind11-mkdoc`_. If you were using those tools, please
+use them via a pip install from the new location.
+
+The ``pybind11`` package on PyPI no longer fills the wheel "headers" slot - if
+you were using the headers from this slot, they are available by requesting the
+``global`` extra, that is, ``pip install "pybind11[global]"``. (Most users will
+be unaffected, as the ``pybind11/include`` location is reported by ``python -m
+pybind11 --includes`` and ``pybind11.get_include()`` is still correct and has
+not changed since 2.5).
+
+.. _pybind11-mkdoc: https://github.com/pybind/pybind11-mkdoc
+
+CMake support:
+--------------
+
+The minimum required version of CMake is now 3.4.  Several details of the CMake
+support have been deprecated; warnings will be shown if you need to change
+something. The changes are:
+
+* ``PYBIND11_CPP_STANDARD=<platform-flag>`` is deprecated, please use
+  ``CMAKE_CXX_STANDARD=<number>`` instead, or any other valid CMake CXX or CUDA
+  standard selection method, like ``target_compile_features``.
+
+* If you do not request a standard, pybind11 targets will compile with the
+  compiler default, but not less than C++11, instead of forcing C++14 always.
+  If you depend on the old behavior, please use ``set(CMAKE_CXX_STANDARD 14 CACHE STRING "")``
+  instead.
+
+* Direct ``pybind11::module`` usage should always be accompanied by at least
+  ``set(CMAKE_CXX_VISIBILITY_PRESET hidden)`` or similar - it used to try to
+  manually force this compiler flag (but not correctly on all compilers or with
+  CUDA).
+
+* ``pybind11_add_module``'s ``SYSTEM`` argument is deprecated and does nothing;
+  linking now behaves like other imported libraries consistently in both
+  config and submodule mode, and behaves like a ``SYSTEM`` library by
+  default.
+
+* If ``PYTHON_EXECUTABLE`` is not set, virtual environments (``venv``,
+  ``virtualenv``, and ``conda``) are prioritized over the standard search
+  (similar to the new FindPython mode).
+
+In addition, the following changes may be of interest:
+
+* ``CMAKE_INTERPROCEDURAL_OPTIMIZATION`` will be respected by
+  ``pybind11_add_module`` if set instead of linking to ``pybind11::lto`` or
+  ``pybind11::thin_lto``.
+
+* Using ``find_package(Python COMPONENTS Interpreter Development)`` before
+  pybind11 will cause pybind11 to use the new Python mechanisms instead of its
+  own custom search, based on a patched version of classic ``FindPythonInterp``
+  / ``FindPythonLibs``. In the future, this may become the default. A recent
+  (3.15+ or 3.18.2+) version of CMake is recommended.
+
+
+
+v2.5
+====
+
+The Python package now includes the headers as data in the package itself, as
+well as in the "headers" wheel slot. ``pybind11 --includes`` and
+``pybind11.get_include()`` report the new location, which is always correct
+regardless of how pybind11 was installed, making the old ``user=`` argument
+meaningless. If you are not using the function to get the location already, you
+are encouraged to switch to the package location.
+
+
+v2.2
+====
+
+Deprecation of the ``PYBIND11_PLUGIN`` macro
+--------------------------------------------
+
+``PYBIND11_MODULE`` is now the preferred way to create module entry points.
+The old macro emits a compile-time deprecation warning.
+
+.. code-block:: cpp
+
+    // old
+    PYBIND11_PLUGIN(example) {
+        py::module m("example", "documentation string");
+
+        m.def("add", [](int a, int b) { return a + b; });
+
+        return m.ptr();
+    }
+
+    // new
+    PYBIND11_MODULE(example, m) {
+        m.doc() = "documentation string"; // optional
+
+        m.def("add", [](int a, int b) { return a + b; });
+    }
+
+
+New API for defining custom constructors and pickling functions
+---------------------------------------------------------------
+
+The old placement-new custom constructors have been deprecated. The new approach
+uses ``py::init()`` and factory functions to greatly improve type safety.
+
+Placement-new can be called accidentally with an incompatible type (without any
+compiler errors or warnings), or it can initialize the same object multiple times
+if not careful with the Python-side ``__init__`` calls. The new-style custom
+constructors prevent such mistakes. See :ref:`custom_constructors` for details.
+
+.. code-block:: cpp
+
+    // old -- deprecated (runtime warning shown only in debug mode)
+    py::class<Foo>(m, "Foo")
+        .def("__init__", [](Foo &self, ...) {
+            new (&self) Foo(...); // uses placement-new
+        });
+
+    // new
+    py::class<Foo>(m, "Foo")
+        .def(py::init([](...) { // Note: no `self` argument
+            return new Foo(...); // return by raw pointer
+            // or: return std::make_unique<Foo>(...); // return by holder
+            // or: return Foo(...); // return by value (move constructor)
+        }));
+
+Mirroring the custom constructor changes, ``py::pickle()`` is now the preferred
+way to get and set object state. See :ref:`pickling` for details.
+
+.. code-block:: cpp
+
+    // old -- deprecated (runtime warning shown only in debug mode)
+    py::class<Foo>(m, "Foo")
+        ...
+        .def("__getstate__", [](const Foo &self) {
+            return py::make_tuple(self.value1(), self.value2(), ...);
+        })
+        .def("__setstate__", [](Foo &self, py::tuple t) {
+            new (&self) Foo(t[0].cast<std::string>(), ...);
+        });
+
+    // new
+    py::class<Foo>(m, "Foo")
+        ...
+        .def(py::pickle(
+            [](const Foo &self) { // __getstate__
+                return py::make_tuple(self.value1(), self.value2(), ...); // unchanged
+            },
+            [](py::tuple t) { // __setstate__, note: no `self` argument
+                return new Foo(t[0].cast<std::string>(), ...);
+                // or: return std::make_unique<Foo>(...); // return by holder
+                // or: return Foo(...); // return by value (move constructor)
+            }
+        ));
+
+For both the constructors and pickling, warnings are shown at module
+initialization time (on import, not when the functions are called).
+They're only visible when compiled in debug mode. Sample warning:
+
+.. code-block:: none
+
+    pybind11-bound class 'mymodule.Foo' is using an old-style placement-new '__init__'
+    which has been deprecated. See the upgrade guide in pybind11's docs.
+
+
+Stricter enforcement of hidden symbol visibility for pybind11 modules
+---------------------------------------------------------------------
+
+pybind11 now tries to actively enforce hidden symbol visibility for modules.
+If you're using either one of pybind11's :doc:`CMake or Python build systems
+<compiling>` (the two example repositories) and you haven't been exporting any
+symbols, there's nothing to be concerned about. All the changes have been done
+transparently in the background. If you were building manually or relied on
+specific default visibility, read on.
+
+Setting default symbol visibility to *hidden* has always been recommended for
+pybind11 (see :ref:`faq:symhidden`). On Linux and macOS, hidden symbol
+visibility (in conjunction with the ``strip`` utility) yields much smaller
+module binaries. `CPython's extension docs`_ also recommend hiding symbols
+by default, with the goal of avoiding symbol name clashes between modules.
+Starting with v2.2, pybind11 enforces this more strictly: (1) by declaring
+all symbols inside the ``pybind11`` namespace as hidden and (2) by including
+the ``-fvisibility=hidden`` flag on Linux and macOS (only for extension
+modules, not for embedding the interpreter).
+
+.. _CPython's extension docs: https://docs.python.org/3/extending/extending.html#providing-a-c-api-for-an-extension-module
+
+The namespace-scope hidden visibility is done automatically in pybind11's
+headers and it's generally transparent to users. It ensures that:
+
+* Modules compiled with different pybind11 versions don't clash with each other.
+
+* Some new features, like ``py::module_local`` bindings, can work as intended.
+
+The ``-fvisibility=hidden`` flag applies the same visibility to user bindings
+outside of the ``pybind11`` namespace. It's now set automatic by pybind11's
+CMake and Python build systems, but this needs to be done manually by users
+of other build systems. Adding this flag:
+
+* Minimizes the chances of symbol conflicts between modules. E.g. if two
+  unrelated modules were statically linked to different (ABI-incompatible)
+  versions of the same third-party library, a symbol clash would be likely
+  (and would end with unpredictable results).
+
+* Produces smaller binaries on Linux and macOS, as pointed out previously.
+
+Within pybind11's CMake build system, ``pybind11_add_module`` has always been
+setting the ``-fvisibility=hidden`` flag in release mode. From now on, it's
+being applied unconditionally, even in debug mode and it can no longer be opted
+out of with the ``NO_EXTRAS`` option. The ``pybind11::module`` target now also
+adds this flag to its interface. The ``pybind11::embed`` target is unchanged.
+
+The most significant change here is for the ``pybind11::module`` target. If you
+were previously relying on default visibility, i.e. if your Python module was
+doubling as a shared library with dependents, you'll need to either export
+symbols manually (recommended for cross-platform libraries) or factor out the
+shared library (and have the Python module link to it like the other
+dependents). As a temporary workaround, you can also restore default visibility
+using the CMake code below, but this is not recommended in the long run:
+
+.. code-block:: cmake
+
+    target_link_libraries(mymodule PRIVATE pybind11::module)
+
+    add_library(restore_default_visibility INTERFACE)
+    target_compile_options(restore_default_visibility INTERFACE -fvisibility=default)
+    target_link_libraries(mymodule PRIVATE restore_default_visibility)
+
+
+Local STL container bindings
+----------------------------
+
+Previous pybind11 versions could only bind types globally -- all pybind11
+modules, even unrelated ones, would have access to the same exported types.
+However, this would also result in a conflict if two modules exported the
+same C++ type, which is especially problematic for very common types, e.g.
+``std::vector<int>``. :ref:`module_local` were added to resolve this (see
+that section for a complete usage guide).
+
+``py::class_`` still defaults to global bindings (because these types are
+usually unique across modules), however in order to avoid clashes of opaque
+types, ``py::bind_vector`` and ``py::bind_map`` will now bind STL containers
+as ``py::module_local`` if their elements are: builtins (``int``, ``float``,
+etc.), not bound using ``py::class_``, or bound as ``py::module_local``. For
+example, this change allows multiple modules to bind ``std::vector<int>``
+without causing conflicts. See :ref:`stl_bind` for more details.
+
+When upgrading to this version, if you have multiple modules which depend on
+a single global binding of an STL container, note that all modules can still
+accept foreign  ``py::module_local`` types in the direction of Python-to-C++.
+The locality only affects the C++-to-Python direction. If this is needed in
+multiple modules, you'll need to either:
+
+* Add a copy of the same STL binding to all of the modules which need it.
+
+* Restore the global status of that single binding by marking it
+  ``py::module_local(false)``.
+
+The latter is an easy workaround, but in the long run it would be best to
+localize all common type bindings in order to avoid conflicts with
+third-party modules.
+
+
+Negative strides for Python buffer objects and numpy arrays
+-----------------------------------------------------------
+
+Support for negative strides required changing the integer type from unsigned
+to signed in the interfaces of ``py::buffer_info`` and ``py::array``. If you
+have compiler warnings enabled, you may notice some new conversion warnings
+after upgrading. These can be resolved using ``static_cast``.
+
+
+Deprecation of some ``py::object`` APIs
+---------------------------------------
+
+To compare ``py::object`` instances by pointer, you should now use
+``obj1.is(obj2)`` which is equivalent to ``obj1 is obj2`` in Python.
+Previously, pybind11 used ``operator==`` for this (``obj1 == obj2``), but
+that could be confusing and is now deprecated (so that it can eventually
+be replaced with proper rich object comparison in a future release).
+
+For classes which inherit from ``py::object``, ``borrowed`` and ``stolen``
+were previously available as protected constructor tags. Now the types
+should be used directly instead: ``borrowed_t{}`` and ``stolen_t{}``
+(`#771 <https://github.com/pybind/pybind11/pull/771>`_).
+
+
+Stricter compile-time error checking
+------------------------------------
+
+Some error checks have been moved from run time to compile time. Notably,
+automatic conversion of ``std::shared_ptr<T>`` is not possible when ``T`` is
+not directly registered with ``py::class_<T>`` (e.g. ``std::shared_ptr<int>``
+or ``std::shared_ptr<std::vector<T>>`` are not automatically convertible).
+Attempting to bind a function with such arguments now results in a compile-time
+error instead of waiting to fail at run time.
+
+``py::init<...>()`` constructor definitions are also stricter and now prevent
+bindings which could cause unexpected behavior:
+
+.. code-block:: cpp
+
+    struct Example {
+        Example(int &);
+    };
+
+    py::class_<Example>(m, "Example")
+        .def(py::init<int &>()); // OK, exact match
+        // .def(py::init<int>()); // compile-time error, mismatch
+
+A non-``const`` lvalue reference is not allowed to bind to an rvalue. However,
+note that a constructor taking ``const T &`` can still be registered using
+``py::init<T>()`` because a ``const`` lvalue reference can bind to an rvalue.
+
+v2.1
+====
+
+Minimum compiler versions are enforced at compile time
+------------------------------------------------------
+
+The minimums also apply to v2.0 but the check is now explicit and a compile-time
+error is raised if the compiler does not meet the requirements:
+
+* GCC >= 4.8
+* clang >= 3.3 (appleclang >= 5.0)
+* MSVC >= 2015u3
+* Intel C++ >= 15.0
+
+
+The ``py::metaclass`` attribute is not required for static properties
+---------------------------------------------------------------------
+
+Binding classes with static properties is now possible by default. The
+zero-parameter version of ``py::metaclass()`` is deprecated. However, a new
+one-parameter ``py::metaclass(python_type)`` version was added for rare
+cases when a custom metaclass is needed to override pybind11's default.
+
+.. code-block:: cpp
+
+    // old -- emits a deprecation warning
+    py::class_<Foo>(m, "Foo", py::metaclass())
+        .def_property_readonly_static("foo", ...);
+
+    // new -- static properties work without the attribute
+    py::class_<Foo>(m, "Foo")
+        .def_property_readonly_static("foo", ...);
+
+    // new -- advanced feature, override pybind11's default metaclass
+    py::class_<Bar>(m, "Bar", py::metaclass(custom_python_type))
+        ...
+
+
+v2.0
+====
+
+Breaking changes in ``py::class_``
+----------------------------------
+
+These changes were necessary to make type definitions in pybind11
+future-proof, to support PyPy via its ``cpyext`` mechanism (`#527
+<https://github.com/pybind/pybind11/pull/527>`_), and to improve efficiency
+(`rev. 86d825 <https://github.com/pybind/pybind11/commit/86d825>`_).
+
+1. Declarations of types that provide access via the buffer protocol must
+   now include the ``py::buffer_protocol()`` annotation as an argument to
+   the ``py::class_`` constructor.
+
+   .. code-block:: cpp
+
+       py::class_<Matrix>("Matrix", py::buffer_protocol())
+           .def(py::init<...>())
+           .def_buffer(...);
+
+2. Classes which include static properties (e.g. ``def_readwrite_static()``)
+   must now include the ``py::metaclass()`` attribute. Note: this requirement
+   has since been removed in v2.1. If you're upgrading from 1.x, it's
+   recommended to skip directly to v2.1 or newer.
+
+3. This version of pybind11 uses a redesigned mechanism for instantiating
+   trampoline classes that are used to override virtual methods from within
+   Python. This led to the following user-visible syntax change:
+
+   .. code-block:: cpp
+
+       // old v1.x syntax
+       py::class_<TrampolineClass>("MyClass")
+           .alias<MyClass>()
+           ...
+
+       // new v2.x syntax
+       py::class_<MyClass, TrampolineClass>("MyClass")
+           ...
+
+   Importantly, both the original and the trampoline class are now specified
+   as arguments to the ``py::class_`` template, and the ``alias<..>()`` call
+   is gone. The new scheme has zero overhead in cases when Python doesn't
+   override any functions of the underlying C++ class.
+   `rev. 86d825 <https://github.com/pybind/pybind11/commit/86d825>`_.
+
+   The class type must be the first template argument given to ``py::class_``
+   while the trampoline can be mixed in arbitrary order with other arguments
+   (see the following section).
+
+
+Deprecation of the ``py::base<T>()`` attribute
+----------------------------------------------
+
+``py::base<T>()`` was deprecated in favor of specifying ``T`` as a template
+argument to ``py::class_``. This new syntax also supports multiple inheritance.
+Note that, while the type being exported must be the first argument in the
+``py::class_<Class, ...>`` template, the order of the following types (bases,
+holder and/or trampoline) is not important.
+
+.. code-block:: cpp
+
+    // old v1.x
+    py::class_<Derived>("Derived", py::base<Base>());
+
+    // new v2.x
+    py::class_<Derived, Base>("Derived");
+
+    // new -- multiple inheritance
+    py::class_<Derived, Base1, Base2>("Derived");
+
+    // new -- apart from `Derived` the argument order can be arbitrary
+    py::class_<Derived, Base1, Holder, Base2, Trampoline>("Derived");
+
+
+Out-of-the-box support for ``std::shared_ptr``
+----------------------------------------------
+
+The relevant type caster is now built in, so it's no longer necessary to
+include a declaration of the form:
+
+.. code-block:: cpp
+
+    PYBIND11_DECLARE_HOLDER_TYPE(T, std::shared_ptr<T>)
+
+Continuing to do so won't cause an error or even a deprecation warning,
+but it's completely redundant.
+
+
+Deprecation of a few ``py::object`` APIs
+----------------------------------------
+
+All of the old-style calls emit deprecation warnings.
+
++---------------------------------------+---------------------------------------------+
+|  Old syntax                           |  New syntax                                 |
++=======================================+=============================================+
+| ``obj.call(args...)``                 | ``obj(args...)``                            |
++---------------------------------------+---------------------------------------------+
+| ``obj.str()``                         | ``py::str(obj)``                            |
++---------------------------------------+---------------------------------------------+
+| ``auto l = py::list(obj); l.check()`` | ``py::isinstance<py::list>(obj)``           |
++---------------------------------------+---------------------------------------------+
+| ``py::object(ptr, true)``             | ``py::reinterpret_borrow<py::object>(ptr)`` |
++---------------------------------------+---------------------------------------------+
+| ``py::object(ptr, false)``            | ``py::reinterpret_steal<py::object>(ptr)``  |
++---------------------------------------+---------------------------------------------+
+| ``if (obj.attr("foo"))``              | ``if (py::hasattr(obj, "foo"))``            |
++---------------------------------------+---------------------------------------------+
+| ``if (obj["bar"])``                   | ``if (obj.contains("bar"))``                |
++---------------------------------------+---------------------------------------------+

third_party/CityFlow/extern/pybind11/noxfile.py

@@ -1,107 +1,107 @@
-import os
-
-import nox
-
-nox.needs_version = ">=2022.1.7"
-nox.options.sessions = ["lint", "tests", "tests_packaging"]
-
-PYTHON_VERSIONS = [
-    "3.6",
-    "3.7",
-    "3.8",
-    "3.9",
-    "3.10",
-    "3.11",
-    "pypy3.7",
-    "pypy3.8",
-    "pypy3.9",
-]
-
-if os.environ.get("CI", None):
-    nox.options.error_on_missing_interpreters = True
-
-
-@nox.session(reuse_venv=True)
-def lint(session: nox.Session) -> None:
-    """
-    Lint the codebase (except for clang-format/tidy).
-    """
-    session.install("pre-commit")
-    session.run("pre-commit", "run", "-a", *session.posargs)
-
-
-@nox.session(python=PYTHON_VERSIONS)
-def tests(session: nox.Session) -> None:
-    """
-    Run the tests (requires a compiler).
-    """
-    tmpdir = session.create_tmp()
-    session.install("cmake")
-    session.install("-r", "tests/requirements.txt")
-    session.run(
-        "cmake",
-        "-S.",
-        f"-B{tmpdir}",
-        "-DPYBIND11_WERROR=ON",
-        "-DDOWNLOAD_CATCH=ON",
-        "-DDOWNLOAD_EIGEN=ON",
-        *session.posargs,
-    )
-    session.run("cmake", "--build", tmpdir)
-    session.run("cmake", "--build", tmpdir, "--config=Release", "--target", "check")
-
-
-@nox.session
-def tests_packaging(session: nox.Session) -> None:
-    """
-    Run the packaging tests.
-    """
-
-    session.install("-r", "tests/requirements.txt")
-    session.run("pytest", "tests/extra_python_package", *session.posargs)
-
-
-@nox.session(reuse_venv=True)
-def docs(session: nox.Session) -> None:
-    """
-    Build the docs. Pass "serve" to serve.
-    """
-
-    session.install("-r", "docs/requirements.txt")
-    session.chdir("docs")
-
-    if "pdf" in session.posargs:
-        session.run("sphinx-build", "-M", "latexpdf", ".", "_build")
-        return
-
-    session.run("sphinx-build", "-M", "html", ".", "_build")
-
-    if "serve" in session.posargs:
-        session.log("Launching docs at http://localhost:8000/ - use Ctrl-C to quit")
-        session.run("python", "-m", "http.server", "8000", "-d", "_build/html")
-    elif session.posargs:
-        session.error("Unsupported argument to docs")
-
-
-@nox.session(reuse_venv=True)
-def make_changelog(session: nox.Session) -> None:
-    """
-    Inspect the closed issues and make entries for a changelog.
-    """
-    session.install("ghapi", "rich")
-    session.run("python", "tools/make_changelog.py")
-
-
-@nox.session(reuse_venv=True)
-def build(session: nox.Session) -> None:
-    """
-    Build SDists and wheels.
-    """
-
-    session.install("build")
-    session.log("Building normal files")
-    session.run("python", "-m", "build", *session.posargs)
-    session.log("Building pybind11-global files (PYBIND11_GLOBAL_SDIST=1)")
-    session.run(
-        "python", "-m", "build", *session.posargs, env={"PYBIND11_GLOBAL_SDIST": "1"}
-    )
+import os
+
+import nox
+
+nox.needs_version = ">=2022.1.7"
+nox.options.sessions = ["lint", "tests", "tests_packaging"]
+
+PYTHON_VERSIONS = [
+    "3.6",
+    "3.7",
+    "3.8",
+    "3.9",
+    "3.10",
+    "3.11",
+    "pypy3.7",
+    "pypy3.8",
+    "pypy3.9",
+]
+
+if os.environ.get("CI", None):
+    nox.options.error_on_missing_interpreters = True
+
+
+@nox.session(reuse_venv=True)
+def lint(session: nox.Session) -> None:
+    """
+    Lint the codebase (except for clang-format/tidy).
+    """
+    session.install("pre-commit")
+    session.run("pre-commit", "run", "-a", *session.posargs)
+
+
+@nox.session(python=PYTHON_VERSIONS)
+def tests(session: nox.Session) -> None:
+    """
+    Run the tests (requires a compiler).
+    """
+    tmpdir = session.create_tmp()
+    session.install("cmake")
+    session.install("-r", "tests/requirements.txt")
+    session.run(
+        "cmake",
+        "-S.",
+        f"-B{tmpdir}",
+        "-DPYBIND11_WERROR=ON",
+        "-DDOWNLOAD_CATCH=ON",
+        "-DDOWNLOAD_EIGEN=ON",
+        *session.posargs,
+    )
+    session.run("cmake", "--build", tmpdir)
+    session.run("cmake", "--build", tmpdir, "--config=Release", "--target", "check")
+
+
+@nox.session
+def tests_packaging(session: nox.Session) -> None:
+    """
+    Run the packaging tests.
+    """
+
+    session.install("-r", "tests/requirements.txt")
+    session.run("pytest", "tests/extra_python_package", *session.posargs)
+
+
+@nox.session(reuse_venv=True)
+def docs(session: nox.Session) -> None:
+    """
+    Build the docs. Pass "serve" to serve.
+    """
+
+    session.install("-r", "docs/requirements.txt")
+    session.chdir("docs")
+
+    if "pdf" in session.posargs:
+        session.run("sphinx-build", "-M", "latexpdf", ".", "_build")
+        return
+
+    session.run("sphinx-build", "-M", "html", ".", "_build")
+
+    if "serve" in session.posargs:
+        session.log("Launching docs at http://localhost:8000/ - use Ctrl-C to quit")
+        session.run("python", "-m", "http.server", "8000", "-d", "_build/html")
+    elif session.posargs:
+        session.error("Unsupported argument to docs")
+
+
+@nox.session(reuse_venv=True)
+def make_changelog(session: nox.Session) -> None:
+    """
+    Inspect the closed issues and make entries for a changelog.
+    """
+    session.install("ghapi", "rich")
+    session.run("python", "tools/make_changelog.py")
+
+
+@nox.session(reuse_venv=True)
+def build(session: nox.Session) -> None:
+    """
+    Build SDists and wheels.
+    """
+
+    session.install("build")
+    session.log("Building normal files")
+    session.run("python", "-m", "build", *session.posargs)
+    session.log("Building pybind11-global files (PYBIND11_GLOBAL_SDIST=1)")
+    session.run(
+        "python", "-m", "build", *session.posargs, env={"PYBIND11_GLOBAL_SDIST": "1"}
+    )

third_party/CityFlow/extern/pybind11/pybind11/__init__.py

@@ -1,17 +1,17 @@
-import sys
-
-if sys.version_info < (3, 6):  # noqa: UP036
-    msg = "pybind11 does not support Python < 3.6. 2.9 was the last release supporting Python 2.7 and 3.5."
-    raise ImportError(msg)
-
-
-from ._version import __version__, version_info
-from .commands import get_cmake_dir, get_include, get_pkgconfig_dir
-
-__all__ = (
-    "version_info",
-    "__version__",
-    "get_include",
-    "get_cmake_dir",
-    "get_pkgconfig_dir",
-)
+import sys
+
+if sys.version_info < (3, 6):  # noqa: UP036
+    msg = "pybind11 does not support Python < 3.6. 2.9 was the last release supporting Python 2.7 and 3.5."
+    raise ImportError(msg)
+
+
+from ._version import __version__, version_info
+from .commands import get_cmake_dir, get_include, get_pkgconfig_dir
+
+__all__ = (
+    "version_info",
+    "__version__",
+    "get_include",
+    "get_cmake_dir",
+    "get_pkgconfig_dir",
+)

third_party/CityFlow/extern/pybind11/pybind11/__main__.py

@@ -1,62 +1,62 @@
-# pylint: disable=missing-function-docstring
-
-import argparse
-import sys
-import sysconfig
-
-from ._version import __version__
-from .commands import get_cmake_dir, get_include, get_pkgconfig_dir
-
-
-def print_includes() -> None:
-    dirs = [
-        sysconfig.get_path("include"),
-        sysconfig.get_path("platinclude"),
-        get_include(),
-    ]
-
-    # Make unique but preserve order
-    unique_dirs = []
-    for d in dirs:
-        if d and d not in unique_dirs:
-            unique_dirs.append(d)
-
-    print(" ".join("-I" + d for d in unique_dirs))
-
-
-def main() -> None:
-    parser = argparse.ArgumentParser()
-    parser.add_argument(
-        "--version",
-        action="version",
-        version=__version__,
-        help="Print the version and exit.",
-    )
-    parser.add_argument(
-        "--includes",
-        action="store_true",
-        help="Include flags for both pybind11 and Python headers.",
-    )
-    parser.add_argument(
-        "--cmakedir",
-        action="store_true",
-        help="Print the CMake module directory, ideal for setting -Dpybind11_ROOT in CMake.",
-    )
-    parser.add_argument(
-        "--pkgconfigdir",
-        action="store_true",
-        help="Print the pkgconfig directory, ideal for setting $PKG_CONFIG_PATH.",
-    )
-    args = parser.parse_args()
-    if not sys.argv[1:]:
-        parser.print_help()
-    if args.includes:
-        print_includes()
-    if args.cmakedir:
-        print(get_cmake_dir())
-    if args.pkgconfigdir:
-        print(get_pkgconfig_dir())
-
-
-if __name__ == "__main__":
-    main()
+# pylint: disable=missing-function-docstring
+
+import argparse
+import sys
+import sysconfig
+
+from ._version import __version__
+from .commands import get_cmake_dir, get_include, get_pkgconfig_dir
+
+
+def print_includes() -> None:
+    dirs = [
+        sysconfig.get_path("include"),
+        sysconfig.get_path("platinclude"),
+        get_include(),
+    ]
+
+    # Make unique but preserve order
+    unique_dirs = []
+    for d in dirs:
+        if d and d not in unique_dirs:
+            unique_dirs.append(d)
+
+    print(" ".join("-I" + d for d in unique_dirs))
+
+
+def main() -> None:
+    parser = argparse.ArgumentParser()
+    parser.add_argument(
+        "--version",
+        action="version",
+        version=__version__,
+        help="Print the version and exit.",
+    )
+    parser.add_argument(
+        "--includes",
+        action="store_true",
+        help="Include flags for both pybind11 and Python headers.",
+    )
+    parser.add_argument(
+        "--cmakedir",
+        action="store_true",
+        help="Print the CMake module directory, ideal for setting -Dpybind11_ROOT in CMake.",
+    )
+    parser.add_argument(
+        "--pkgconfigdir",
+        action="store_true",
+        help="Print the pkgconfig directory, ideal for setting $PKG_CONFIG_PATH.",
+    )
+    args = parser.parse_args()
+    if not sys.argv[1:]:
+        parser.print_help()
+    if args.includes:
+        print_includes()
+    if args.cmakedir:
+        print(get_cmake_dir())
+    if args.pkgconfigdir:
+        print(get_pkgconfig_dir())
+
+
+if __name__ == "__main__":
+    main()

third_party/CityFlow/extern/pybind11/pybind11/_version.py

@@ -1,12 +1,12 @@
-from typing import Union
-
-
-def _to_int(s: str) -> Union[int, str]:
-    try:
-        return int(s)
-    except ValueError:
-        return s
-
-
-__version__ = "2.12.0"
-version_info = tuple(_to_int(s) for s in __version__.split("."))
+from typing import Union
+
+
+def _to_int(s: str) -> Union[int, str]:
+    try:
+        return int(s)
+    except ValueError:
+        return s
+
+
+__version__ = "2.12.0"
+version_info = tuple(_to_int(s) for s in __version__.split("."))