Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 285120

Summary:

[parser] Parsing with backslashes failure

Product:

[Modeling] OCL

Reporter:

Laurent Goubet <laurent.goubet>

Component:

Core

Assignee:

Alexander Igdalov <alexander.igdalov>

Status:

CLOSED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

alexander.igdalov, ed

Version:

1.3.0

Keywords:

plan

Target Milestone:

3.0.0

Hardware:

All

OS:

All

Whiteboard:

Compliance

Attachments:

Description	Flags
Updated escaped sequences test containing the described examples	none

Description Laurent Goubet

2009-07-30 03:40:31 EDT

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

Comment 1 Alexander Igdalov

2009-07-30 09:57:00 EDT

Created attachment 143011 [details]
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.

Comment 2 Laurent Goubet

2009-07-30 11:00:21 EDT

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.

Comment 3 Alexander Igdalov

2009-07-30 13:36:04 EDT

(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.

Comment 4 Ed Willink

2009-07-30 15:25:40 EDT

+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.

Comment 5 Ed Willink

2009-10-01 14:52:22 EDT

Any plans to commit this?

Comment 6 Alexander Igdalov

2009-10-01 15:38:27 EDT

(In reply to comment #5)
> Any plans to commit this?

Yes. I am taking this bug.

Comment 7 Ed Willink

2009-10-30 15:51:04 EDT

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

Comment 8 Ed Willink

2011-05-27 02:48:20 EDT

Closing after over 18 months in resolved state.