[NFC][SemaHLSL] Remove check dependent on non-deterministic root element association #148649
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- when there are duplicate `RangeInfo`s created and we will attempt to `llvm::sort` or `llvm::stable_sort` them, it does not appear deterministic in which order they will be sorted (because they are equivalent) - when `DLLVM_ENABLE_EXSTENSIVE_CHECKS` is enabled, it appears to deal with this tie-breaker sorting the list differently than when it is not enabled, this causes one of the test cases to fail because the diagnostic is produced, not in a different order, but with a different identical root element - functionally this makes no difference to the diagnostic being produced, so we will remove the check that it is that specific element in the test This should resolve the build issues reported:
llvmbot
added
clang
|
@llvm/pr-subscribers-hlsl @llvm/pr-subscribers-clang Author: Finn Plummer (inbelic) Changes
This should resolve the build issues reported here and here Full diff: https://github.com/llvm/llvm-project/pull/148649.diff 1 Files Affected:
diff --git a/clang/test/SemaHLSL/RootSignature-resource-ranges-err.hlsl b/clang/test/SemaHLSL/RootSignature-resource-ranges-err.hlsl
index 47c06d3fd6381..bac41d13dd6be 100644
--- a/clang/test/SemaHLSL/RootSignature-resource-ranges-err.hlsl
+++ b/clang/test/SemaHLSL/RootSignature-resource-ranges-err.hlsl
@@ -112,21 +112,12 @@ void bad_root_signature_14() {}
// CHECK: [[@LINE-2]]:13: note: expanded from macro 'DuplicatesRootSignature'
// CHECK-NEXT: [[@LINE-3]] | "CBV(b0), CBV(b0), CBV(b0), DescriptorTable(CBV(b0, numDescriptors = 2))"
// CHECK-NEXT: | ^
-// CHECK: [[@LINE-5]]:4: note: expanded from macro 'DuplicatesRootSignature'
+// CHECK: [[@LINE-5]]:22: note: expanded from macro 'DuplicatesRootSignature'
// CHECK-NEXT: [[@LINE-6]] | "CBV(b0), CBV(b0), CBV(b0), DescriptorTable(CBV(b0, numDescriptors = 2))"
-// CHECK-NEXT: | ^
-// CHECK: [[@LINE-8]]:22: note: expanded from macro 'DuplicatesRootSignature'
-// CHECK-NEXT: [[@LINE-9]] | "CBV(b0), CBV(b0), CBV(b0), DescriptorTable(CBV(b0, numDescriptors = 2))"
// CHECK-NEXT: | ^
-// CHECK: [[@LINE-11]]:4: note: expanded from macro 'DuplicatesRootSignature'
-// CHECK-NEXT: [[@LINE-12]] | "CBV(b0), CBV(b0), CBV(b0), DescriptorTable(CBV(b0, numDescriptors = 2))"
-// CHECK-NEXT: | ^
-// CHECK: [[@LINE-14]]:47: note: expanded from macro 'DuplicatesRootSignature'
-// CHECK-NEXT: [[@LINE-15]] | "CBV(b0), CBV(b0), CBV(b0), DescriptorTable(CBV(b0, numDescriptors = 2))"
-// CHECK-NEXT: | ^
-// CHECK: [[@LINE-17]]:4: note: expanded from macro 'DuplicatesRootSignature'
-// CHECK-NEXT: [[@LINE-18]] | "CBV(b0), CBV(b0), CBV(b0), DescriptorTable(CBV(b0, numDescriptors = 2))"
-// CHECK-NEXT: | ^
+// CHECK: [[@LINE-8]]:47: note: expanded from macro 'DuplicatesRootSignature'
+// CHECK-NEXT: [[@LINE-9]] | "CBV(b0), CBV(b0), CBV(b0), DescriptorTable(CBV(b0, numDescriptors = 2))"
+// CHECK-NEXT: | ^
// expected-error@+6 {{resource ranges b[0;0] and b[0;0] overlap within space = 0 and visibility = All}}
// expected-note@+5 {{overlapping resource range here}}
|
|
@guy-david @bevin-hansson This resolved the build issue for me locally when using |
inbelic
changed the title
|
Although, thinking a bit more, we can actually remove this test entirely. The FileCheck portion was just a nicety to check that the SourceLocation was pointing correctly for this case. However, this is redundant with the other checks that exist to do so. |
after further investigation, we can remove this testcase as it does not cover any unique case that is not previously covered as the ordering is not guarenteed to be consistent - for a test that covers the exact column placement of a resource range error, please see above and given that we are checking the quantity of ranges here, then we will still correctly check that we are generating an error for each duplicate range
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/123/builds/23314 Here is the relevant piece of the build log for the reference |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
when there are duplicate (equivalent)
RangeInfos created we will attempt tollvm::sortorllvm::stable_sortthem, it does not appear deterministic in which order they will be sorted (because they are equivalent)when
DLLVM_ENABLE_EXSTENSIVE_CHECKSis enabled, it appears to deal with this tie-breaker sorting the list differently than when it is not enabled, this causes one of the test cases to fail because the diagnostic is produced, not in a different order, but with a different root element associated with an identicalRangeInfofunctionally this makes no difference to the diagnostic being produced and the removed test-case was added just as a nicety to demonstrate how the diagnostics might look
the test above the removed will correctly demonstrate that the
SourceLocationwill be set to the correct column, and, the-verifyportion of this testcase will ensure that we still generate a diagnostic for each duplicatetherefore, it is safe to remove this portion of the test-case that can have a non-deterministic association of root element
This resolves the build issues reported here and here