GDScript: Add error when exporting node in non Node-derived classes

[dalexeev]

• Closes When using a Node exported through a Resource, you can not listen to its signals. #82809.
  • Display an error when trying to export a node in a non Node-derived class.
• Extends the @export annotation documentation.
• Rename p_node to p_target so .cpp matches .h.

[adamscott]

Looks nice!

[akien-mga]

Thanks!

[aaronfranke]

parser->head is a ClassNode *, so this line should be:

E->apply(parser, parser->head, parser->head);

I have added a fix for this to #67777.

[dalexeev]

No, p_class is the class that p_target is in. The root class is not in any other class. This is a subtle detail, but for example if an annotation is applied to an inner class (we don't have such a case right now), then p_target will be the class, and p_class will be its outer class. Therefore, if you do not need the context class, then it is important to use p_target rather than p_class, even this requires static_cast.

[aaronfranke]

Thanks, I missed that detail before. I've updated my PR and add a comment in the abstract annotation apply method for why we are using p_target instead of p_class.

Maybe p_class should be renamed to p_in_class? Since it's the class the target is in.

[YuriSizov]

Just a small note: if we are referring to some unspecified limitations, we should link to some place that explains what those are. Do we have an article that goes into such detail about Node exports?

[dalexeev]

Just a small note: if we are referring to some unspecified limitations, we should link to some place that explains what those are. Do we have an article that goes into such detail about Node exports?

Fair point. I remember that there are issues with exporting nodes in @tool mode, but I'm not sure about other issues, which of them are limitations and which are bugs. So I left room for interpretation. I wanted to warn that exporting nodes is less stable than exporting node paths and may not work in non-standard scenarios.