* This tries to ast parse source that may contain an error.
* We don't try to fully error recover from unlimited problems, but a single
statement that is being edited can be tolerated by commenting out lines around
it
* We buffer output to avoid spamming huge numbers of signals especially when
single lines can be many write calls. This means if an exception is processed
immediately after a print the output from the print may come after the
extension.
* This is not the default python layout but is convenient for sharing the
standard library .zip and include folder with separate binary folders per-
platform. The layout mirrors what we include in the repository.
* This is expected to be in a pyside\ subfolder, with an organisation matching
our default setup.
* We also now copy the shiboken2 python module (if it exists) as required by new
pyside2 versions.
* We create both a stubs folder for each specific version, and a 'latest' that
is updated by newer RD versions.
* For development, the stubs will be regenerated any time the git commit hash
changes for development builds.
* In a previous update in 2021 many copyright ranges were truncated
accidentally, and some files have been copy-pasted with wrong years. These
dates have been fixed based on git history and original copyright messages.
* We shouldn't require 'pure virtual' functions in CaptureViewer implementations
in python, so detect when the derived class methods point to the base class
pass-throughs, and skip them in that case.
* We keep parent references when returning child objects via reference/python
object wrappers rather than copying. But when iterating a linked list like the
actions this can produce an incredibly long parent chain and then on
destruction we can stack overflow if the chain is long enough.
* These are temporarily given separate names, to allow them to exist in parallel
with the existing helpers, but in future these will be renamed when the older
helpers are removed.
* This is a consideration for any cases where binding numbers are relevant -
primarily D3D11 and GL - where the offset into an arbitrary (and possibly
fake) descriptor storage is not helpful but knowing the register binding
definitely is.
* If someone wants to look at the raw descriptor contents without respect to a
particular shader access they can use this query to determine a more useful
'name' for any given descriptor. On D3D11 and GL this gives the register
number, on Vulkan it gives the binding number (and array element). On D3D12 it
just repeats the offset effectively.
* Baking these into descriptors when we get arbitrary 'GetDescriptor' queries
independent of the bound descriptor sets is not possible - a descriptor set
could be in theory bound twice to two places with different dynamic offsets.
* Instead we report these as part of the pipeline states and the abstraction &
replay API consumer will need to manually apply them to get the true buffer
offset.
* The offsets are indexed by descriptor storage byte offset for easier
processing (the dynamic offset struct can be turned into a pair and used to
initialise a dict)
baldurk