Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

changelog entry, panic less often, reject newer Go versions, document init order caveat #835

Merged
merged 5 commits into from
Feb 18, 2024
Merged

changelog entry, panic less often, reject newer Go versions, document init order caveat #835

merged 5 commits into from
Feb 18, 2024

Commits on Feb 18, 2024

  1. CHANGELOG: add entry for v0.12.1

    @mvdan
    mvdan committed Feb 18, 2024
    Configuration menu
    Copy the full SHA
    c1ddd67 View commit details
    Browse the repository at this point in the history

  2. don't panic when we can error as easily 

    Panicking in small helpers or in funcs that don't return error
has proved useful to keep code easier to maintain,
particularly for cases that should typically never happen.

However, in these cases we can error just as easily.
In particular, I was getting a panic whenever I forgot
that I was running garble with Go master (1.23), which is over the top.
    @mvdan
    mvdan committed Feb 18, 2024
    Configuration menu
    Copy the full SHA
    d25c1a2 View commit details
    Browse the repository at this point in the history

  3. fail early if we know we lack Go linker patches 

    Right now, we only have linker patches for Go 1.22.x.
We only ever maintain those for one or two major Go versions at a time.

If a user tries to use the Go toolchain from 1.21, we already fail
with "Go version too old" messages early on, but we don't for 1.23,
causing a relatively confusing error later on when we link a binary:

    cannot get modified linker: cannot retrieve linker patches: open patches/go1.23: file does not exist

Instead, fail early and with a good error message.
    @mvdan
    mvdan committed Feb 18, 2024
    Configuration menu
    Copy the full SHA
    5658a35 View commit details
    Browse the repository at this point in the history

  4. README: document the package initialization order caveat 

    Keeping the original lexical sorting of Go packages would be very hard,
as a Go program may import an unknown number of Go packages,
and we load and obfuscate one package at a time by design.

One option would be to load all packages upfront when obfuscating
main packages, but that would break the per-package caching of
ofbuscated Go packages, causing a huge slow-down in builds.

Another option would be to not obfuscate import paths,
which would clearly cause a worsening of the obfuscation quality.

The third option is to not attempt to keep the original order,
and document that as a caveat in the README.
I suspect the vast majority of Go projects won't be affected by this,
and those few that might be can always use imports to enforce the order.

Closes burrowers#693, per the decision above to not change what we do.
    @mvdan
    mvdan committed Feb 18, 2024
    Configuration menu
    Copy the full SHA
    81d0beb View commit details
    Browse the repository at this point in the history

  5. use types.Info.PkgNameOf 

    It accomplishes the same Implicits/Defs logic we were doing here.
    @mvdan
    mvdan committed Feb 18, 2024
    Configuration menu
    Copy the full SHA
    75fb58c View commit details
    Browse the repository at this point in the history