With the new specification, it's possible to stop reading a file early even when the generated comment is absent, since the generated comment may no longer appear anywhere in the file. Begin parsing /* */ comment blocks, which may span multiple lines, to be able to be able to detect when we run into the first non-comment, non-blank text in the file. It was mentioned in https://go.dev/issue/41196#issuecomment-686607452: > [...] the primary focus for these comments is Go code > and more generally Go package sources. > Go package sources today can be Go, assembly, C, C++, Objective C, > SWIG, and Fortran. > The comment being discussed here, like the //go:build comment, > handles all of these these except Fortran, which seems fine. The initial scope of this package was to support parsing Go source only, but it happens to work well with many other source types that are found in Go packages. Replace mentions of "a Go source file" in documentation and code with "a source file", to make it apply more generally. If this will mean we need to parse comments differently depending on the source type in the future, we can revisit this decision. Let's see how it goes. Fixes issue 1. Reviewed-On: https://dmitri.shuralyov.com/go/generated/...$changes/1
Enough time has passed since the API was created, and so far, I have not had desires to change it, nor has anyone else suggested any API improvements. It's likely going to stay as is, so remove the comment. If there are good change ideas in the future, it can still be considered. But the comment was meant for the very early days of the package's existence, and has outlived its usefulness.
On Windows, a file that hasn't been gofmt'ed can have \r\n line endings. Though rare and unusual, it's still a valid .go file and needs to be supported. The performance cost is not significant compared to the entire task. name old time/op new time/op delta ParseFile-8 32.4µs ± 1% 32.4µs ± 1% ~ (p=1.000 n=10+10) Fixes https://github.com/shurcooL/go/issues/30.
This makes it possible to use this package in contexts where the .go file is in memory or otherwise not available on disk. For now, keep ParseFile around as a trivial helper. If it ends up being not used in the wild much, perhaps it could be deprecated/removed later. Fixes https://github.com/shurcooL/go/issues/31.
The specification proposal at golang.org/issue/13560 has changed. This updates the parser implementation for the latest spec as described at https://golang.org/s/generatedcode: Generated files are marked by a line of text that matches the regular expression, in Go syntax: ^// Code generated .* DO NOT EDIT\.$ The .* means the tool can put whatever folderol it wants in there, but the comment must be a single line and must start with Code generated and end with DO NOT EDIT., with a period. The text may appear anywhere in the file. The new implementation for this spec is simpler. It uses bufio.Reader and ReadBytes. The performance can be optimized further by using lower level IO primitives and allocating less, but the first priority is getting a correct parser out for the latest spec. It can be optimized later as needed. The main cause of inefficiency is having to read the entire file, without being able to stop early, because the new specification allows the comment to appear anywhere in the file. GitHub-Pull-Request: https://github.com/shurcooL/go/pull/29
This new package contains an initial attempt at implementing a parser for the currently proposed specification for generated disclaimer comment in golang.org/issue/13560.