From eb18969adb40313e1b46d494d03a6347691f175f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Daniel=20Mart=C3=AD?= Date: Sat, 3 Jun 2023 22:33:33 +0100 Subject: [PATCH] finally remove garbleActionID hack Our cache is now robust against different Go package build inputs which result in exactly the same build outputs. In the past, this caused Go's cache to be filled but not ours. In the present, our cache is just as resilient as Go's is. --- main.go | 21 --------------------- 1 file changed, 21 deletions(-) diff --git a/main.go b/main.go index 4328261..cd472d1 100644 --- a/main.go +++ b/main.go @@ -1011,27 +1011,6 @@ func (tf *transformer) transformCompile(args []string) ([]string, error) { if err != nil { return nil, err } - // It is possible to end up in an edge case where two instances of the - // same package have different Action IDs, but their obfuscation and - // builds produce exactly the same results. - // In such an edge case, Go's build cache is smart enough for the second - // instance to reuse the first's build artifact. - // However, garble's caching via garbleExportFile is not as smart, - // as we base the location of these files purely based on Action IDs. - // Thus, the incremental build can fail to find garble's cached file. - // To sidestep this bug entirely, ensure that different action IDs never - // produce the same cached output when building with garble. - // Note that this edge case tends to happen when a -seed is provided, - // as then a package's Action ID is not used as an obfuscation seed. - // TODO(mvdan): replace this workaround with an actual fix if we can. - // This workaround is presumably worse on the build cache, - // as we end up with extra near-duplicate cached artifacts. - // TODO: can we remove this now with the better caching? - if i == 0 { - src = append(src, fmt.Sprintf( - "\nvar garbleActionID = %q\n", encodeBuildIDHash(tf.curPkg.GarbleActionID), - )...) - } // We hide Go source filenames via "//line" directives, // so there is no need to use obfuscated filenames here.