swag: panic: runtime error: negative shift amount
Describe the bug While running the init command with master it panics
To Reproduce Steps to reproduce the behavior:
- with the following definition:
type Type string
const (
TypePerson Type = "person"
TypeBusiness Type = "business"
)
type customerIn struct {
ClientId string `json:"client_id"`
Type string `json:"type"`
}
type customerOut struct {
Id string `json:"id"`
ClientId string `json:"client_id"`
Type string `json:"type"`
CreatedAt time.Time `json:"created_at"`
UpdatedAt time.Time `json:"updated_at"`
}
type customersOut struct {
Result []customerOut
}
run:
swag init -g service/server/server.go --pd
swag fmt -g service/server/server.go
Throws the error:
swag init -g service/server/server.go --pd
2022/11/22 08:09:45 Generate swagger docs....
2022/11/22 08:09:45 Generate general API Info, search dir:./
2022/11/22 08:09:45 warning: failed to get package name in dir: ./, error: execute go list command, exit status 1, stdout:, stderr:no Go files in /Users/nicolas.sassi/dev/soul/acaiah
panic: runtime error: negative shift amount
goroutine 1 [running]:
github.com/swaggo/swag.(*PackageDefinitions).evaluateConstValue(0xc00607e870, 0xc0068aa2d0?, 0xc00665ef60?, {0x165bee0?, 0xc005cecf90?}, {0x165a460, 0xc0001b1800}, 0x1c?)
/Users/nicolas.sassi/go/pkg/mod/github.com/swaggo/swag@v1.8.8-0.20221122034606-e5d507dd4727/package.go:146 +0x102b
github.com/swaggo/swag.(*PackagesDefinitions).EvaluateConstValue(0xc00479f698?, 0xc00607e870, 0xc00682de00, 0x0)
/Users/nicolas.sassi/go/pkg/mod/github.com/swaggo/swag@v1.8.8-0.20221122034606-e5d507dd4727/packages.go:282 +0x19d
github.com/swaggo/swag.(*PackagesDefinitions).evaluateAllConstVariables(...)
/Users/nicolas.sassi/go/pkg/mod/github.com/swaggo/swag@v1.8.8-0.20221122034606-e5d507dd4727/packages.go:265
github.com/swaggo/swag.(*PackagesDefinitions).ParseTypes(0xc0001b1800)
/Users/nicolas.sassi/go/pkg/mod/github.com/swaggo/swag@v1.8.8-0.20221122034606-e5d507dd4727/packages.go:110 +0x254
github.com/swaggo/swag.(*Parser).ParseAPIMultiSearchDir(0xc00027c000, {0xc0002780e0?, 0x1?, 0x0?}, {0x7ff7bfeff555?, 0x18?}, 0x64)
/Users/nicolas.sassi/go/pkg/mod/github.com/swaggo/swag@v1.8.8-0.20221122034606-e5d507dd4727/parser.go:375 +0x3bf
github.com/swaggo/swag/gen.(*Gen).Build(0xc000249950, 0xc0002502a0)
/Users/nicolas.sassi/go/pkg/mod/github.com/swaggo/swag@v1.8.8-0.20221122034606-e5d507dd4727/gen/gen.go:182 +0x637
main.initAction(0xc000266780?)
/Users/nicolas.sassi/go/pkg/mod/github.com/swaggo/swag@v1.8.8-0.20221122034606-e5d507dd4727/cmd/swag/main.go:158 +0x7bd
github.com/urfave/cli/v2.(*Command).Run(0xc000220ea0, 0xc000262300)
/Users/nicolas.sassi/go/pkg/mod/github.com/urfave/cli/v2@v2.3.0/command.go:163 +0x5dc
github.com/urfave/cli/v2.(*App).RunContext(0xc000195d40, {0x165cef0?, 0xc000196008}, {0xc00019c000, 0x5, 0x5})
/Users/nicolas.sassi/go/pkg/mod/github.com/urfave/cli/v2@v2.3.0/app.go:313 +0xb7d
github.com/urfave/cli/v2.(*App).Run(...)
/Users/nicolas.sassi/go/pkg/mod/github.com/urfave/cli/v2@v2.3.0/app.go:224
main.main()
/Users/nicolas.sassi/go/pkg/mod/github.com/swaggo/swag@v1.8.8-0.20221122034606-e5d507dd4727/cmd/swag/main.go:229 +0x5c5
make: *** [swagger] Error 2
Expected behavior Swagger created
Your swag version go install github.com/swaggo/swag/cmd/swag@e5d507dd472777bec3a3744f7f9cc86065037530
Your go version 1.19.1
Desktop (please complete the following information):
- OS: macOS Monterey 12.6.1
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 10
- Comments: 45 (19 by maintainers)
@AdrianCio, we are releasing a new version every month. The latest version was released 7 days ago, so you can do the maths.
Meanwhile, you can test by building swag from the source.
Please don’t be rude, they are volunteer developers that don’t owe you anything.
And remember, you can simply
go install github.com/swaggo/swag@master.This is an awful decision to be made by a developer of something used by others. If the team completely breaks a stable release which forces people to rollback, its ok shit happens. If the teams answer is we only release once a month, do the math… that is ridiculous and pathetic from a developer.
Forcing people to build from source (with other potentially breaking things) in their live environments is also a stupid solution for more than just testing.
Just cut a patch release to fix your screw up, why is that not even considered before telling people to “you can do the maths”
Wonder how many folks, like myself, just pinned their version to 1.8.7 and will never upgrade it again.
Bud, I said the decision… Not the dev.
I am well aware the crap OSS devs deal with & this is all about the decision to not patch it for 3 weeks
I agree that a release should be made, but you can ask nicely and not call devs “pathetic” when they are spending their free time to bring us such a highly useful project. Being an OSS maintainer is hard enough.
Sure go ahead, no one is forcing you. Just put the notice on the README and let’s get done with this. That’d benefit the community.
If the current
stableisn’t stable why not pull the build back? Would it cause too much trouble on your end?I think the swaggo team and the community have completely different definitions of what a new
stablerelease is.If the release is not stable and production ready as you claim then it should NOT be tagged as
latestimplying a stable release and should be tagged aspre-releasefor beta testing.GitHub clearly notes that when creating a release as well.
If your releases are not production ready - as you said given saying users are testing in production - why is the team failing to mark them as NOT production ready and lying to the community?
That’s extremely poor development practice.
Pretty strange to release a broken
stablerelease and for no clear (nor rationale) reason refuse to release any hotfix simply saying to wait until the next regularly scheduled release.I got same problems, too. But if I changed swaggo version to 1.8.7, everything is fine.
Your swag version go install github.com/swaggo/swag/cmd/swag@v.1.8.8
Your go version 1.19.2 darwin/arm64
Desktop (please complete the following information):
OS: macOS Monterey 12.6
https://github.com/swaggo/swag/releases/tag/v1.8.9-rc2 is out, let’s try out and leave feedback please.
Good luck.
Contribution is not only about pushing codes. We are all here contributing to the project by discussing things, submitting bugs, using and advocating it on the internet. If release cadence is about baking and testing latest changes, I suggest you to read what the release candidate is. 😉
Good luck.
I agree with you regarding this matter. We should be more organized here. We made mistakes, and we will possibly do more.
But it would be best if you respected the time and effort invested by contributors and maintainers. After all, you never contributed to this project, but I guess you are using it.
Staying polite and benevolent in all circumstances and for all, prevent to avoid extreme and negative decisions being taken by a confusion of understanding.
and expecting users to build from source are really the only rude comments here.
but in the interest of not derailing the conversatoin
to be clear: there are no plans to ever have an off-cycle release even for critical breaking bugs or CVEs?
That’s beyond any words if that is the case. Rude, unprofessional, unethical, and a generally dick move are some terms that come to mind.
How about Bugfix/Patch releases come out ASAP while feature release following regular cadence? Are you going to say same thing when another CVE appears in the wild and you’re gonna be like “do the maths”? Dude
Oh thanks for the hint. 🚀
It might be rude but it is true. As a dev, if i completely break something that people rely on (i made the choice to give my time and break it, i will make the choice to spend my time and fix it as that is the right thing to do) i am saying this from a standpoint of making people wait instead of releasing a patch is absurd and it is.
And remember, consumers are not GO devs and should not be expected/forced to build and run from source as i already stated.
I totally get people make mistakes, hell i do it all the time! I also have the expectation if something gets completely broken (not just a small thing) it should be fixed. I expect that from myself as well.
@AdrianCio Hi, sorry to have made this bug. Enums invole a lot of const evaluation, and many cases to be considered. It is to be pefected gradually. @faustfu-WaveGIS has provided useful imformation about panic to me, and I have made an effort to fix it by PR #1440.
This is helpful to me, thank you
I’ll add some exception detecting code to output where it is