cmd/compile: init code or linker should verify package "fingerprint" #20486
Labels
compiler/runtime
Issues related to the Go compiler and/or runtime.
help wanted
NeedsFix
The path to resolution is known, but the work has not been done.
Milestone
Given a file lib.go:
and main.go:
The following command sequence prints 42 as expected:
If one now changes 42 to 43 in lib.go, the following command sequence still prints 42:
rather than 43. The issue is (presumably) that lib.F() got inlined and there's (apparently) no check in the linker that lib.go changed.
While not surprising to an initiated user, this is surprising to an unsuspecting user. Ideally the linker, or then the initialization code should check that a compiler package we link again (or that we initialize) is the same that we compiled against. This could be done with some fingerprint of sorts, perhaps computed on the export data only.
I suspect scenarios can be created where the linker succeeds and the program crashes (because a data type changed in lib.go and main.go wasn't recompiled).
This behavior is no different from C/C++ where we have "independent" compilation: as long as the linker finds the matching symbols, it doesn't care whether they are referring to the same entities that were implied in the source code - hence the independence.
Go should properly implement "separate" compilation: packages can be compiled separately, but correspondence to source code should be enforced.
The text was updated successfully, but these errors were encountered: