Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.
SRP Precompiler Error Using /**/ Multiline Comments with "Service" Keyword
in SRP Editor
With the #pragma precomp SRP_PreCompiler directive near the start of my
program, if I follow with a multiline comment as used in C (and B before
that, and apparently PL/I before that), the "Service" keyword inside the
comment fails compilation. As an example, the following program gives
three errors :
Removing the rest of the line ("[in] -- Name of the service being requested")
after the "Service" keyword removes the errors. One can retain the rest of
the line by adding a visible character (such as "@) before the keyword.
Or if "Service" is alone on a line, or surrounded only by whitespace, the
code also compiles.
The bug is linked to the GoToService statement, because removing that
statement also removes the errors. And placing the directive after any
offending multiline comments also allows the program to compile.
But is there any chance of improving the parser, which ought to ignore
everything inside a comment?
program, if I follow with a multiline comment as used in C (and B before
that, and apparently PL/I before that), the "Service" keyword inside the
comment fails compilation. As an example, the following program gives
three errors :
function Test_Services(@Service, @Params)
#pragma precomp SRP_PreCompiler
/*
...
Parameters:
Service [in] -- Name of the service being requested
Params
...
*/
GoToService else
* error-handling code here
end
Return Response OR ''
service TestService()
* service code here
end service
Removing the rest of the line ("[in] -- Name of the service being requested")
after the "Service" keyword removes the errors. One can retain the rest of
the line by adding a visible character (such as "@) before the keyword.
Or if "Service" is alone on a line, or surrounded only by whitespace, the
code also compiles.
The bug is linked to the GoToService statement, because removing that
statement also removes the errors. And placing the directive after any
offending multiline comments also allows the program to compile.
But is there any chance of improving the parser, which ought to ignore
everything inside a comment?
Comments
SRP Editor version: 3.3.8.2
Build: 2/17/22 11:13AM
SRPEditor.ocx: 3.3.8.2
If you still think it worthwhile to look closer, Opto is over 300 MB compressed. Is there a way to upload it?
If you don't find a local application version, open $SRP_PRECOMPILER, go to the bottom of the record, highlight the internal datetime stamp, and right click to show the Oconv DateTime. Mine looks like this:
Let me know what datetime yours is.
Removing this version eliminated the errors. Now I know somewhere else to look before posting an outdated bug report to the forum.
Thank you! I would not have solved this one in a month of Sundays.
@DonBakke, You and I diagnosed an issue back in mid-2020 (archived-version-srputilities-1-6-1#latest) where it became clear that we had SRP debug code throughout the system once upon a time. It stands to reason that, for whatever purpose that was, we didnt give our system as full cleanout as we should have. Maybe it had creeped in there and never left?