error obfuscating go-openapi/spec: cannot use make as value in assignment

[nickolastone]

What version of Garble and Go are you using?

$ garble version
mvdan.cc/garble v0.9.3

Build settings:
      -buildmode exe
       -compiler gc
     CGO_ENABLED 1
          GOARCH arm64
            GOOS darwin

$ go version
go version go1.20.1 darwin/arm64

What environment are you running Garble on?

go env Output

$ go env
GO111MODULE=""
GOARCH="arm64"
GOBIN=""
GOCACHE="/Users/nickolast/Library/Caches/go-build"
GOENV="/Users/nickolast/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="arm64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/user/go/pkg/mod"
GOOS="darwin"
GOPATH="/Users/user/go"
GOROOT="/opt/homebrew/Cellar/go/1.20.1/libexec"
GOSUMDB="sum.golang.google.cn"
GOTMPDIR=""
GOTOOLDIR="/opt/homebrew/Cellar/go/1.20.1/libexec/pkg/tool/darwin_arm64"
GOVCS=""
GOVERSION="go1.20.1"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/dev/null"
GOWORK=""
CGO_CFLAGS="-O2 -g"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-O2 -g"
CGO_FFLAGS="-O2 -g"
CGO_LDFLAGS="-O2 -g"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/9r/n4smctzd5tx3vr1z48tmn1y00000gn/T/go-build88002715=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

What did you expect to see?

garble build done

What did you see instead?

github.com/go-openapi/spec

:1: cannot use make([]map[string]struct{PkQkPm []string; Zw3sMnzI4_l bool}, 0, len(chPWgF2S.Security)) (value of type []map[string]struct{PkQkPm []string; Zw3sMnzI4_l bool}) as []map[string]struct{List []string; Pad bool} value in assignment
:1: cannot use jB3BcU6B3 (variable of type map[string]struct{PkQkPm []string; Zw3sMnzI4_l bool}) as map[string]struct{List []string; Pad bool} value in argument to append
:1: cannot use make([]map[string]struct{PkQkPm []string; Zw3sMnzI4_l bool}, 0, len(lBSSbmm.Security)) (value of type []map[string]struct{PkQkPm []string; Zw3sMnzI4_l bool}) as []map[string]struct{List []string; Pad bool} value in assignment
:1: cannot use jB3BcU6B3 (variable of type map[string]struct{PkQkPm []string; Zw3sMnzI4_l bool}) as map[string]struct{List []string; Pad bool} value in argument to append
exit status 2
exit status 1

[lu4p]

Can you share some code so we can reproduce?

[nickolastone]

main.go

package main

import (
	"github.com/gin-gonic/gin"
	swaggerfiles "github.com/swaggo/files"
	ginSwagger "github.com/swaggo/gin-swagger"
)

func main() {
	var router = gin.New()
	router.GET("/swagger/*any", ginSwagger.WrapHandler(swaggerfiles.Handler))
}

docs/docs.go

// Code generated by swaggo/swag. DO NOT EDIT
package docs

import "github.com/swaggo/swag"

const docTemplate = `{
    "schemes": {{ marshal .Schemes }},
    "swagger": "2.0",
    "info": {
        "description": "{{escape .Description}}",
        "title": "{{.Title}}",
        "contact": {},
        "version": "{{.Version}}"
    },
    "host": "{{.Host}}",
    "basePath": "{{.BasePath}}",
    "paths": {
    }
}`

// SwaggerInfo holds exported Swagger Info so clients can modify it
var SwaggerInfo = &swag.Spec{
	Version:          "1.0",
	Host:             "",
	BasePath:         "/v1",
	Schemes:          []string{},
	Title:            "test",
	Description:      "test",
	InfoInstanceName: "swagger",
	SwaggerTemplate:  docTemplate,
}

func init() {
	swag.Register(SwaggerInfo.InstanceName(), SwaggerInfo)
}

garble build main.go

[mvdan]

The code in question is:

https://github.com/go-openapi/spec/blob/df35a527ea5dde89966d4c6b7661d000a99899b9/swagger.go#L160-L180

We appear to not obfuscate the anonymous struct type in the Security field, presumably because our current reflect detection is good enough to catch that - since raw gets used with encoding/gob. However, we do obfuscate the equivalent anonymous types used in the v := make(T) and v[k] = T{} statements, so then append fails to compile since the types mismatch.

I think it makes sense to look at this once @lu4p's #644 is merged. It's entirely possible that his new detection logic already handles this case properly, in which case we should just add a regression test that failed with the old detection.

[nickolastone]

would #644 merge in next release?

[mvdan]

We want to merge it soon, yes.

[mvdan]

This appears to still happen in master after the latest changes; cc @lu4p.