-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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
fmt: compound object rules don't seem to apply recursively #28625
Comments
related: #27768 (comment) |
You're right; I hadn't caught that issue as the title seemed unrelated. Should we keep this issue open and amend the documentation? |
I think the issues are slightly different (the other one started as %d not applying to pointers, which IIRC is WAI according to the documentation). So happy if this stays open and we can discuss if we should just update the documentation. With the other issue i wanted to reference the note that the implementation is deliberately not following pointers to arbitrary depth as there could be loops in pointer chains. |
Those look like rules for Output using
Which makes a bit more sense. Since it's a pointer to a pointer, |
Change https://golang.org/cl/147997 mentions this issue: |
I don't think the rules only apply to |
As far as I understand the rules for compounds they should always apply. As far as I remember the implementation it will work for all verbs except for %T and %p as those are handled specially. |
Every time we try to fix fmt to be more consistent or correct, we roll back the change because it breaks things. I suspect we should just leave it alone. |
I don't imagine that clarifying the docs will break any program :) |
Pointers to compound objects (structs, slices, arrays, maps) are only followed by fmt if the pointer is at the top level of an argument. This is to minimise the chances of fmt running into loops. However, vet did not follow this rule. It likely doesn't help that fmt does not document that restriction well, which is being tracked in #28625. Updates #27672. Change-Id: Ie9bbd9b974eda5ab9a285986d207ef92fca4453e Reviewed-on: https://go-review.googlesource.com/c/147997 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Alan Donovan <adonovan@google.com>
https://golang.org/pkg/fmt/#hdr-Printing reads:
It is specifically said that these rules apply recursively. However, take a look at this playground link: https://play.golang.org/p/CbrniH9q45I
It currently prints:
But I'd expect it to print:
Reading the docs carefully again, I can't find a reason why only top-level pointers would follow the "pointer to above" rule that's clearly documented.
It seems to me like either the code is wrong, or the docs need clarification. If only top-level pointers are supposed to follow the "pointer to above" rule, that should be made clear in the rules.
This issue is split from #27672. I initially thought this was a bug in vet, but then started wondering if this was a bug in fmt instead.
/cc @robpike @martisch @rogpeppe
The text was updated successfully, but these errors were encountered: