dmitri.shuralyov.com/go/generated
update implementation for 2020 spec changes dmitri.shuralyov.com/go/generated#1
Shortened 'golang.org' to 'go.dev' here, and on line 24.
asdf
Should capitalize sentence :P
given at the start of the line and updated at the end of the line
I know what you mean, but I find the wording confusing. To be honest I'd probably not use a pointer and instead return the new state of inBlock.
I'm following the Go style for commit messages, which chooses to do:
A rule of thumb is that it should be written so to complete the sentence "This change modifies Go to _____." That means it does not start with a capital letter, is not a complete sentence, and actually summarizes the result of the change.
(From https://go.dev/doc/contribute#first_line and emphasis mine.)
Go fuzzing support is out of beta and no longer uses this build constraint. It should be replaced with go1.18 by now.
Done in PS 3.
I replaced the confusing description here with a better comment for var inBlock bool in Parse.
inBlock value. It got awkward because containsNonComment already returns a bool, so it started needing named result parameters, but inBlock couldn't be reused, and another name becomes confusing. Similarly, dealing with two results in the caller made it clunky.I also explored making
containsNonComment a method, so it could just update its field, but that added more verbosity compared to just making this one bool a pointer. So, I don't like using a pointer either, but not using it didn't end up working out better.Ultimately, there's not much point for
Parse to break input into lines via ReadLines('\n') and process them separately. By now it makes more sense to just do everything in one pass, reading byte-by-byte, while keeping track of /* */ and // style comments, until the first non-comment byte. When that optimization happens, the pointer will go away.
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 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.