Complex SFINAE expressions appear to be broken on the latest release of MSVC 2017.

MSVC++ 14.15 (Visual Studio 2017 version 15.8):
The parent change compiles fine.

MSVC++ 14.16 (Visual Studio 2017 version 15.9):
 `error C2039: 'type': is not a member of 'std'` for some CToReactorPtr specializations that use `std::enable_if`.

Replacing these `typename std::enable_if<T>::type` with `enable_if_t<T>` works around the issue (while also making the template expressions easier to read).

I was unable to find an existing MSVC bug report for this problem, and so I will create one.

Bug: swiftshader:141
Change-Id: I7e953dbc719d7cb656aa7f16656c3f86ffad5522
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/38688
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Tested-by: Ben Clayton <bclayton@google.com>

Change-Id: I85bfa4a040ec6b45ca0637ab4eb5b7b6c8c26275
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/38668
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Alexis Hétu <sugoi@google.com>

* changes:
  Update SPIRV-Tools to d552f632
  Squashed 'third_party/SPIRV-Tools/' changes from 65e362b7a..c3f22f7cb
  Update SPIRV-Headers to 0f9a2dc9
  Squashed 'third_party/SPIRV-Headers/' changes from e4322e3be..af64a9e82

This is the correct behavior according to the spec. This CL modifies
MetalSurface, XcbSurfaceKHR and XlibSurfaceKHR.

Bug: swiftshader: 140
Change-Id: I3f1829506a9d95c11c07f6a3a9ea1e7557e78725
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/38648
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Jonah Ryan-Davis <jonahr@google.com>

ANGLE already has this logic, but with Dawn looking to use Swiftshader
as well, there would have been a conflict when both ANGLE and Dawn tried
to generate the same ICD JSON file.

Having this logic in Swiftshader's GN files means that any number of
component of projects using GN (aka Chromium) can use swiftshader
without issues.

Bug: dawn:283
Change-Id: I8531c98c370db01563dc102f259164e0393242ca
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/38491
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Corentin Wallez <cwallez@google.com>

This is part of VK_EXT_line_rasterization, which we claim to support.
The stippled line feature itself is not supported, so apps must not call this function.

Bug: b/144183516
Test: dEQP-VK.api.version_check.entry_points
Change-Id: I935be72717184b2e8b1a51cb8e411d66a9fcfa52
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/38628Tested-by: Chris Forbes <chrisforbes@google.com>
Presubmit-Ready: Chris Forbes <chrisforbes@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>

- Added a loop for handling pNext pointers everywhere in
  libVulkan.cpp where the wasn't already one, in order to
  always output the unsupported structure type(s) received
  by the library
- Changed UNIMPLEMENTED to WARN for unhandled pNext pointers

Fixes the test:
dEQP-VK.api.smoke.triangle_ext_structs

Bug: b/144999059 b/119321052
Change-Id: Id83b5e74c8925dbd38651747b0cea46fac4a69a4
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/38548
Presubmit-Ready: Alexis Hétu <sugoi@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Sean Risser <srisser@google.com>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
Tested-by: Alexis Hétu <sugoi@google.com>

pResults was not getting filled in correctly.

As per the spec:

pResults is an array of VkResult typed elements with
swapchainCount entries. Applications that do not
need per-swapchain results can use NULL for pResults.
If non-NULL, each entry in pResults will be set to the VkResult
for presenting the swapchain corresponding to the same index
in pSwapchains.

Bug: b/144766511

Change-Id: I42fcb6d96218d4dbfa60e857226c0aed72e7d8ca
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/38369Reviewed-by: Chris Forbes <chrisforbes@google.com>
Presubmit-Ready: Chris Forbes <chrisforbes@google.com>
Tested-by: Chris Forbes <chrisforbes@google.com>
Tested-by: Andrew Woloszyn <awoloszyn@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

Change-Id: I1522a335fc3fe7f46c1533baf244ee3ad6ae2b9a
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/38492Reviewed-by: Chris Forbes <chrisforbes@google.com>
Tested-by: Chris Forbes <chrisforbes@google.com>

It was originally committed into LLVM: https://reviews.llvm.org/D69434

This CL aims to continue the work on Swiftshader for Windows on ARM64.

Bug: chromium:893460
Change-Id: Ib0de220c1d332f2a16d2275a5f3aef4d1a53ee33
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/38453Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Alexis Hétu <sugoi@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

Bug: b/139528538
Change-Id: I11d25399f582393ede13cbd8349c79cb3fdf4053
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/38608Reviewed-by: Ben Clayton <bclayton@google.com>
Tested-by: Ben Clayton <bclayton@google.com>

Build error: `You got a tab character in here. Tabs are evil. Convert to spaces.`

Bug: b/139528538
Change-Id: Ic06cc9e0aafa0a4d3517fc13428724d6fe40e0b5
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/38589Reviewed-by: Ben Clayton <bclayton@google.com>
Tested-by: Ben Clayton <bclayton@google.com>

Build error: `You got a tab character in here. Tabs are evil. Convert to spaces.`

Bug: b/139528538
Change-Id: I937f96d3aeae48103510c0faab6bec9499a290dc
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/38588
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Tested-by: Alexis Hétu <sugoi@google.com>

The purpose of this function is to express *additional* restrictions
beyond those imposed by the device limits. We have no such restrictions
to impose, so should *always* claim support, not *never*.

Test: dEQP-VK.api.maintenance3_check.descriptor_set
Bug: b/145007346
Change-Id: Ibacc9336c0900fe0d7af239c58b930bcd13bcd3b
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/38549Tested-by: Chris Forbes <chrisforbes@google.com>
Presubmit-Ready: Chris Forbes <chrisforbes@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

The Vulkan spec states that if an implementation does not support an
extension, then it must ignore all fields other than pNext and pType and
continue on without processing any further information contained in the
extension's structure. We've been using asserts to log these situations
so we can tell which extension structs people are trying to use.

This CL changes our behavior so we silently log these unsupported extensions,
and warn a user once if they're debugging.

Retrying this after updating build files to include added VkStringify.*pp files.

Bug: b/139528538
Change-Id: Icd4ea3f53bf2eec5c2c81079b2ebbaa1b9a855db
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/38568
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Sean Risser <srisser@google.com>
Presubmit-Ready: Sean Risser <srisser@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>

Added new functions to explicitly mark some
new extension features as not supported.

Fixes the following test:
dEQP-VK.api.info.get_physical_device_properties2.features

Bug: b/144945388
Change-Id: Id4c5da51d42537f5e1d92352eece67d4e7f5b930
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/38531
Presubmit-Ready: Alexis Hétu <sugoi@google.com>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Alexis Hétu <sugoi@google.com>

Change-Id: I6f56a6e953415cc40eb692a0a019ab2330d63078
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/38409
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Alexis Hétu <sugoi@google.com>

In libVulkan.cpp, many structures are received as pointers,
which are dereferenced, only to be references on the next line.
We can just take the pointers as is.

Bug: b/144943261
Change-Id: I60585ab5e953dc9baf1f6951a3762c890ab95641
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/38530
Presubmit-Ready: Alexis Hétu <sugoi@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>

Reason for revert: Didn't update a build file, which broke the build and commit queue.

Bug: b/139528538
Change-Id: I45cd93a01d984175c2dba5351a4cdd1154e50f31
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/38528
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Alexis Hétu <sugoi@google.com>

Update from:
https://github.com/KhronosGroup/Vulkan-Headers
To revision:
24347673152e093a48efbf65dfd3b06026b6ed33

Did not modify vulkan.h, so vulkan_fuchsia_extras.h
was not removed from it.

Bug: b/143197472
Change-Id: Ia96ca3b15fb5d04b4bb5155ae33f39d75043e0fe
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/38529
Presubmit-Ready: Alexis Hétu <sugoi@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Alexis Hétu <sugoi@google.com>

The Vulkan spec states that if an implementation does not support an
extension, then it must ignore all fields other than pNext and pType and
continue on without processing any further information contained in the
extension's structure. We've been using asserts to log these situations
so we can tell which extension structs people are trying to use.

This CL changes our behavior so we silently log these unsupported extensions,
and warn a user once if they're debugging.

Bug: b/139528538
Change-Id: I8d31f147e22f670c9c10c64e239085700eae73a3
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/36089
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Sean Risser <srisser@google.com>
Presubmit-Ready: Sean Risser <srisser@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>

If enabled, and ALLOW_DUMP = 1, emit() outputs text asm to stdout along
with liveness info. Useful for debugging register allocation.

Bug: b/144688789
Change-Id: I36137c439f6f2ca32af6f208146501b095ccfac4
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/38478Tested-by: Antonio Maiorano <amaiorano@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

When enabled, coupled with ALLOW_DUMP = 1, will enable verbose and
unbuffered logging. Helpful for debugging Subzero bugs.

Bug: b/144688789
Change-Id: Ia5ae4456e4ec43dcf616f7f14cf88cd0911fe17b
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/38477
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Antonio Maiorano <amaiorano@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>

Opt_0 and Opt_1 are not implemented, so they weren't useful. With this
change, we can at least run Subzero's "0-1" optimization level to
compare against "02".

Bug: b/144688789
Change-Id: Ic6a5af572ed9a543f76bbc7074f87771f8da1980
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/38476Tested-by: Antonio Maiorano <amaiorano@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

Fix asserts that would trip during emit, which we only use to emit textual
representation of generated asm to stdout. Useful for debugging.

Bug: b/144688789
Change-Id: I42d60da042fa04bf6afc9035b2892249e5e46c59
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/38475Tested-by: Antonio Maiorano <amaiorano@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

Subzero would generate invalid code during register allocation in
certain instances related to incorrect liveness analysis. With the help
of Jim Stichnoth, we identified that "computeInOutEdges" was never being
called, so, as Jim put it: "Because control-flow information is not
available in InEdges and OutEdges, liveness analysis essentially does
block-local liveness instead of global liveness." As a result, values
would get incorrectly assigned to registers.

The ExtractFromRValue unit test demonstrates this bug. Without the call
to computeInOutEdges, the Extract(v, 1) would return the wrong result.

Bug: b/144688789
Change-Id: Iad7f7bf9dec74f628120003d316480d83b9fa4f1
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/38474Tested-by: Antonio Maiorano <amaiorano@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

When lowering Call to external functions on x64, Subzero was not
correctly allocating 32 bytes for the shadow store. This became
apparent when trying to pass pointers to local variables to Call, in
which case, the address of the stack variable would be passed via
register. However, in the called external function, on x64, it's allowed
to use the first 32 bytes on the stack - the shadow store - as scratch
space. In my use-case, the called function ended up overwriting the
local stack variable that the callee passed a pointer to.

Another use-case where this error was apparent was in passing more than
four arguments to a Call, in which case, the callee expected the spilled
args to be present after the shadow store.

This fixes these problems by correctly allocating the 32 byte shadow
store when lowering Call on x64.

Note that this is similar to e81e8b3c
where I fixed the prolog to the generated entry point to take the shadow
store into account.

Bug: b/144688789
Change-Id: I9d7960bb9c520f5cc3c0ad885305ca5a3c06b5dc
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/38473Reviewed-by: Ben Clayton <bclayton@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Antonio Maiorano <amaiorano@google.com>

Includes a test fix for dEQP-VK.spirv_assembly.instruction.compute.hlsl_cases.cbuffer_packing

Bug: b/144183516
Bug: b/144306942
Change-Id: I3056837e2069841a465b8e4af12713b0a1995272
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/38508Tested-by: Chris Forbes <chrisforbes@google.com>
Presubmit-Ready: Chris Forbes <chrisforbes@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>

This CL fixes a minor compiler warning related to the use of 0xFFFFFFFF
to divide a float value. It turns out that this integer value cannot be
converted to a float without losing one bit of accuracy.

Bug: None
Change-Id: I34fefd91afb526edbfafd3d8a2378fa6b7bf325d
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/38448Reviewed-by: Ben Clayton <bclayton@google.com>
Tested-by: David Turner <digit@google.com>
Kokoro-Presubmit: David Turner <digit@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

Because stencil buffers can now be texture sampled, used in
cubemaps, blitted, etc, the quadLayout used for stencil
buffers requires constant texture coordinate conversion in
order to perform various tasks involving stencil buffers.
For now, the simplest solution is to remove the quadLayout
used by the stencil buffer.

Fixes all issues in the following subcategory using SwANGLE:
dEQP-GLES31.functional.stencil_texturing.format.*_stencil8_cube

Bug: b/144353295
Change-Id: I2a8cbdda0036146f9dca222ec330841788a3ee8b
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/38188
Presubmit-Ready: Alexis Hétu <sugoi@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>

This was committed to LLVM at https://reviews.llvm.org/D57291 .
Created by Martin Storsjo.

Bug: chromium:893460
Change-Id: Ifbf5a632f8d517b0910aa3274d0cae585729d34f
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/38452
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Alexis Hétu <sugoi@google.com>

The name is wrong, so this only really worked if xcb was
actually linked normally, if the user opened it in another
way (dlopen) this would get missed.

Bug: b/139491466

Change-Id: Ib9a84bd7424a1c4bf027ecb9f1a5b9af6d7210b3
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/38368Reviewed-by: Ben Clayton <bclayton@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Andrew Woloszyn <awoloszyn@google.com>

No depth buffer format uses quad layout currently and stencil
quad layout will soon be removed, so the depth buffer quad
layout logic can be removed.

Bug: b/144353295
Change-Id: I78ab5dbf292af2752ed1c6aea069a8079c21663f
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/38472
Presubmit-Ready: Alexis Hétu <sugoi@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>

3D subregions were not properly supported in Image::copyTo()

Bug: b/144353295
Change-Id: I445881b37be310401b38cffcb6003a1e4461bed8
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/38471
Presubmit-Ready: Alexis Hétu <sugoi@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>

Blitting should be done either using the depth
aspect or the stencil aspect, not both at once.

Bug: b/144353295
Change-Id: I5b7a81d3c2b915f6ebb5854edc814f335eb2cac5
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/38470
Presubmit-Ready: Alexis Hétu <sugoi@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>

This is considered non-core functionality.

Fixes: b/144686205
Change-Id: I41b811d70db9c07d26a3e6cb2f8c36a2a9e34296
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/38450Tested-by: Ben Clayton <bclayton@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

Both LLVM and Subzero now support it, so there's no need to expose this as a capability. Yay!

Bug: b/142132927
Change-Id: I5cf5eece809f7305d38e8d0f995be45d44a8b1cd
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/38449Tested-by: Ben Clayton <bclayton@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

rr::ConstantData() returns a Pointer<Byte> to an immutable copy of the provided data.

Added two new variants of rr::Call() for calling member function pointers.

Added tests.

Bug: b/143479561
Change-Id: I5846fb313fbd81821bf4e9bb655414a5e0eaf133
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/38408Tested-by: Ben Clayton <bclayton@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>

This should have been done as part of 51f08312, but it got missed.

Bug: b/143479561
Change-Id: I16d802e753989576ade007c031f11bc5ab351d32
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/38390Tested-by: Ben Clayton <bclayton@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>

The documentation states:

  "For T types that have a CToReactorT<> specialization,
  CToReactorPtrT<T>::type resolves to Pointer< CToReactorT<T> >,
  otherwise CToReactorPtrT<T>::type resolves to Pointer<Byte>."

However, the CToReactorPtrT<T>::cast() function did not behave
correctly for some Pointer<Byte> cases. Now fixed.

Bug: b/143479561
Change-Id: I64387653e9edf21eb7fa91e3bcb7b76171c7bca4
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/38389Tested-by: Ben Clayton <bclayton@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>