-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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
x/pkgsite, x/tools/cmd/godoc: some code examples are not displayed (but work at godoc.org) #40172
Comments
Thanks for reporting. I tested this package at commit go-pg/pg@6fe164e with pkg.go.dev, godoc.org, and x/tools/cmd/godoc, and can confirm the issue is present in pkg.go.dev and x/tools/cmd/godoc, but not godoc.org. It's also helpful to look at the complete listing of examples at https://godoc.org/github.com/go-pg/pg?tab=doc#pkg-examples, https://pkg.go.dev/github.com/go-pg/pg/v10?tab=doc#pkg-examples, and the output of x/tools/cmd/godoc: This looks like a valid issue. It needs investigation to understand why these examples, which appear to be following the example naming convention correctly, are not showing up in 2 out of 3 documentation viewers. It might be a problem in the example matching logic in |
One lead to investigate is that the exported
Notably,
The example classification logic in I haven't confirmed further, just wanted to share this. |
@dmitshur you're right that the issue is related to the embedded field. However, this appears to be expected behavior and is documented in https://github.com/golang/go/blob/master/src/go/doc/example.go#L489-L491
Removing
appears to fix this issue. The question now is whether we should consider embedded field methods for examples. One problem I can think of is that the embedded field type could also be exported, resulting in duplicate examples. However, we can check for this case easily (i.e. whether the embedded field is exported) and choose not to show the example for either the original struct type or the embedded field type. /cc @dsnet @griesemer |
Gentle ping. It seems to be better having duplicated examples rather than not having them at all. Also if duplicates are problematic - authors can rework examples and place them on different struct. |
The type for which to show the example is embedded in its name: In determining whether |
The fundamental problem is that we don't have full type information when building the doc, so we can't really compute the full method set in all cases. However, we do know about types in the same package. So I can't think of a reason we shouldn't use that information. So we should remove the It is out of scope for this issue to make the change in |
@jba The original plan for pkgsite's copied |
@dmitshur I see, I hadn't realized that. In that case, I think we should make the change in |
I sent https://golang.org/cl/249557 to change |
Change https://golang.org/cl/249638 mentions this issue: |
…d unexported types This CL uses the same logic as implemented in CL 249557. In type T1 struct { t2 } type t2 int func (t2) M() T1 has method M because it embeds t2, which has M. Classify the example func ExampleT1_M with T1 instead of ignoring it, as is done currently. There is no other way to provide an example for such a method, since its original type is unexported. Continue to ignore examples on methods from embedded types that are exported, unless in AllMethods mode. Examples for those methods could be written on the original type. The change involves removing a check in classifyExamples. The check isn't necessary to get the above behavior because reader.collectEmbeddedMethods and sortedFuncs already generate the appropriate list of methods. Updates golang/go#40172 Change-Id: Iaeffc1dcfcfca42dc91db1e2527b10286c06fa84 Reviewed-on: https://go-review.googlesource.com/c/pkgsite/+/249638 Reviewed-by: Jonathan Amsterdam <[email protected]>
Change https://golang.org/cl/249557 mentions this issue: |
In type T1 struct { t2 } type t2 int func (t2) M() T1 has method M because it embeds t2, which has M. Classify the example func ExampleT1_M with T1 instead of ignoring it, as is done currently. There is no other way to provide an example for such a method, since its original type is unexported. Continue to ignore examples on methods from embedded types that are exported, unless in AllMethods mode. Examples for those methods could be written on the original type. The change involves removing a check in classifyExamples. The check isn't necessary to get the above behavior because reader.collectEmbeddedMethods and sortedFuncs already generate the appropriate list of methods. For #40172. Change-Id: Ibe7d965ecba6426466184e6e6655fc05989e9caf Reviewed-on: https://go-review.googlesource.com/c/go/+/249557 Reviewed-by: Dmitri Shuralyov <[email protected]>
For example
The text was updated successfully, but these errors were encountered: