# Revert "Fix C include files not being in \`whole\` cache \(\#11365\)" · gitcafe/zig

[View on GitCafe](https://git.cafe/gitcafe/zig/commit/06310e3d4eb47fed88b175891cb5865bb050f020)

Repository: [gitcafe/zig](https://git.cafe/gitcafe/zig)

Visibility: public

Requested revision: 06310e3d4eb47fed88b175891cb5865bb050f020

Requested commit: 06310e3d4eb47fed88b175891cb5865bb050f020

Commit: 06310e3d4eb47fed88b175891cb5865bb050f020

Tree: e19d5d14323ae797495027f33fbb63120fce660b

Author: Andrew Kelley

Committer: Andrew Kelley

## Message

```
Revert "Fix C include files not being in `whole` cache (#11365)"

This reverts commit a430630002bf02162ccbf8d3eb10fd73e490cefd.

Wait a minute, I'm sorry, I need to revert this. The whole premise
of this change is broken because the point of the hash is that it tells
whether the same compilation has been done before. This requires items
to be added to the hash in the same sequence every time. This means that
introducing a lock is fundamentally broken because the order needs to be
the same in future runs of the compiler, and not decided by threads
racing against each other.

The proper solution to this is to, in whole cache mode, append the hash
inputs to some data structure, and then after the compilation is
complete, do some kind of sorting on the hash inputs so that they will
be the same order every time, then apply them in sequence. No lock on
the Cache object is needed for this scheme.

```

## Parents

- [a430630002bf02162ccbf8d3eb10fd73e490cefd](https://git.cafe/gitcafe/zig/commit/a430630002bf02162ccbf8d3eb10fd73e490cefd?format=markdown)

[Source at this commit](https://git.cafe/gitcafe/zig/tree/06310e3d4eb47fed88b175891cb5865bb050f020?format=markdown)