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.

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

Formatting crosstalk #1314

Closed
MrDOS opened this issue Sep 3, 2022 · 2 comments · Fixed by #1317
Closed

Formatting crosstalk #1314

MrDOS opened this issue Sep 3, 2022 · 2 comments · Fixed by #1317

Comments

@MrDOS
Copy link
Contributor

MrDOS commented Sep 3, 2022

Describe the bug

When one function has poorly formatted annotations, swag fmt may incorrectly modify the formatting of other functions.

To Reproduce

main.go:

package main

// @Produce json
// @Success 200 {object} string
// @Failure 400 {object} string
func A() {}

// @Description Description of B.
// @Produce json
// @Success 200 {array} string
// @Failure 400 {object} string
func B() {}

Then run swag fmt.

The resulting main.go:

package main

// @Produce     json
// @Success 200 {object} string
// @Failure     400 {object} string
func A() {}

// @Description Description of B.
// @Produce json
// @Success     200 {array}  string
// @Failure 400 {object} string
func B() {}

Expected behavior

  • I do not expect the comments on function A to change.
  • I expect the Swag attributes on function B to have been correctly aligned.
package main

// @Produce json
// @Success 200 {object} string
// @Failure 400 {object} string
func A() {}

// @Description Description of B.
// @Produce     json
// @Success     200 {array}  string
// @Failure     400 {object} string
func B() {}

Your swag version

$ swag --version
swag version v1.8.5

...but I can reproduce on v1.8.4 and the latest development version.

Your go version

$ go version
go version go1.18.5 darwin/arm64

...but I can reproduce on Go 1.19, and on Linux AMD64.

Desktop (please complete the following information):

  • OS: macOS 12.5.1
  • Browser: n/a
  • Version: n/a

Additional context

This is the most messed-up example of this that I could come up with. It seems to be extremely sensitive to how well-formatted the input is to begin with, and the success/failure types.

  • Half-indenting attributes or changing their types produces further wild variations in output. For example, change B's success type from {array} string to {object} string, and all three of A's attributes will be indented equally, but none of B's:

    package main
    
    // @Produce     json
    // @Success     200 {object} string
    // @Failure     400 {object} string
    func A() {}
    
    // @Description Description of B.
    // @Produce json
    // @Success 200 {object} string
    // @Failure 400 {object} string
    func B() {}

    Or, change A's success and failure types from {object} string to just string, and A's produce attribute and B's success and failure attributes will be indented:

    package main
    
    // @Produce     json
    // @Success 200 string
    // @Failure 400 string
    func A() {}
    
    // @Description Description of B.
    // @Produce json
    // @Success     200 {array}  string
    // @Failure     400 {object} string
    func B() {}
  • If there is another function between A and B, it will not be affected (but A and B both still will be).

  • This does not happen if the comments on C are already correctly formatted.

  • I have only been able to trigger this behaviour with a @Description attribute on the second function, which I suspect has something to do with that attribute being longer than any on the first.

@ubogdan
Copy link
Contributor

ubogdan commented Sep 3, 2022

@MrDOS This is an Open Souce project, and you can contribute via PR to improve it.

@MrDOS
Copy link
Contributor Author

MrDOS commented Sep 5, 2022

@ubogdan, sure thing: see #1317.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants