if (UnderlyingNode is null)

It feels like all individual code paths in this function should have dedicated code coverage. That should include both positive and negative outcomes, when applicable. Also, I have to admit, I am not an expert in this area, and, at the moment, I do not have a good idea about how expected implementation should actually look like. Therefore, it would be good to provide an explanation why this is the right implementation. If the logic was "copied" from some other place, it would be good to mention that as well. #Closed

When I copied this logic I was not able to come up with a test for the scenario where there is no syntax tree, but the underlying green node exists. After thinking about it for a while I managed to find the case: when parsing trivia via SyntaxFactory.Parse[Leading|Trailing]Trivia we get precisely this scenario, so added tests for both branches (where we have diagnostics and where we don't)

any problem keeping the logic directly equivalent to SyntaxToken? like line for line. In other words, looking like:

            if (UnderlyingNode == null)
            {
                return SpecializedCollections.EmptyEnumerable<Diagnostic>();
            }

            var tree = SyntaxTree;

            if (tree == null)
            {
                var diagnostics = UnderlyingNode.GetDiagnostics();

                return diagnostics.Length == 0
                    ? SpecializedCollections.EmptyEnumerable<Diagnostic>()
                    : diagnostics.Select(s_createDiagnosticWithoutLocation);
            }

            return tree.GetDiagnostics(this);

Where should we extract this logic? Is there a good existing helper class for such things?

feels like it could all be on SyntaxTree. It just needs a GreenNode+pos to be able to operate.

The VB part also needs to know whether the node/token is in doc comments section, for which it walks the tree upwards from the given node, which is not available for green nodes. I mean we can extract the "getting diagnostic from the tree" part into a delegate, but that will make code more complex, introduce allocation of a delegate etc

My primary feedback was really just to keep the code written the same way. It's ok to still have the duplicated impl.

My primary feedback was really just to keep the code written the same way. It's ok to still have the duplicated impl.