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

Fix some typos; update links to latest protocompile #65

Merged
merged 2 commits into from
Nov 1, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions docs/examples.md
Original file line number Diff line number Diff line change
Expand Up @@ -24,6 +24,6 @@ more features, and we also may add new examples to the list using other parser g

Another example that may be interesting to examine, in addition to the above, is the actual
parser that powers Buf. It uses YACC for Go (aka [Goyacc](https://pkg.go.dev/golang.org/x/tools/cmd/goyacc)),
so it includes inlined Go code for producing an [AST](https://pkg.go.dev/github.com/bufbuild/protocompile@v0.2.0/ast).
That configuration can be found [here](https://github.com/bufbuild/protocompile/blob/v0.2.0/parser/proto.y).
Lexical analysis in Buf uses a [hand-written tokenizer in Go](https://github.com/bufbuild/protocompile/blob/v0.2.0/parser/lexer.go#L169).
so it includes inlined Go code for producing an [AST](https://pkg.go.dev/github.com/bufbuild/protocompile@v0.14.1/ast).
That configuration can be found [here](https://github.com/bufbuild/protocompile/blob/v0.14.1/parser/proto.y).
Lexical analysis in Buf uses a [hand-written tokenizer in Go](https://github.com/bufbuild/protocompile/blob/v0.14.1/parser/lexer.go#L170).
14 changes: 7 additions & 7 deletions docs/language-spec.md
Original file line number Diff line number Diff line change
Expand Up @@ -493,10 +493,10 @@ EmptyDecl = semicolon .
### Syntax Declaration

Files should define a syntax level. If present, this must be the first
declaration in the file. When the "syntax" keyword is used, string literal
indicates the syntax level and must have a value of "proto2" or "proto3".
If the "edition" keyword is used, the file is said to use Editions syntax,
and the string literal indicates a particular indication. By convention,
declaration in the file. When the "syntax" keyword is used, the string
literal indicates the syntax level and must have a value of "proto2" or
"proto3". If the "edition" keyword is used, the file uses Editions syntax,
and the string literal indicates a particular edition. By convention,
editions are named after the year in which their development began. The
first edition is "2023".

Expand Down Expand Up @@ -545,8 +545,8 @@ enum does not necessarily mean that the edition is actually
_supported_ or even completely defined. For example, v27.0 of
the Protobuf distribution includes a value named `EDITION_2024`,
but such a version was not implemented yet. It is present in the
file because it must be added to the enum before any
implementation work can actually being. Once the edition is
file because it must be added to the enum *before* any
implementation work can actually begin. Once the edition is
adequately implemented for users to try it out, it can be made
available for users of `protoc` via an `--experimental_editions`
flag. (Users were able to experiment with edition 2023 in this
Expand Down Expand Up @@ -629,7 +629,7 @@ dependencies.
#### Visibility

When one element in a file refers to another element (defined in the same file
or possible in another file), the referenced element must be _visible_ to that
or possibly in another file), the referenced element must be _visible_ to that
file. Imports are how elements in one file are made visible to another.

The elements that are visible to a given file include the following:
Expand Down