- choose smp_allocator depending on optimization mode
- organize the globals
- avoid pessimistically allocating failed command string
- recover the PkgConfig memory
- recover the memory from captureChildProcess
- make Step.result_stderr gpa-owned so it doesn't leak when a step that
fails with stderr is re-run
- recover memory from evalZigTest and evalGeneric child process stdio
streams
I'm a bit confused because my understanding is that each step is
supposed to make its own decision about whether to clear its watch
inputs and start over, or retain them from the previous update. However,
without this fix in place, the problem from #35224 manifests itself
again.
Since this fix is in place in master branch, I'll leave it for now and
audit the file watching logic later.
next thing to do is figure out how LazyPath is supposed to work now.
something like this:
* each Step that provides LazyPath objects has a setLazyPath and
getLazyPath function which takes a tagged union identifying which one
to access
* steps that fulfill LazyPath objects can freely call setLazyPath
without obtaining a lock because the dependency graph prevents
simultaneous access.
* similarly, steps that access LazyPath results can freely call
getLazyPath without obtaining a lock, because after modification,
there may be simultaneous reads from dependencies but they will all be
read-only
* a fulfilled LazyPath object is a read-only std.Build.Cache.Path.
David Senoner