-
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
go/doc/comment: failure to recognize initial code block #61373
Comments
Interesting - subtly, I think the implementation has a notion of common indentation. By tweaking the relative amount of whitespace it's possible to get different parses (https://go.dev/play/p/-MM0d5hDbYk). Is this a documentation thing? I couldn't pick out this behavior from the documentation directly or infer it from subtle details it does cover. The package doc for Parser.Parse says:
Would "Comment markers and indentation common to all lines in |
I would prefer if the current behavior was an error, because I would like the freedom to start a comment with a code block, which seems is not currently possible. but if I had to guess, I would say the current behavior is correct, and that the documentation needs to be improved.
I dont think so. I think this behavior is unexpected enough that it should be special cased in the documentation, assuming the current behavior is correct. so something like:
|
I think this is possible? In https://go.dev/play/p/-MM0d5hDbYk just having the opening line have more spaces in front seemed to set it into a |
yes, I just noticed that as well. it seems the current restriction would more accurately be:
|
This is happening because the go/doc/comment parser first strips any indentation that appears consistently in every line. If you change your example to const fail = ` two
three
four` then the initial code block is recognized. Stripping consistent indentation is a heuristic that seems to work reasonably well in practice. |
ideally I would like to be able to have a code block only comment, which is not currently possible. however failing that, I think it would be helpful to at least document that its a known shortcoming that you cannot do that. |
Change https://go.dev/cl/524039 mentions this issue: |
Fixes golang/go#61373 Change-Id: I60fa1be13cb7e32af5169e303f5e1c40d207edc4 Reviewed-on: https://go-review.googlesource.com/c/website/+/524039 Reviewed-by: Russ Cox <rsc@golang.org> Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
What version of Go are you using (
go version
)?What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
if I run this code:
What did you expect to see?
What did you see instead?
it seems the first input gives expected output, but the second does not. from what I can tell, both inputs match the definition of a code block:
https://go.dev/doc/comment#code
The text was updated successfully, but these errors were encountered: