go 1.18 generics support issue

[liveever]

Describe the bug
go 1.18 generics not supported

To Reproduce
type Result2 [T any] struct {
Data T json:"data"
Meta string json:"meta"
}

The T type could not be recognized

Expected behavior
The T type could be recognized

Screenshots
If applicable, add screenshots to help explain your problem.

Your swag version
1.8.1

Your go version
1.18

[ubogdan]

My bad, the binary was built with go version go1.17.8 linux/amd64 which doesn't support generics.

I won't do a release only for this , please use the following command to build It locally
go install github.com/swaggo/swag/cmd/swag@v1.8.1

[wagnerww]

@ubogdan How do I use this feature?
I updated to the version that commented above, but still the error persists:
:cannot find type definition: T

[ubogdan]

What feature?

[wagnerww]

@ubogdan How do I generate the documentation with swag for this:
type Result2 [T any] struct {
Data T json:"data"
Meta string json:"meta"
}

you mentioned to install the version below, but how do I get the T parameter
go install github.com/swaggo/swag/cmd/swag@v1.8.1

[ubogdan]

GoLang 1.18 comes with many changes, and swag is not ready yet, as you may see.

If you need this feature, please feel free and contribute with a PR, and I will be more than happy to assist you with a CR.

[ipointer-netrise]

@ubogdan - do we have any specific issues created for generics support? I may be able to tackle some a smaller piece at a time if this were broken out... Or is this the only generics/1.18 issue at the moment?

[ghoshabhi]

would be really nice to get support for 1.18! I have 1 function in my code. Our solution at the moment is to remove this generic function until this pkg is ready

Output error:

swag init -g cmd/api/main.go
2022/04/07 18:56:36 Generate swagger docs....
2022/04/07 18:56:36 Generate general API Info, search dir:./
2022/04/07 18:56:36 warning: failed to get package name in dir: ./, error: execute go list command, exit status 1, stdout:, stderr:no Go files in /Users/username/path/to/project
2022/04/07 18:56:36 ParseFile error:pkg/helpers/common.go:3:10: expected '(', found '['
make: *** [swagger] Error 1

Maybe we can add a temporary hack so that users could ignore certain file patterns ?

swag/parser.go

Line 1393 in 32f02b9

if strings.HasSuffix(strings.ToLower(path), "_test.go") || filepath.Ext(path) != ".go" {

[ubogdan]

would be really nice to get support for 1.18! I have 1 function in my code. Our solution at the moment is to remove this generic function until this pkg is ready

There is no support for generics at all. If someone here intends to contribute, I will be more than happy to assist you with a CR.

Please remember to open a feature request and document what exactly is going to be implemented, We need a way to track these changes.

[ubogdan]

would be really nice to get support for 1.18! I have 1 function in my code. Our solution at the moment is to remove this generic function until this pkg is ready

Unfortunately, this is the only option for now.

[eljoth]

would be really nice to get support for 1.18! I have 1 function in my code. Our solution at the moment is to remove this generic function until this pkg is ready

Unfortunately, this is the only option for now.

Any updates on this one ?
I think one generic function should not break the whole pipeline after almost 3 months of generics being released and an open PR about that topic.
I would prioritize that.

[ubogdan]

@eljoth Don't you think it would be more helpful to contribute instead of criticizing?
This is an open-source project, and all the features come from community contributions.

[eljoth]

@ubogdan I did not want to offend and sound that harsh. It just seemed for me that there is no prio to work in that.

[johan-lejdung]

@ubogdan Is there a planned release for the features @FabianMartin added?

I'll fork and do a release myself otherwise since it's much needed in my project at the moment 😅

[ubogdan]

We will release a new version in the next few days.

[johan-lejdung]

Thank you for the response @ubogdan. I couldn't help myself and I forked to repo to be able to try it against our codebase.

Seems like there still are some issues with nested generic fields, I've raised the following issue #1304

@FabianMartin was this use-case expected to be covered by your contributions? Or am I using it in an unsupported way?

[johan-lejdung]

This should be possible to close when a new release is done, right?

[ubogdan]

v1.8.6 has been released.