Bug #7438
the label in the UNDO <lbl>, THROW is not validated or used in 4GL
100%
History
#2 Updated by Constantin Asofiei 11 months ago
This simple line compiles and executes fine in 4GL:
undo bogus, throw new progress.lang.apperror("a").
The FWD parse will still try to validate the label as existing; but instead, this needs to be dropped.
#4 Updated by Constantin Asofiei 11 months ago
Greg Shah wrote:
Is this really a parsing issue? Maybe
label_referencedetects this as amalformed_symbolbut it isn't clear that this is a problem.
I did not investigate further - FWD parser fails when encountering a 'bogus' label (which is not defined at previous parent block).
I would think most of the issue is about avoiding downstream TRPL processing for this case.
The TRPL patch just ensures the label is not emitted, ever, in the converted source. From what I see in customer code, the label for UNDO, THROW is not specified, anyway, but I can't say for sure, as I haven't ran a report on the full conversion ASTs.
A 4GL developer for sure has other instincts than mine when programming 4GL, but for me, the tests started by trying to make UNDO, THROW target a block further in the hierarchy - all behavior was the same in 4GL, until I tried with a 'bogus' label.
#6 Updated by Constantin Asofiei 11 months ago
Greg Shah wrote:
all behavior was the same in 4GL, until I tried with a 'bogus' label
You mean this was the case after your changes in 7300a?
No, I mean I couldn't understand the behavior of 4GL until I found that the label has no meaning for UNDO, THROW - after that, things started making sense.
#8 Updated by Constantin Asofiei 11 months ago
Greg Shah wrote:
The label never has meaning?
Correct - it has no meaning, either for the 4GL compiler or the 4GL runtime. The label just gets discarded. No matter where UNDO, THROW is called from, or what the target is.
#9 Updated by Constantin Asofiei 11 months ago
- Status changed from New to Review
- Assignee set to Constantin Asofiei
- % Done changed from 0 to 100
This patch solves the issue; I don't see a more elegant solution.
=== modified file 'src/com/goldencode/p2j/uast/progress.g'
--- old/src/com/goldencode/p2j/uast/progress.g 2023-05-01 10:29:36 +0000
+++ new/src/com/goldencode/p2j/uast/progress.g 2023-06-15 14:32:57 +0000
@@ -24898,7 +24898,8 @@
// unreserved keywords which exists to "pull" us into this
// rule, but when we leave the type is always reset to LABEL
// OR we throw an exception
- | { proper || mal }?
+ // for UNDO, THROW, we must allow matching the label name, regardless if it exists or not
+ | { proper || mal || LA(3) == KW_THROW}?
malformed_symbol
| // empty alternative
@@ -24912,6 +24913,12 @@
{
int newtype = sym.lookupLabel(##.getText());
+ if (newtype == -1 && LA(2) == KW_THROW)
+ {
+ // bogus label for UNDO, THROW
+ newtype = LABEL;
+ }
+
// there should always be a match in valid Progress 4GL source
// so we throw an exception if this is not the case
if ( newtype != -1 )
If it looks OK, I can commit it to 7300a.
#10 Updated by Constantin Asofiei 11 months ago
The patch above does not drop the label, but instead 'forces it' even if it can't be resolved, to preserve the AST structure as it was. The TRPL changes in control_flow.rules will drop it.
#12 Updated by Constantin Asofiei 11 months ago
Committed to 7300a rev 14626.