You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
...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:
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:
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.
The text was updated successfully, but these errors were encountered:
Describe the bug
When one function has poorly formatted annotations,
swag fmt
may incorrectly modify the formatting of other functions.To Reproduce
main.go
:Then run
swag fmt
.The resulting
main.go
:Expected behavior
A
to change.B
to have been correctly aligned.Your swag version
...but I can reproduce on v1.8.4 and the latest development version.
Your go version
...but I can reproduce on Go 1.19, and on Linux AMD64.
Desktop (please complete the following information):
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 ofA
's attributes will be indented equally, but none ofB
's:Or, change
A
's success and failure types from{object} string
to juststring
, andA
's produce attribute andB
's success and failure attributes will be indented:If there is another function between
A
andB
, it will not be affected (butA
andB
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.The text was updated successfully, but these errors were encountered: