[parser] Parsing with backslashes failure

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 285120 | | Status | CLOSED FIXED | | Importance | P3 normal | | Reported | Jul 30, 2009 03:40 EDT | | Modified | May 27, 2011 02:48 EDT | | Version | 1.3.0 | | Reporter | Laurent Goubet |

Description

bug #242880 enabled clients to activate an option allowing for the use of control characters within OCL Strings. Among the valid escapes is the simple quote : \', yet it seems that the parser doesn't take into account what comes before the escape.

In other words :\ '\\ ' can be parsed and compiles even though one of the backslashes isn't escaped and AFAIK "\ " isn't a valid escape.\ '\' cannot be parsed as the parser thinks the closing quote is escaped

[eclipse-ocl-bot]

By Alexander Igdalov on Jul 30, 2009 09:57

Created attachment 143011 Updated escaped sequences test containing the described examples

Hi Laurent,

I have checked escaped sequences in the interpreter console example - it doesn't seem to recognize backslashes. We should fix this in the console example. However, '\\ ' and '\' seem to be correctly handled by the OCL engine. Please make sure you are running the parser with ParsingOptions.USE_BACKSLASH_ESCAPE_PROCESSING option set to true. I have modified the BasicOCLTest.test_escapeSequences_242880 test (see attached patch) so that it includes the samples you describe. It passes successfully in my workspace.

:notepad_spiral: patch_example_for_285120.txt

[eclipse-ocl-bot]

By Laurent Goubet on Jul 30, 2009 11:00

Aleksandr,

I did set this option to true, and indeed the OCL parser and engine seem to both handle these correctly ... which would mean the issue lies within my plugin :p.

As a side note, '''' results in ''' ... how come (and that's with the OCL interpreter, not from my plugin :p)?

I can raise another bug for this second issue if you'd rather.

[eclipse-ocl-bot]

By Alexander Igdalov on Jul 30, 2009 13:36

(In reply to comment #2)

As a side note, '''' results in ''' ... how come (and that's with the OCL interpreter, not from my plugin :p)?

This was done on purpose in 1.3.0 to be compatible with the SQL-like escaping of single quotes, i.e. a string literal 'It''s a string' gives 'It's a string' value. So in 1.3.0 such behaviour is correct. However, this can be toggled in extending languages. See AbstractOCLParser.isNonStdSQSupported(). QVTO, for example, doesn't support this type of escaping.

I can raise another bug for this second issue if you'd rather.

Yes, I think it's a good idea to get aligned with QVTO here (which explicitly describes escaping in its specification). I suppose that in the new implementation we can afford such an API breakage.

[eclipse-ocl-bot]

By Ed Willink on Jul 30, 2009 15:25

+1 for the patch.

The QVTo text should be submitted as a resolution-formatted OCL Issue to OMG so that we can justifiably treat it as plausible future OCL functionality.

[eclipse-ocl-bot]

By Ed Willink on Oct 01, 2009 14:52

Any plans to commit this?

[eclipse-ocl-bot]

By Alexander Igdalov on Oct 01, 2009 15:38

(In reply to comment #5)

Any plans to commit this?

Yes. I am taking this bug.

[eclipse-ocl-bot]

By Ed Willink on Oct 30, 2009 15:51

I accidentally committed this with one of my own fixes on 7-Oct-2009.

[eclipse-ocl-bot]

By Ed Willink on May 27, 2011 02:48

Closing after over 18 months in resolved state.