This information is also available via a "find all references" query on v.Some. The cursor (hover) docs message functionality focuses more on local type information.

The primary reason I opened this issue is that the information provided about the safety of using this field is now misleading.
If I use it as it is, v.Some, as field of MyStruct, I can encounter an unexpected nil pointer dereference panic because it is actually provided by an embedded pointer to OtherStruct.
Therefore, if I am aware that a struct may contain embedded structs, I cannot rely on the LSP information.
I encountered this issue after a lengthy search for a nil pointer dereference panic in a code base that I am not familiar with.
I believe my proposal can enhance the usefulness of this LSP information and prevent panics for some developers or assist in diagnosing issues.

What about

field Some int

---

(mypkg.MyStruct.*OtherStruct).Some on pkg.go.dev

Thank you for your suggestion.
I believe it is an improvement over the current state.
At the very least, it would be beneficial to modify the quick message feature in Emacs to display two lines of hover quick documentation, the first and last.

Do you think extending the first-line message would make it excessively long?
In that case, if the chain of embedded structures is lengthy, the message could become very long. However, I am unsure why LSP cares about this.

Perhaps a way to indicate that this structure is not ‘by value’ could be implemented.
field Some *int would be more confusing than the current format, lol.
Therefore, a better suggestion would be to use

embedded field Some int

to emphasize the importance of caution when using this field.

There is another related issue.
Assume we have the following code:

_ = v.OtherStruct

and the cursor hovers over OtherStruct.
The message would then be:

field OtherStruct *OtherStruct

—

(main.MyStruct).OtherStruct on pkg.go.dev

This message does not make sense if the embedded structure or field is named the same as the type name (until the full message is opened).

It is possible that this is an issue specific to Emacs’ view, and other clients display the entire message by default.

So it is also may be solved with additional mention that it is embedded, for example:

embedded *OtherStruct

I agreed with your proposal but there could be hard to determine how many depth should we search the ref backward.

Like the following sample, what should we show as doc?

type A struct {
    V int
}

type B struct {A}

type C struct {*B}

// Then we do something
_ = C{}

_ = C.V <- cursor

On the other hand, I think there could be some perf issue to determine whether a ref's parent would be nil when there got deep-embed structs.

But if we only focus the first depth of embed, this should be a good enhancement.

I am uncertain about the current state of doc rendering. If “gopls” is already aware that c.V is a field of C, in other words, a “forward search” for the field has been performed, then it should be possible to unwind this backward to collect the embedding chain. Therefore, I believe this is not a significant challenge.

The final line of the document could potentially display the complete chain of embeddings, as suggested. I believe this is a necessary feature.

The question remains about the first line of the document.

In my opinion, there are two possible edge solutions, with everything in between being reasonable.

One option is to display only the information that the field is an embedded field, rather than simply indicating that it is a field (owned or not). This would provide a concise representation.

The other option is to display the complete chain of embeddings.

Of course, there may be limitations on the depth level of the embeddings, such as a maximum depth of 1, 2, or other predefined values.

However, I believe limiting the depth to the server side is not a good idea. Clients can shorten the embedding chain if necessary.

I am currently leaning towards the second option, which would display the complete chain of embeddings as follows:

field *B.A.V int

---

(mypkg.*B.A).V on pkg.go.dev

However, it may be acceptable to simplify the representation to the following:

embedded field V int

---

(mypkg.*B.A).V on pkg.go.dev

Apologies, I think I misunderstood earlier. Augmenting the hover information with the embedded representation would certainly be helpful. Please feel free to pick this up if you have any interest, I've added a help wanted label

Change https://go.dev/cl/662275 mentions this issue: gopls/internal/golang: add embedded struct info to hover