From 06310e3d4eb47fed88b175891cb5865bb050f020 Mon Sep 17 00:00:00 2001 From: Andrew Kelley Date: Fri, 22 Apr 2022 08:19:51 -0700 Subject: 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. --- src/Cache.zig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'src/Cache.zig') diff --git a/src/Cache.zig b/src/Cache.zig index 2438c5528d..0d4b51492d 100644 --- a/src/Cache.zig +++ b/src/Cache.zig @@ -690,7 +690,7 @@ pub const Manifest = struct { while (true) { switch (it.next() orelse return) { .target, .target_must_resolve => return, - .prereq => |file_path| try self.addFilePost(file_path), + .prereq => |bytes| try self.addFilePost(bytes), else => |err| { try err.printError(error_buf.writer()); log.err("failed parsing {s}: {s}", .{ dep_file_basename, error_buf.items }); -- cgit v1.2.3