Yes, I thought about it and I am quite sure that it would be very complex
code detecting referenced but unused code.
I am just starting with learning how to break things apart properly. Go
makes it easy to modularise but old bad habits to make monolithic stuff
don't dissolve overnight, and in
On Fri, Jun 28, 2019 at 11:39 AM wrote:
>
> I am pretty sure that every folder in a Go code repository creates one binary
> object, maybe two with a test package alongside it. It just didn't occur to
> me that it would not trace the execution path of the main, and where each of
> the
I am pretty sure that every folder in a Go code repository creates one
binary object, maybe two with a test package alongside it. It just didn't
occur to me that it would not trace the execution path of the main, and
where each of the closures/function references in this case are stored in a
Please provide a minimal, self contained demonstration code that reproduces
the problem. Then it should be hopefully easy to either explain why things
work they do or it'll be a nice test case for the fix to the issue this may
actually be. Thanks.
On Fri, Jun 28, 2019, 20:10 wrote:
> I have
I have come up against something a bit strange and interesting that I
didn't really expect from the Go compiler.
I have a main which uses a structure created in a package, which contains a
whole load of references to other packages.
What I discovered is that even though only one of these
