Inconsistency on the rules for multi line comments and syntax highlighting
joseluis opened this issue · 9 comments
The issue is that no Dart syntax highlighter seems to be treating the multi-line comments as nestable, which in Dart they are by spec. Example:
void main() {
print(1);
/*
print(2);
///* <--- This multi-line opening mark
consumes this closing mark --> */
/* The same happens in this case */
print(3);
*/ // <--- this isn't syntax highlighted, but is necessary for the current interpreter to work
print(4);
}I've confirmed it in dartpad, in vim plugin, and in GitHub, as the example above shows.
EDIT1:
Other languages with the same type of multi-line comments /* */ ignore every subsquent opening mark /* after the first one, up until the first closing mark */ is found. But Dart does not do that.
Dart seems to nest multi-line comments, treats them like if it were brackets or parenthesis, which really doesn't make sense, and it can derive in confusion and frustration.
I believe this choice is not made in purpose, since the syntax highlighter is not aware of it.
The above example prints 1 and 4 and exits gracefully, but it should fail because of the last closing mark. When that line is removed, it should print 1 and 3.
EDIT2
I want to link to this Interesting discussion about the reasons for not including nested comments in Go: golang/go#54 . It's funny how different the decisions can be, coming both languages from Google.
http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-408.pdf 20.1.2
It's intentional (see last sentence in this paragraph).
A multi-line comment begins with the token /* and ends with the token /.
Everything between / and */ must be ignored by the Dart compiler unless the
comment is a documentation comment. Comments may nest.
Actually I prefer it that way.
Comments may nest.
Good find. I miss the reason for it to work that way though, I can image to have something to do with a simpler or more efficient parser.
In anycase if this is intentional then the bug is in the Dart syntax highlighter rules implementation.
Actually I prefer it that way.
I prefer if they don't nest, because that doesn't really serve any practical purpose for the programmer, and it prevents the use of /**/ which is a versatile mark, able to stop any previous multi-line comment, and when there's none, then it does nothing.
I like to use them when debugging for quickly comment / uncomment blocks of code, but this doesn't work in Dart:
/*
// commented out
/**/
// working block of code
/**/
I find it annoying when I want to comment out a larger block of code (for example during refactoring) that contains comments and then have to modify each multiline comment start and end in between to not end the new comment block.
I run into this a lot when I migrated JS code to Dart and commented out larger blocks of code because they weren't relevant at that stage of migration to get rid of the noise the analyzer produces because of all the invalid JS code in Dart files and to be able to run the code already during migration.
I understand, that's a very good practical use of nesting comments indeed, and in fact more useful than my use case, so I stand corrected. And now that I know what to search for, it appears this is well documented.
It still remains the issue of the syntax highlighter, which I believe should match the real rules.
I agree with syntax highlighter.
Neither dartpad not GitHub use the analyzer to do syntax highlighting. I'm not sure about the vim plugin, but I suspect that it doesn't either. I don't know how the others work, but dartpad uses the codemirror support for highlighting.
I tried the example in IntelliJ and it works correctly. As a result I'm reasonably certain that analyzer is working correctly.
Just FYI. Lexer-level highlighting (literals, comments, keywords, etc.) in IntelliJ IDEA is performed without using Analysis Server. I'm glad it works correctly with nested comments. I can confirm that Analysis Server handles them correctly as well.
Actually, I knew that :-) I was basing my conclusion on other things, like the absence of navigation, etc.