[DCOM-118] [GH-195] Add failing test to demonstrate parse error when @ is present in the description Created: 02/Oct/12 Updated: 03/Dec/13
|Reporter:||Benjamin Eberlei||Assignee:||Benjamin Eberlei|
This issue is created automatically through a Github pull request on behalf of Seldaek:
If someone can take this and fix the issue it'd be great. I couldn't figure it out at a quick glance and I don't really have time, but it's a pretty messed up bug and not so trivial to debug if you don't know what happens in the background so I'd say it's pretty important.
|Comment by Philipp Scheit [ 02/Oct/12 ]|
I digged a little deeper. The test case is a great one
So that the catchable pattern: ("(?:[^"]|"")*") matches here to greedy (it matches string in quotes):
As a result the lexer does not catch the correct @ from the Annotation
I could not think of a fast fix for this. But maybe tomorrow.
Its not a workaround to do more or less cutting in the parser, because not-well-formed quoted strings would break anyway
|Comment by Philipp Scheit [ 03/Oct/12 ]|
can someone think of a case, where a string (in some annotation) has a newline in it? Otherwise the tests do not fail, when I leave the string matching pattern with a newline.
but the second is not solvable with the lexer itself and would transfer the quoted string matching to the parser, because it needs context.
I'll let seldaek pull, what I have (is this the right way?)
|Comment by Marco Pivetta [ 03/Dec/13 ]|