Summary: | Compiler does not report end of line comment error | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Dani Megert <daniel_megert> |
Component: | Core | Assignee: | Olivier Thomann <Olivier_Thomann> |
Status: | VERIFIED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | philippe_mulet |
Version: | 2.0 | Keywords: | readme |
Target Milestone: | 2.1 M3 | ||
Hardware: | PC | ||
OS: | Windows 2000 | ||
Whiteboard: | |||
Bug Depends on: | |||
Bug Blocks: | 24744, 24833 |
Description
Dani Megert
2002-09-03 04:04:39 EDT
This would mean that we actually tokenize comments during regular parsing, but we don't. This could slow down the parser. In fact the bug is that the scanner is not reporting an error when a line comment is not closed with a line break (i.e. EOF is reached before a line break is found). Do we want to report this error only in JCK 1.4 mode? In case there is a line break after the line comment, is it supposed to be part of the line comment. If I have: // test\n Is the source of this comment "// test\n" or "// test"? >Do we want to report this error only in JCK 1.4 mode? I guess not only in JCK1.4 mode except you want to leave the bug in there for compatibility reasons (see Java Language spec 2nd ed.). >Is the source of this comment "// test\n" or "// test"? At least in the Java Language specification it is part of the comment It is trivial to modify the scanner to report an error when the line delimiter is not found behind the line comment. We need to change it too to include the line delimiters in its positions. Changed milestone. Fixing this problem has a bad side-effect on the formatter. So we need to be sure that the new formatter is ready prior to releasing any code. Fixed and released in 2.1 stream. Regression tests added. Verified. |