Make DXC and DXV use new `DxcDllExtValidationLoader` to load external validator before validation. #7749

bob80905 · 2025-09-09T23:19:54Z

This PR focuses on allowing dxc to use the existing infrastructure to use a DxcDllExtValidationLoader object, and load an external dxil.dll with it, via the environment variable. The validate*.test was added to verify that the dll is indeed being loaded and used for external validation, which causes a failure, since the dll's validator version is older than the required minimum validator version that the metadata indicates.

Fixes #7527

github-actions · 2025-09-13T00:32:40Z

✅ With the latest revision this PR passed the C/C++ code formatter.

include/dxc/Support/dxcapi.extval.h

lib/DxcSupport/dxcapi.extval.cpp

V-FEXrt · 2025-09-18T20:21:47Z

lib/DxcSupport/dxcapi.extval.cpp

+  UINT32 newArgCount = ArgCount + 1;
+  std::vector<LPCWSTR> newArgs;
+  newArgs.reserve(newArgCount);
+
+  // Copy existing args
+  for (unsigned int i = 0; i < ArgCount; ++i) {
+    newArgs.push_back(pArguments[i]);
+  }


nit: I think rewriting this as below is equally performant and certainly cleaner

Suggested change

UINT32 newArgCount = ArgCount + 1;

std::vector<LPCWSTR> newArgs;

newArgs.reserve(newArgCount);

// Copy existing args

for (unsigned int i = 0; i < ArgCount; ++i) {

newArgs.push_back(pArguments[i]);

}

std::vector<LPCWSTR> newArgs = {pArguments, pArguments + ArgCount};

lib/DxcSupport/dxcapi.extval.cpp

V-FEXrt · 2025-09-18T21:31:59Z

lib/DxcSupport/dxcapi.extval.cpp

+  if (pResult == nullptr)
+    return E_POINTER;


nit:

Suggested change

if (pResult == nullptr)

return E_POINTER;

if (!pResult)

return E_POINTER;

lib/DxcSupport/dxcapi.extval.cpp

V-FEXrt · 2025-09-18T21:44:24Z

lib/DxcSupport/dxcapi.extval.cpp

+      hr = evh->QueryInterface(riid, reinterpret_cast<void **>(pResult));
+      return hr;
+
+    } else if (clsid == CLSID_DxcValidator) {


nit: you can delete the else here. Might even be worth moving the entire if to the top of this block since its quite short comparted to the other one

V-FEXrt · 2025-09-18T21:44:45Z

lib/DxcSupport/dxcapi.extval.cpp

                                                       IUnknown **pResult) {
-  if (DxilExtValSupport.IsEnabled() && clsid == CLSID_DxcValidator)
-    return DxilExtValSupport.CreateInstance2(pMalloc, clsid, riid, pResult);
+  if (pResult == nullptr)


nit:

Suggested change

if (pResult == nullptr)

if (!pResult)

lib/DxcSupport/dxcapi.extval.cpp

tools/clang/test/CMakeLists.txt

tools/clang/test/LitDXILValidation/validate_1_6_2112.hlsl

V-FEXrt · 2025-09-18T22:01:15Z

tools/clang/tools/dxclib/dxc.cpp

+            if (DXC_FAILED(ValHR)) {
+              if (SUCCEEDED(pCompileResult->QueryInterface(&pResult)))


nit: it looks like these can be a single if statement

lib/DxcSupport/dxcapi.extval.cpp

tools/clang/tools/dxclib/dxc.cpp

lib/DxcSupport/dxcapi.extval.cpp

tools/clang/tools/dxclib/dxc.cpp

lib/DxcSupport/dxcapi.extval.cpp

tools/clang/tools/dxclib/dxc.cpp

utils/hct/hcttest.cmd

lib/DxcSupport/dxcapi.extval.cpp

tools/clang/tools/dxclib/dxc.cpp

tex3d · 2025-09-22T16:43:12Z

lib/DxcSupport/dxcapi.extval.cpp

+// validation scenario, so there is no point in also running
+// the internal validator. This wrapper wraps both the
+// IDxcCompiler and IDxcCompiler3 interfaces.
+class ExternalValidationHelper : public IDxcCompiler, public IDxcCompiler3 {


For one, you'll need to wrap all the interfaces that the compiler object implements so you don't lose the object wrapping for any of them.

But also, IDxcCompiler and IDxcCompiler3 should be incompatible to derive from and implement in the same class due to the nature of COM not supporting separate overloaded methods of the same name. This requires a separate object to implement the other interfaces.

So to be clear, are you suggesting one parent class, ExternalValidationHelper, that implements 4 interfaces and has 4 wrapper member objects, that each implement one interface: IDxcCompiler, IDxcCompiler2, IDxcCompiler3, and IDxcValidator? Your comment above, "This code should all be inside the compiler object wrapper.", makes me think that this class should also implement the IDxcValidator interface, is that correct?

But also, IDxcCompiler and IDxcCompiler3 should be incompatible to derive from and implement in the same class due to the nature of COM not supporting separate overloaded methods of the same name.

It's lucky that IDxcCompiler and IDxcCompiler3 don't actually have any identical methods in them so that this isn't a problem.

IDxcCompiler::Compile takes 10 args, while IDxcCompiler3::Compile takes 7
Preprocess only exists on IDxcCompiler
IDxcCompiler::Disassemble takes 2 args while IDxcCompiler3::Disassemble take 3.

If you only try and implement one of these when you derive from both interfaces you'll get a warning about hiding the base class version.

Interesting. I thought it was not allowed, hence the hoops we jumped through multiple times for multiple implementations of the compiler object supporting both interfaces to avoid deriving from both on the same implementation class.

In any case the first point stands, that there are more interfaces to support than these two.

You'll want to derive from each of these:

IDxcCompiler2

IDxcCompiler3

IDxcLangExtensions3

IDxcContainerEvent

IDxcVersionInfo3

IDxcVersionInfo2 (or IDxcVersionInfo if SUPPORT_QUERY_GIT_COMMIT_INFO not defined)

And no need to derive from IDxcCompiler when deriving from IDxcCompiler2, since IDxcCompiler2 already derives from IDxcCompiler.

The implementation in this PR will cause failures if any of the tests attempt to use these interfaces. I don't think we need to wrap additional ones for the sake of it.

Like Damyan said, I think I'll worry about deriving from each of those in a future PR.

lib/DxcSupport/dxcapi.extval.cpp

tools/clang/tools/dxclib/dxc.cpp

lib/DxcSupport/dxcapi.extval.cpp

tex3d

There are quite a few issues, and as I tried to write something that could express the exact logic necessary for the arguments, I started rewriting the ExternalValidationHelper implementation to also fix many of the other issues. I put a branch up, so here's the link to the commit:

tex3d@08bacdb

See the commit for the general list of issues this rewrite fixes.

lib/DxcSupport/dxcapi.extval.cpp

include/dxc/Support/Global.h

lib/DxcSupport/dxcapi.extval.cpp

damyanp

I think this still looks good to me. It's very hard for me to review, because the rebase means that I can't easily tell what changed since my last review. Since we squash all our commits into main there's no real benefit to rebasing rather than merging with main.

V-FEXrt · 2025-10-02T22:13:21Z

lib/DxcSupport/dxcapi.extval.cpp

+      if (Result)
+        return Result->QueryInterface(Riid, ValResult);
+      else
+        return E_FAIL;


nit:

Suggested change

if (Result)

return Result->QueryInterface(Riid, ValResult);

else

return E_FAIL;

if (!Result)

return E_FAIL;

return Result->QueryInterface(Riid, ValResult);

tools/clang/test/LitDXILValidation/validate_1_6_2112.hlsl

alsepkow

Submitting a block of comments while I continue to review.

alsepkow · 2025-10-03T00:53:05Z

lib/DxcSupport/dxcapi.extval.cpp

+      if (Result)
+        return Result->QueryInterface(Riid, ValResult);
+      else
+        return E_FAIL;


I suggest returning E_POINTER as I think that's what this HRESULT is intended to reflect?
That is, we expect that the caller gives us a valid IDxcOperationResult*.

alsepkow · 2025-10-03T01:02:58Z

lib/DxcSupport/dxcapi.extval.cpp

+
+    // No validation needed; just set the result and return.
+    if (!NeedsValidation)
+      return UseResult(CompileResult);


The UseResult name seems misleading to me? It really looks like it's just a glorified QueryInterface call?

I think it would be cleaner to

Remove the UseResult lambda

Add a check to return E_INVALID_ARG if CompileResult is an invalid pointer at the start of doValidation.

Update line 59 to 'return CompileResult->QueryInterface(Riid, ValResuilt);

Same update to line 67.

Same update for line 83.

Same update on line 87.

alsepkow · 2025-10-03T01:23:46Z

lib/DxcSupport/dxcapi.extval.cpp

+      if (ValidatorVersionInfo->GetVersion(&ValidatorVersionMajor,
+                                           &ValidatorVersionMinor)) {


Suggested change

if (ValidatorVersionInfo->GetVersion(&ValidatorVersionMajor,

&ValidatorVersionMinor)) {

if (FAILED(ValidatorVersionInfo->GetVersion(&ValidatorVersionMajor,

&ValidatorVersionMinor))) {

lib/DxcSupport/dxcapi.extval.cpp

alsepkow · 2025-10-03T01:28:09Z

lib/DxcSupport/dxcapi.extval.cpp

+#endif
+                           !Opts.DumpDependencies && !Opts.VerifyDiagnostics &&
+                           Opts.Preprocess.empty();
+    bool ProduceFullContainer = ProduceDxModule && !Opts.CodeGenHighLevel;


Suggested change

bool ProduceFullContainer = ProduceDxModule && !Opts.CodeGenHighLevel;

const bool ProduceFullContainer = ProduceDxModule && !Opts.CodeGenHighLevel;

alsepkow · 2025-10-03T17:46:09Z

lib/DxcSupport/dxcapi.extval.cpp

+      return DoBasicQueryInterface<IDxcCompiler, IDxcCompiler2, IDxcCompiler3>(
+          NewWrapper.p, Iid, ResultObject);
+    } catch (...) {
+      return E_FAIL;


I think the exception expected here would be due to an allocation failure.
So would ERROR_OUTOFMEMORY be a more appropriate HRESULT?

alsepkow · 2025-10-03T17:47:54Z

lib/DxcSupport/dxcapi.extval.cpp

+      if (ValidatorVersionInfo->GetVersion(&ValidatorVersionMajor,
+                                           &ValidatorVersionMinor)) {
+        DXASSERT(false, "Failed to get validator version");
+        return E_FAIL;


nit: I like to try and avoid E_FAIL because its pretty generic.
There is an 'ERROR_VERSION_PARSE_ERROR' you could use here.

Gonna stick to E_FAIL since there is no definition for that Error code in non-windows.
Same applies to ERROR_OUTOFMEMORY

lib/DxcSupport/dxcapi.extval.cpp

alsepkow · 2025-10-03T18:10:27Z

lib/DxcSupport/dxcapi.extval.cpp

+// The ExtValidationArgHelper class helps manage arguments for external
+// validation, as well as perform the validation step if needed.
+class ExtValidationArgHelper {
+  std::vector<std::wstring> ArgStorage;


I think we generally do all publics first and then all privates second?
Should we move the member variables to the private section?

alsepkow · 2025-10-03T18:10:59Z

lib/DxcSupport/dxcapi.extval.cpp

+// IDxcValidator interface to validate a successful compilation result, when
+// validation would normally be performed.
+class ExternalValidationCompiler : public IDxcCompiler2, public IDxcCompiler3 {
+private:


nit: public first for consistency with the rest of this file

Actually the reason this broke that consistency is because there's a special rule in linux / macos builds on initialization order, and the Compiler object can't be initialized after the m_pAlloc field, which was originally taken care of in the previous private block. So I will leave this as is.

there's a special rule in linux / macos builds on initialization order

There's not a special rule, it's just that MSVC doesn't warn if you mismatch the order that things appear in the constructor's initialization list with the order that they are actually initialized (ie the order they appear in the class itself).

If you wanted to put the private block at the end then you'd just need to update the constructor to list m_pMalloc first (since it'd be listed first in the class as the field is added by the DXC_MICROCOM_TM_REF_FIELDS macro).

Or you could have your private block at the end look like this and not need to modify the constructor:

private: CComPtr<IDxcValidator> Validator; IID CompilerIID; CComPtr<IUnknown> Compiler; DXC_MICROCOM_TM_REF_FIELDS()

lib/DxcSupport/dxcapi.extval.cpp

…go in

alsepkow · 2025-10-06T22:14:05Z

lib/DxcSupport/dxcapi.extval.cpp

+    CComPtr<IDxcBlob> CompiledBlob;
+    IFR(CompileResult->GetResult(&CompiledBlob));
+
+    // If no compiled blob; just return the compile result.


nit: comment doesn't seem accurate. We're returning the HRESULT of QI. That doesn't seem like a compile result?

This language is a bit overloaded, I meant return through an out-parameter, by placing the result into ValResult.
I can rewrite this.

The main thing that threw me off is that you wouldn't generally expect a QI call to do anything other than get you a pointer to the requested interface. The fact that the private implementation of QI is doing more than that is a little weird.

alsepkow · 2025-10-06T22:24:02Z

lib/DxcSupport/dxcapi.extval.cpp

+    // Return the validation result if it failed.
+    HRESULT HR;
+    IFR(TempValidationResult->GetStatus(&HR));
+    if (FAILED(HR)) {


I see uses of DXC_FAILED and FAILED. Hadn't seen DXC_FAILED before but it looks like they do the same thing.
We should just use one.

lib/DxcSupport/dxcapi.extval.cpp

tools/clang/test/LitDXILValidation/validate_1_6_2112.hlsl

tools/clang/test/lit.cfg

tools/clang/tools/dxclib/dxc.cpp

tex3d · 2025-10-10T22:55:38Z

tools/clang/tools/dxclib/dxc.cpp

+        // function is deferred to whatever object was chosen to be pCompiler,
+        // which must implement the IDxcCompiler interface. External validation
+        // will only take place if the DXC_DXIL_DLL_PATH env var is set
+        // correctly.


Why is this comment on this one compile call? Why not put a comment where you initialize the DxcDllExtValidationLoader in dxc::main instead?

Because the Compile command also is responsible for validation. I think this call site is appropriate because at this point, different outcomes may happen. IMO it's less clear on DxcDllExtValidationLoader initialization, since there's no compilation or validation happening then and there.

Again, another nit I'll let go.

I guess my point was:

This isn't the only call that could lead to external validation in DxcContext

This isn't the code scope where that knowledge is needed or relevant - in fact, as I pointed out elsewhere, DxcContext doesn't need to be hard-coded to use DxcDllExtValidationLoader in the first place.

I suggested main because that's the top-level place where options are parsed and this is a bit like an undocumented option for the tool which dxcSupport.initialize() is going to read from the environment at that point.

tools/clang/tools/dxclib/dxc.cpp

tex3d · 2025-10-10T23:13:42Z

tools/clang/tools/dxclib/dxc.cpp

 private:
  DxcOpts &m_Opts;
-  SpecificDllLoader &m_dxcSupport;
+  DxcDllExtValidationLoader &m_dxcSupport;


Shouldn't we use DllLoader instead? Isn't that the point of DllLoader as a base class?

Suggested change

DxcDllExtValidationLoader &m_dxcSupport;

DllLoader &m_dxcSupport;

The point of DllLoader is to provide abstraction for an object that is capable of creating instances of objects from a dll.
However, in the specific cases of dxc and dxv, we know ahead of time that in that context, we don't need any abstraction. dxc and dxv should both be using the more specific object type, because we know that they may both load from an external dll if the environment variable exists.
The DllLoader class was created for cases where there's delegation, and where it isn't clear whether a DxcDllExtValidationLoader instance was passed or whether something else might be passed. But we can constrain dxc and dxv to be DxcDllExtValidationLoader's only.

I get that, and it's just a nit, so I'm fine with this.

Just to be clear why I thought we should use DllLoader, and consider it a nit:

This DxcContext is in a library and can be linked into and used from different top-level tool driver executables. If one of those doesn't need to use DxcDllExtValidationLoader and implements its own main to initialize the context, it doesn't seem right (architecturally) to force it to use DxcDllExtValidationLoader since DxcContext only needs to know about the DllLoader interface.

I'm fine with it as-is particularly because we don't plan to expand the set of tools using DxcContext. We are more likely to deprecate/remove dxl instead, which, IIRC, is the only other tools that uses this.

tools/clang/tools/dxv/dxv.cpp

lib/DxcSupport/dxcapi.extval.cpp

include/dxc/Support/dxcapi.extval.h

tex3d

I noticed we regressed the -external and -external-fn dxc options, and need a change to DxcDllExtValidationLoader to support this.

include/dxc/Support/dxcapi.extval.h

tools/clang/tools/dxclib/dxc.cpp

tools/clang/tools/dxv/dxv.cpp

tools/clang/unittests/HLSL/ValidationTest.cpp

tools/clang/tools/dxclib/dxc.cpp

tools/clang/unittests/HLSL/ValidationTest.cpp

tex3d

Approved, but would like to see the fragile __FILE__ reference from the test replaced with a reference to a file in the test data location which is required to be set for the test environment.

tex3d · 2025-10-25T02:25:33Z

lib/DxcSupport/dxcapi.extval.cpp

+  template <typename T> CComPtr<T> cast() const {
+    CComPtr<T> Result;
+    if (Compiler)
+      Compiler->QueryInterface(__uuidof(T), reinterpret_cast<void **>(&Result));


Ok, but why doesn't Result = Compiler; work? CComPtr will correctly call the QueryInterface for you upon assignment.

Even if you want to manually write the QueryInterface, you can use Compiler->QueryInterface(IID_PPV_ARGS(&Result));, or Compiler.QueryInterface(&Result); (CComPtr's templated QueryInterface).

tex3d · 2025-10-25T02:44:46Z

tools/clang/unittests/HLSL/ValidationTest.cpp

+  VERIFY_IS_TRUE(ExtSupportBogus.dxilDllFailedToLoad());
+
+  // 3. Test with a valid path to this file in the environment variable
+  std::filesystem::path p = std::filesystem::absolute(__FILE__);


This presumes the test has access to this source file via the same path. That seems quite fragile, since that's not a requirement of the tests.

We do have a reliable way to access a file that must exist in the test environment: hlsl_test::GetPathToHlslDataFile(fileName) where fileName is the path to a test file relative to the tools/clang/test/HLSL path, for instance, you could use another file referenced in ValidationTest.cpp: L"..\\DXILValidation\\hs_signatures.hlsl" (through the CompileFile() function).

github-project-automation bot added this to HLSL Roadmap Sep 9, 2025

github-project-automation bot moved this to New in HLSL Roadmap Sep 9, 2025

bob80905 changed the title ~~Make DXC use new DxcDllExtValidationLoader to load external validator before validation.~~ Make DXC and DXV use new DxcDllExtValidationLoader to load external validator before validation. Sep 16, 2025

bob80905 force-pushed the add_extvalsupport_class_to_val_infra branch from 6c69325 to 78cace7 Compare September 16, 2025 23:24

bob80905 marked this pull request as ready for review September 17, 2025 18:21

damyanp reviewed Sep 17, 2025

View reviewed changes

damyanp reviewed Sep 18, 2025

View reviewed changes

lib/DxcSupport/dxcapi.extval.cpp Outdated Show resolved Hide resolved

damyanp reviewed Sep 18, 2025

View reviewed changes

lib/DxcSupport/dxcapi.extval.cpp Outdated Show resolved Hide resolved

damyanp reviewed Sep 18, 2025

View reviewed changes

lib/DxcSupport/dxcapi.extval.cpp Outdated Show resolved Hide resolved

damyanp reviewed Sep 18, 2025

View reviewed changes

lib/DxcSupport/dxcapi.extval.cpp Outdated Show resolved Hide resolved

damyanp reviewed Sep 18, 2025

View reviewed changes

lib/DxcSupport/dxcapi.extval.cpp Outdated Show resolved Hide resolved

V-FEXrt reviewed Sep 18, 2025

View reviewed changes

damyanp requested changes Sep 19, 2025

View reviewed changes

github-project-automation bot moved this from New to In progress in HLSL Roadmap Sep 19, 2025

damyanp requested changes Sep 20, 2025

View reviewed changes

damyanp reviewed Sep 20, 2025

View reviewed changes

lib/DxcSupport/dxcapi.extval.cpp Outdated Show resolved Hide resolved

damyanp reviewed Sep 20, 2025

View reviewed changes

tools/clang/tools/dxclib/dxc.cpp Outdated Show resolved Hide resolved

damyanp reviewed Sep 20, 2025

View reviewed changes

tools/clang/tools/dxclib/dxc.cpp Outdated Show resolved Hide resolved

damyanp reviewed Sep 20, 2025

View reviewed changes

tools/clang/tools/dxclib/dxc.cpp Outdated Show resolved Hide resolved

damyanp reviewed Sep 20, 2025

View reviewed changes

tools/clang/tools/dxclib/dxc.cpp Outdated Show resolved Hide resolved

damyanp reviewed Sep 20, 2025

View reviewed changes

tools/clang/tools/dxclib/dxc.cpp Outdated Show resolved Hide resolved

tex3d reviewed Sep 22, 2025

View reviewed changes

damyanp requested changes Sep 23, 2025

View reviewed changes

tex3d requested changes Sep 24, 2025

View reviewed changes

bob80905 force-pushed the add_extvalsupport_class_to_val_infra branch from c6ac790 to eb69e26 Compare September 24, 2025 05:36

tex3d reviewed Sep 24, 2025

View reviewed changes

lib/DxcSupport/dxcapi.extval.cpp Outdated Show resolved Hide resolved

damyanp reviewed Sep 24, 2025

View reviewed changes

damyanp reviewed Sep 25, 2025

View reviewed changes

lib/DxcSupport/dxcapi.extval.cpp Outdated Show resolved Hide resolved

damyanp requested changes Sep 26, 2025

View reviewed changes

damyanp approved these changes Oct 2, 2025

View reviewed changes

V-FEXrt approved these changes Oct 2, 2025

View reviewed changes

alsepkow reviewed Oct 3, 2025

View reviewed changes

lib/DxcSupport/dxcapi.extval.cpp Show resolved Hide resolved

bob80905 added 6 commits October 3, 2025 13:03

address Alex

cedc965

revert some non-windows incompatible stuff

b5babf1

Merge branch 'main' into add_extvalsupport_class_to_val_infra

c708f6a

add requires to new test that was added while waiting for this PR to …

17b35b5

…go in

try rearranging public private order

0dabdd1

clang format

f12af78

alsepkow reviewed Oct 6, 2025

View reviewed changes

lib/DxcSupport/dxcapi.extval.cpp Outdated Show resolved Hide resolved

address Alex

03c1d54

tex3d reviewed Oct 10, 2025

View reviewed changes

bob80905 added 2 commits October 13, 2025 17:01

address Tex

3b595e0

undo cast function addition

7daf141

tex3d reviewed Oct 15, 2025

View reviewed changes

include/dxc/Support/dxcapi.extval.h Outdated Show resolved Hide resolved

bob80905 added 2 commits October 14, 2025 19:43

address Tex

c8b6248

don't merge entire env when running dxil --version

8dc8a10

tex3d reviewed Oct 15, 2025

View reviewed changes

bob80905 added 2 commits October 15, 2025 14:28

address Tex

4a8b666

remove unused member var

5a3821f

bob80905 force-pushed the add_extvalsupport_class_to_val_infra branch from f69c61f to 5a3821f Compare October 15, 2025 21:29

actually use external opts in dxc

bea0c47

tex3d approved these changes Oct 25, 2025

View reviewed changes

bob80905 merged commit 715dacc into microsoft:main Oct 27, 2025
12 checks passed

github-project-automation bot moved this from In progress to Done in HLSL Roadmap Oct 27, 2025

This was referenced Oct 27, 2025

[Validation] Make Validation tests more robust #7848

Open

Replace DxilDllSupport in dxc.cpp and in tests #7527

Closed

		if (DXC_FAILED(ValHR)) {
		if (SUCCEEDED(pCompileResult->QueryInterface(&pResult)))

		if (ValidatorVersionInfo->GetVersion(&ValidatorVersionMajor,
		&ValidatorVersionMinor)) {

	bool ProduceFullContainer = ProduceDxModule && !Opts.CodeGenHighLevel;
	const bool ProduceFullContainer = ProduceDxModule && !Opts.CodeGenHighLevel;

	DxcDllExtValidationLoader &m_dxcSupport;
	DllLoader &m_dxcSupport;

Uh oh!

Make DXC and DXV use new DxcDllExtValidationLoader to load external validator before validation. #7749

Make DXC and DXV use new DxcDllExtValidationLoader to load external validator before validation. #7749

Conversation

bob80905 commented Sep 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions bot commented Sep 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Make DXC and DXV use new `DxcDllExtValidationLoader` to load external validator before validation. #7749

Make DXC and DXV use new `DxcDllExtValidationLoader` to load external validator before validation. #7749

bob80905 commented Sep 9, 2025 •

edited

Loading

github-actions bot commented Sep 13, 2025 •

edited

Loading

tex3d left a comment •

edited

Loading