Match against LLVMValString
in overrides (#2148)
#2149
Merged
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.
LLVM will sometimes optimize
uint8_t
arrays into top-level string constants. For example, Clang will optimizeuint8_t xs[4] = {0,1,2,3};
into the LLVM string constant"\00\01\02\03"
. This is still a value of type[4 x i8]
, but it uses string syntax for convenience.crucible-llvm
mirrors this choice by having a dedicatedLLVMValString
value alongside the more generalLLVMValArray
, with the former using aByteString
as its payload for convenience.While SAW's LLVM override matching logic had cases for
LLVMValArray
, it did not have cases forLLVMValString
, which meant that any override that needs to match on an LLVM string constant argument would fail. This is easily fixed by adding the missing cases.Fixes #2148.