go/ast: document CommentGroup types
diff --git a/src/go/ast/ast.go b/src/go/ast/ast.go
index a3dc0c3..543cb83 100644
--- a/src/go/ast/ast.go
+++ b/src/go/ast/ast.go
@@ -75,6 +75,14 @@
// A CommentGroup represents a sequence of comments
// with no other tokens and no empty lines between.
+//
+// There are two separate types of comment groups, both represented by a CommentGroup:
+// - Line comment group: comments where every comment starts on the same line.
+// Such group is recognized by [go/parser] when, before a COMMENT token,
+// another (non-COMMENT) token appears on the same line before.
+// - Block comment group: a block of comments, comments might start at different lines, but
+// such comments cannot be separated by an empty line.
+// Such group is recognized by [go/parser] when a COMMENT token is the first token on a line.
type CommentGroup struct {
List []*Comment // len(List) > 0
}
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
// There are two separate types of comment groups, both represented by a CommentGroup:
Tighter:
The parser creates two kinds of CommentGroup.
A line comment group is a sequence of comments all on the same line, following a token on that line.
A block comment group is a sequence of comments, starting on a line without tokens.
In other words, the parser promises both "maximal munch", and not to conjoin a line comment group with a block comment in cases such as this:
```
foo // line
// block
```
We should probably await gri's comments before strengthening the parser's postcondition.
// - Line comment group: Recognized by [go/parser] when a comment is not the first
// token on the line. Such group ends when a non-comment token, an empty line
Comments are not tokens, BTW.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
I'll have to re-read the comment group logic to verify correctness of this comment. It's been a while...
adonovan: how are we strengthening the parser's postcondition?
// token on the line. Such group ends when a non-comment token, an empty line
Since comments are not tokens, maybe:
... when a token (not a comment) ...
Also below.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Commit-Queue | +1 |
I'll have to re-read the comment group logic to verify correctness of this comment. It's been a while...
adonovan: how are we strengthening the parser's postcondition?
I'll have to re-read the comment group logic to verify correctness of this comment. It's been a while...
FYI skimming CL 703815 might help with that (not sure we want that change though).
// There are two separate types of comment groups, both represented by a CommentGroup:
Tighter:
The parser creates two kinds of CommentGroup.
A line comment group is a sequence of comments all on the same line, following a token on that line.
A block comment group is a sequence of comments, starting on a line without tokens.In other words, the parser promises both "maximal munch", and not to conjoin a line comment group with a block comment in cases such as this:
```
foo // line
// block
```We should probably await gri's comments before strengthening the parser's postcondition.
Updated the comment.
// token on the line. Such group ends when a non-comment token, an empty line
Since comments are not tokens, maybe:
... when a token (not a comment) ...Also below.
I think i prefer the tighter version of this comment (as written by Alan). WDYT?
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |