Made 'Sample' come first again and thereby made it easier to use for
quick experiments and smoke testing.

Bug: b/156739423
Change-Id: Ic821aba66afbac97556b072750e24747af1010de
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45208
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>

Previously we relied on the default copy constructor to be generated
when ENABLE_RR_DEBUG_INFO is disabled. This is not necessary as we can
just use the straightforward manual definition of it in either case.
Note RR_DEBUG_INFO_EMIT_VAR() is a no-op when ENABLE_RR_DEBUG_INFO is
disabled.

Bug: b/155302798
Change-Id: I04c020a795b4333e3c3d0a7ed375d21d9382e3d1
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45152
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>

From https://gcc.gnu.org/onlinedocs/gcc-9.3.0/gcc/Name-lookup.html:
"The C++ standard prescribes that all names that are not dependent on
template parameters are bound to their present definitions when parsing
a template function or class.5 Only names that are dependent are looked
up at the point of instantiation.
...
To make the code valid either use this->f(), or Base<T>::f()"

It is best to use the this->f() solution because it could be a virtual
method.

Also use the type-safe load() and store() methods where possible.

Bug: b/155302798
Change-Id: Id636bfb0b1aae9529bf7f3f58213ec7823d9eddd
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45150
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>

We only need to know the array size during materialization of Array<>
types, so store it only for that class and make the allocation a
virtual method.

This change removes the REACTOR_MATERIALIZE_LVALUES_ON_DEFINITION
option, since it requires knowing the full size of Variable at
construction, which would require Array<> to still pass that into the
Variable constructor. If we need an debugging feature like this again,
we could also materialize variables on first use instead of at
construction.

Bug: b/155302798
Change-Id: I65b02c1258643dcbd3ae18f3f097cb815efa0830
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45148
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>

Bug: none
Change-Id: I1e9d97e95fea1e9c2863211c711feda6d794a825
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45268
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Antonio Maiorano <amaiorano@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

This will enable us to lazily create the underlying Value* in subsequent
changes.

Also make Argument<T> encapsulate its value, and make it type-safe.

Bug: b/155302798
Change-Id: I50eb16be06bc83e6c87b11f11effed33bee7107a
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44671Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>

This methods returns an RValue<T> type so it's safer than 'loadValue()'.

Bug: b/155302798
Change-Id: Ib48819bd0a1b64ae2d22eda4910ad0b551b1eed7
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44670
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>

These methods operate on RValue<T> types so they're safer than
'loadValue()' and 'storeValue()'. They also enable overloading
the latter in subsequent changes.

Bug: b/155302798
Change-Id: I30903fc70e353dfd668873122ad7d8f74e857420
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44669
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>

This is just a refactoring which avoids storing the type as a Variable
fields, since the 'LValue<T>' subclass knows the type statically and we
only need it during materialization.

This gives us a vtable for overloading other methods in subsequent
changes, at no additional storage cost for Variable.

Bug: b/155302798
Change-Id: I36f6ef8f5f4d2b50ba04d539dc8b9735481c816a
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44668
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>

This is just a refactoring which will allow adding a virtual getType()
method in a subsequent change without overload naming conflicts.

'isVoid()' has been removed since it appears unused now.

Bug: b/155302798
Change-Id: I16f5cbd947da9581e0f20837497f6b61cfeb7a21
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45008
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>

Previously any SPIR-V OpExecutionMode instruction would override the
execution mode parameters, so a shader module with multiple entry points
with different execution modes would not work as intended.

Bug: b/155550449
Change-Id: I86211e66a3cef5a3bbf9e535e9be8415b5d69d4b
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45249
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>

Doing a test run with LLVM after the one with Subzero results in various
tests timing out (including some 'UNSUPPORTED' ones). The Subzero test
run doesn't exhibit this issue. It's unclear at this point why this
happens, but reversing the order appears to stabilize it.

Bug: b/156728197
Change-Id: I6450d2d95d6043ef206d09f0020313fbf4b3f2e2
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45149Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>

In has16bitTextureFormat(), we were missing several formats. Also this
function was poorly named, as it made it seem like we were just
duplicating the work of the bytes() function but giving less
informations. What has16bitTextureFormat() is really checking for is if
the texture format is 16 bit Packed. So it's been renamed to
has16bitPackedTextureFormat()

Bug: b/150076646
Change-Id: I8082e8e9d3845cfa3b5c3ec4a269454457d558ce
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/42688Tested-by: Sean Risser <srisser@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

ANGLE uses image blit to generate mipmaps so, for cubemaps,
a border update is required after we blit into an image so
that the cube's border are still seamless when using lower
mip levels.

Fixes WebGL Conformance Test:
conformance/textures/misc/texture-size.html

Bug: b/154620294
Change-Id: I22daf60afd9143c52a57c67ae0039eb49be4f1ca
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44990
Presubmit-Ready: Alexis Hétu <sugoi@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

