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.
b1254a4463635f9a4eddb19e8fa1e379f1383e20
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.
8b6e764c43499f8595ac75086720dbe1624e0c02
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.
c6f4016b8c9c279153dc353bb22eb4011e41cc70
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
6b8a8a102051edeb74fe6596b8cd05d2a312f0f3
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.
1fe745ad0baf2ebe14f78bc10ed6ffdc131cdce0