Kevin Newton 6068da8937 Finer-grained constant cache invalidation (take 2) ... This commit reintroduces finer-grained constant cache invalidation. After 8008fb7 got merged, it was causing issues on token-threaded builds (such as on Windows). The issue was that when you're iterating through instruction sequences and using the translator functions to get back the instruction structs, you're either using `rb_vm_insn_null_translator` or `rb_vm_insn_addr2insn2` depending if it's a direct-threading build. `rb_vm_insn_addr2insn2` does some normalization to always return to you the non-trace version of whatever instruction you're looking at. `rb_vm_insn_null_translator` does not do that normalization. This means that when you're looping through the instructions if you're trying to do an opcode comparison, it can change depending on the type of threading that you're using. This can be very confusing. So, this commit creates a new translator function `rb_vm_insn_normalizing_translator` to always return the non-trace version so that opcode comparisons don't have to worry about different configurations. [Feature #18589]		2022-04-01 14:48:22 -04:00
..
controllers
helpers
loaders
models	Treat TS_ICVARC cache as separate from TS_IVC cache	2022-02-02 09:20:34 -08:00
scripts
tests
views	Finer-grained constant cache invalidation (take 2)	2022-04-01 14:48:22 -04:00