The reply function for xcb_get_geometry was called without handling errors,
causing a null-dereference in the fuzzer. These calls should be wrapped and
handled safely.

Bug: chromium:1080987
Change-Id: Ie1377909b68375fa9bc6eb54bdcbfda0627fd680
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45068
Presubmit-Ready: Jonah Ryan-Davis <jonahr@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Jonah Ryan-Davis <jonahr@google.com>

According to the Vulkan spec:

2.9.2. Conversion from Floating-Point to Normalized Fixed-Point
"The conversion from a floating-point value f to the corresponding
 unsigned normalized fixed-point value c is defined by first
 clamping f to the range [0,1], then computing ..."

Also, in section 18.3. Clear Values:
"float32 are the color clear values when the format of the image or
 attachment is one of the formats in the Interpretation of Numeric
 Format table other than signed integer (SINT) or unsigned integer
 (UINT). Floating point values are automatically converted to the
 format of the image, with the clear value being treated as linear
 if the image is sRGB"

Added a clamp to sRGB values to avoid getting out of bound values
for the sRGB color space.

Bug: b/151469361
Change-Id: I22615b807384904ca4fa887e93529d5a4b185d04
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45090
Presubmit-Ready: Alexis Hétu <sugoi@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Alexis Hétu <sugoi@google.com>

This lets users specify the level of sampling precision they want.
Chromium needs this to pass WebGL tests with SWANGLE.

Bug: b/146423360
Bug: b/154620295

Change-Id: I83575823b5909d836c3d4c02803ba7909ce08935
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/42268Tested-by: Antonio Maiorano <amaiorano@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>

This prevents '400 Bad Request' responses. The limit of 16000 was
determined through experimentation.

Bug: b/150284316
Change-Id: I5507efdcfbaac2c09c2dffde9bf173f4f9219a72
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44989Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>

This reverts commit cd09f8e9.

Reason for revert: Kokoro build failures

Bug: b/130335507
Change-Id: I5479cc40723ae3a95e3d9fb7b74de8506f188e08
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44928Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>

Exporting all typeinfo was copied over from the GLES version scripts
which addressed crbug.com/737384. However, this can lead to ODR
violations, and we have several other solutions in place for avoiding
UBSan failures.

Remove it entirely for now. If this causes a regression and we still
have to export some typeinfo, we should do so selectively. For example
to only export typeinfo for objects in the vk namespace:
_ZTS*vk*;
_ZTI*vk*;
Alternatively, or in addition, we can try using
'-mllvm -asan-use-private-alias=1'.

Bug: b/155441530
Change-Id: I07303ac01b05d02b879fff829b6a9945c16fdf82
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44689
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>

This is already a warning treated as an error by GCC/Clang:
-Werror=delete-non-virtual-dtor

Bug: b/130335507
Change-Id: I9d44f668168e2a77da8839017871e469f5d53bcb
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44788Tested-by: Nicolas Capens <nicolascapens@google.com>
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>

Followup to:
https://swiftshader-review.googlesource.com/c/SwiftShader/+/43950

Fixes dEQP.KHR_GLES31/core_compute_shader_copyimage.
This dEQP test was passing by chance, because load and store
were paired properly together, being equally incorrect with
regards to the OpenGL ES specs, which mentions:

GLES 3.1 spec, section 8.22:
If the individual texel identified for an image load or store
operation doesn’t exist, the access is treated as invalid.
Invalid image loads will return a vector where the value of
R, G, and B components is 0 and the value of the A component
is undefined. Invalid image stores will have no effect.

Bug: b/150464740
Change-Id: I5aa508ed7f08e234387478d3a6faee958ca9dd97
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44868
Presubmit-Ready: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Alexis Hétu <sugoi@google.com>

`target_compile_options` should have been `target_compile_definitions`

Also remove the global `set_cpp_flag` for these defines which are now unnecessary.

Bug: b/145758253
Change-Id: Ie03b0ad196bd1ee155e3f4953d920d6b502db51c
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44848Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Ben Clayton <bclayton@google.com>

Fixes more MSan LLVM JIT false positives.

Change-Id: I0579e2cc71b089424fe168cc60fed63c4b431f91
Bug: b/140204746
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44708
Presubmit-Ready: James Price <jrprice@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: James Price <jrprice@google.com>

When the out of bounds behavior is defined and any of the
image coordinates is out of bounds, this cl manually pushes
the pointer out of bounds in order to trigger the out of
bounds behavior even if the resulting pointer would still
be within memory bounds.

Bug: b/150464740
Change-Id: I685973dfac440a8bca830810cf974819cfbc0f33
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/43950
Presubmit-Ready: Alexis Hétu <sugoi@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

Reactor backend: LLVM

Change-Id: Idacca75cfd2a18886dc9f86f3d9a60d9d40d8bd3
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/42930Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>

`runDailyTest()` calls `test.cleanup()` before returning, removing the entire checkout directory, along with coverage data, and the git repo.

This breaks both `postDailyResults()` and `postCoverageResults()`.

Instead use a callback to handle the daily results. This way we can keep the `defer` to clean up even in case of error.

Change-Id: I9730d7dd8ac9c3a19d82d07a68325afdf38bfd40
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44748Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Ben Clayton <bclayton@google.com>

turbo-cov can only process clang coverage information, so there's no point building it for other toolchains.

turbo-cov depends on the llvm-10 libs and headers, and does not build against llvm-7.

Bug: b/152192800
Change-Id: I522ecb3adfbd448aa47673c452a83083134a36ca
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44728
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Ben Clayton <bclayton@google.com>

This typeinfo was added for UBSan failures reported in crbug.com/737384,
but it didn't address other 'Incorrect-function-pointer-type' failures
for crbug.com/746914. We've suppressed sanitization for these functions
with the NO_SANITIZE_FUNCTION macro, refactored interfaces used across
library boundaries into purely abstract ones for crbug.com/732667, and
use '-mllvm -asan-use-private-alias=1' to address b/128551743.

It's unclear whether this typeinfo still serves ay purpose We shouldn't
have to export typeinfo for objects used only inside the shared library,
to avoid ODR violations.

Remove it entirely for now. If this causes a regression and we still
have to export any typeinfo, we should do so more selectively. For
example to only export typeinfo for objects in the egl namespace:
_ZTS*egl*;
_ZTI*egl*;
Alternatively, or in addition, we can try using
'-mllvm -asan-use-private-alias=1' for more build systems.

Bug: b/155441530
Change-Id: Ia966c40dfe45817f356d11725910afef1bb94d6e
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44688
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>

Bug: b/146166966
Bug: angleproject:4071
Change-Id: Ib2c69de7fb00ae1917b657840f7c456792f804f6
Tests: dEQP-VK.*
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44531Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>

Bug: b/146166966
Bug: angleproject:4071
Change-Id: Ifbfcf2d68c8789b0f91fef48db95bd9dc5a7576a
Tests: dEQP-VK.*
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44530Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>

Bug: b/146166966
Bug: angleproject:4071
Change-Id: If5746fac41ba8890804819efd2f05b359e666b4f
Tests: dEQP-VK.*
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44529Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>

Bug: b/146166966
Bug: angleproject:4071
Change-Id: I154e0fa9395e7bd10d82cc2564fa507af68d7497
Tests: dEQP-VK.*
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44528Reviewed-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>

Bug: b/146166966
Bug: angleproject:4071
Tests: dEQP-VK.*
Change-Id: I07008936fbb09f134283a21a6d3bba881f97fe09
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/40668Tested-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>

Currently all conditional branches in SPIR-V shaders are 'flattened',
resulting in the execution of all instructions in both code paths, even
in the case where none of the SIMD lanes are active. If a logically
never taken code path contains an image sampling instruction which
accesses a sampler or image array out of bounds, this could lead to
reading invalid descriptor data, or a page fault.

This is fixed by checking if any SIMD lanes are active, and if not,
jumping over the actual sampling operations which access the
descriptor data.

Bug: b/153380916
Change-Id: I8e0cf7ef855e1250ce6dce9ebf7a47e29da7814d
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/43549Tested-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>

Bug: b/154013190
Change-Id: I0a51912c3fad45f6ce0d04cbc7d4b56e1276d1dc
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44588
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>

Use the Subzero backend instead of LLVM when running Regres per CL.
Turnaround times should be faster, and since Chromium now uses
SwiftShaderVK/Subzero, we'll know which CL breaks it, if any.

Change-Id: If164d87c4946a1f7899c3407cc31fa2f1eba4931
Bug: b/152216043
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44628Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Antonio Maiorano <amaiorano@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>

Changes:
    3c643dd4c Reduce size of marl::ConditionVariable
    ffa88289a Pool::Loan::get(): Return nullptr if has no item.
    6c9341313 Add a new test for 16-byte stack alignment for fibers.
    924493413 Fix marl::parallelize race.

Commands:
    ./third_party/update-marl.sh --squash

Bug: b/140546382
Change-Id: Ie3d376ae9e80d5a40960aee07b664be2d75c69d5

3c643dd4c Reduce size of marl::ConditionVariable
ffa88289a Pool::Loan::get(): Return nullptr if has no item.
6c9341313 Add a new test for 16-byte stack alignment for fibers.
924493413 Fix marl::parallelize race.

git-subtree-dir: third_party/marl
git-subtree-split: 3c643dd4c88d612a2622366074e029dca6a794d1

OpLine is produced for any line / column change.

Column information may be useful for stack frame information (say two function calls on the same line), diagnosing a crash in a complex expression, or some other tooling. However, it's not so useful for IDE debugger stepping, unless you have a location for the span end (which we don't).

Bug: b/155390706
Bug: b/148401179
Change-Id: Ic416c6e3c47044d707bfa36112e1153588669424
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44549Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Ben Clayton <bclayton@google.com>