ziglang
Sema: allow comptime mutation of multiple array elements
See the added test case for an example of what this fixes.
Previously, if you had a pointer to multiple array elements and tried to write to it at comptime, it was incorrectly treated as a pointer to one specific array value, leading to an assertion down the line. If we try to mutate a value at an elem_ptr larger than the element type, we need to perform a modification to multiple array elements.
This solution isn't ideal, since it will result in storePtrVal serializing the whole array, modifying the relevant parts, and storing it back. Ideally, it would only take the required elements. However, this change would have been more complex, and this is a fairly rare operation (nobody ever ran into the bug before after all), so it doesn't matter all that much.
Resolves: #8304 Resolves: #10211 Resolves: #13336
and this is a fairly rare operation (nobody ever ran into the bug before after all), so it doesn't matter all that much.
Definitely not, I've seen it multiple times, have had it happen to me and others. If this works, it closes #13336 and a whole heck of similar issues.
Oh, interesting, I hadn't seen it happen before. The potential performance overhead probably still isn't a big deal tho, since in most cases you're probably writing to what is still a fairly small array.
This definitely resolves #13336, SHA-256 at comptime was my original test case for this prior to reduction and I made sure it worked post-fix. You mention there are other similar issues this might close; do you happen to know what they are?
My own issue: #10211 -> #8304 I'm sure there are plenty more, these are the ones I could find fast. If you could make sure these work with the update, that would be amazing.
Okay, I guess I can take a lap around the issue tracker to see what's fixed by this later then.
Oh, nice! Changed that test without any local testing about 5 minutes before I go to bed, I'll see tomorrow how it went :D
FWIW I'm now working on a total rewrite of the comptime pointer access functions which would supersede this, but I'm not 100% certain that PR will see the light of day (it's a big change, I need to check whether there are any performance implications, plus it currently has some definite issues I've not figured out) so I'm leaving this open for the second
I think merging this for now would still be a good idea as it's already finished, you can PR your rewrite later.