An extra brace (curly bracket) or parenthesis at the top level , will terminate umple code processing

[TimLethbridge]

In the following example

class X {}}
  thisIsIgnored;
}

class WholeClassIsIgnored {
}

... the extra closing brace will terminate all subsequent processing of input. That means that if anyone accidentally has one more closing brace than opening one at any point in their code, then code will be ignored and this may be very hard to debug.

Somehow the parser should detect the extra closing brace and raise an error message at that point.

[TimLethbridge]

An extra opening brace has the same effect.

Adding a grammar rule (and processing in UmpleInternalParser_CodeClass.ump) to catch an loose braces and raise new error messages (e.g. 1504) at the top level seemed to have no effect, yet broke certain code in the RealTimeCPP generator.

Perhaps the answer would be to determine if there are characters not processed beyond the end of parsing, and if so raise an error message.

[TimLethbridge]

we discovered that any { or } or {} ot () or ( or ) will terminate processing

I suggest trying to match these using a regex in line 14 of umple_core.grammar and then detecting that in class/UmpleInternalParser_CodeClass.ump and calling setFailedPosition with a new warning in en.error

We already added the message to branch issue2023curlybracket so use that branch

[TimLethbridge]

I give a 60% chance that we could follow the following approach.

1. Modify the grammar rule umpleProgram. Change it so that at the top level, in addition to a comment or a directive or a semicolon (any of which can be interleaved), a new [invalidBracket:{|}|(|)] could be present. This might need to instead be specified using a regular expression [!invalidBracket:XXXX] where XXXXX would be the regex.

2. Then in the umpleInternalParser code we would detect the presence of an invalidBracket, issue a warning and ignore it.

3. We would want to add test to demonstrate that the warning is detected.

If that doesn't work, we may have to dig deeper.

[TimLethbridge]

New suggestion: Look for malformedStatement processing in the umple_exceptions.grammar. Consider the extra brackets as a new type of maformed statement. Create a regex to match, and then process the resulting rule (which would be near class/UmpleInternalParser_CodeClass.ump:5640: ... note that all you need to do is to output a warning)

[AxelTWC]

Created PR which detects open and close (round and curly brackets). Next step is to create test cases and write the user manual for the warning.

[AxelTWC]

The new PR merged has the following information:

PR #2049

This code currently raises a warning and detects the following Extra Brackets:

• OPEN_ROUND_BRACKETS
• CLOSE_ROUND_BRACKETS
• OPEN_CURLY_BRACKETS
• CLOSE_CURLY_BRACKETS
  and outputs the warning number 1016.

In order to remove the warning, the user would need to look at the warning message showing the line number of the extra bracket.

Note

For Developers, Quick Build the Compiler twice as there is an edit in the Umple Internal Parser Code.
Multiple Test Cases has been added to test and solve this issue.
An extra user manual guideline has been added to show how to reproduce this warning and how to solve the warning.

[TimLethbridge]

Fixed by #2057 and #2049