* This is a little specific to us, but when we see references to a `renderdoc`
module etc we want to be able to look up the generated stubs instead as they
have better type hints for processing.
* 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.
* This is the only thing missing from an installed version of python to be able
to build against it, so it's convenient to rebuild it instead of fetching it
separately from the embeddable distribution
* 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.
* This is smaller and easier to maintain, and adds functionality like resolving
circular dependencies to be able to import the stubs as-is on python 3.6+
* Some markers from the application may be unbalanced, or it might be unbalanced
if we began the capture with some markers already open (e.g. due to a push/pop
around present).
When MRTSS is used, resolveImageView must be NULL since resolve happens
into the same image:
> VUID-VkRenderingAttachmentInfo-imageView-06863
> If imageView is not VK_NULL_HANDLE, resolveMode is not VK_RESOLVE_MODE_NONE,
> the pNext chain of VkRenderingInfo includes a VkMultisampledRenderToSingleSampledInfoEXT
> structure with the multisampledRenderToSingleSampledEnable field equal to
> VK_TRUE, and imageView has a sample count of VK_SAMPLE_COUNT_1_BIT,
> resolveImageView must be VK_NULL_HANDLE
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
* Debug info could theoretically contain names which include path like
characters including '.' or '[]' even though these wouldn't be valid
identifier names. We assume this will not happen with names that are part of
structures/arrays themselves but instead only happen if there's a single
matching path.
baldurk