4 was a clean, expedient fix for the common problem in #3, but it introduced a known issue: any line of non-tag text, or any "description" following a tag, that starts w/ a backslash (\) will cause parse issues. At this time, I suspect that this is a relatively niche issue (though it is not a non-issue) that we can tackle later, if/when it's reported.
For example, a file like https://github.com/drupal/drupal/blob/9.4.x/core/lib/Drupal/Core/Config/ConfigEvents.php includes a number of docblocks with lines that happen to start w/ a \ as part of a global qualified namespace. These will result in parse errors. The upside is that these are relative minor: tree-sitter will recover quickly and the rest of the lines will be parsed correctly. I'm also assuming that it's unlikely that anyone will specifically be needing to pull the specific text nodes from these cases. (The description nodes should still be intact in most cases.)
Another funny case is something like this:
/**
* @return int \Fully\Qualified\Name would be better, but we're stuck w/ int
*/
In this case, the parser seems want to want to combine the int w/ the FQN. Here again, I'm making the assumption that cases like this are going to be relatively rare and we can work out a better fix when it's reported.
4 was a clean, expedient fix for the common problem in #3, but it introduced a known issue: any line of non-tag text, or any "description" following a tag, that starts w/ a backslash (
\
) will cause parse issues. At this time, I suspect that this is a relatively niche issue (though it is not a non-issue) that we can tackle later, if/when it's reported.For example, a file like https://github.com/drupal/drupal/blob/9.4.x/core/lib/Drupal/Core/Config/ConfigEvents.php includes a number of docblocks with lines that happen to start w/ a
\
as part of a global qualified namespace. These will result in parse errors. The upside is that these are relative minor:tree-sitter
will recover quickly and the rest of the lines will be parsed correctly. I'm also assuming that it's unlikely that anyone will specifically be needing to pull the specifictext
nodes from these cases. (Thedescription
nodes should still be intact in most cases.)Another funny case is something like this:
In this case, the parser seems want to want to combine the
int
w/ the FQN. Here again, I'm making the assumption that cases like this are going to be relatively rare and we can work out a better fix when it's reported.