My reasoning was that in a guarded situation where we are using this modifiable_tracker I couldn't think of a reason *not* to allow it to reuse external storage where the object in that storage has been destroyed.
I also couldn't think of a case that would validly hit that branch, so i'm fine either way. I'll get a v2 that skips void_node out next, and i'll add a comment indicating that the skipping is intentional. On Sat, Sep 19, 2026 at 5:43 PM Jason Merrill <[email protected]> wrote: > On 9/18/26 7:21 PM, Joshua Berne wrote: > > Attached is a patch fixing a bug that occurs when a contract assertion > > during constant evaluation invokes a function that has already been > > invoked (outside the contract assertion) during that constant evaluation > > --- the already-destroyed result object for the function looks like an > > attempt to modify code outside the function to the contract assertion > > evaluation. > > > > A similar code path could probably be constructed where an [[assume]] > > would be discarded, which is very hard to observe but should also be > > smoothed out by this patch. > > > This change updates the put_value member of constexpr_global_ctx to > recognize > > void_list_node values in the map as not being a concern for what > modifiables > > is tracking, and treats them the same way it treats not yet having a > value in > > the map for that key. > > Agreed, those cases can be treated as equivalent. > > > void_node is treated the same way if it is found in > > the map to be consistent with other handling of the values that are > stored, > > though no case seems to currently hit that path. > > Let's not treat void_node the same way; that indicates an object still > within its storage duration. > > Jason > >
