Unhelpful error message when a parameter is mis-specified

bgrommes

Given this incorrect parameter declaration:

fragment1 As String, fragment2 As String, fragment 3 As String

... one gets the error message "Expected module member declaration." Also it's on the 3rd line of the method (lines 1-3 all have code, no comments or empty lines). Line 1 references fragment3 (without the space) and produces no error.

The same error also repeats on 7 other lines of this 16 line routine.

This is not pointing me to the problem other than that I can deduce something on or prior to line 3 must not be compiling. Naturally I am looking in the code for this and not in the method definition (especially if the definition is collapsed). I mean, I should be, but I'm used conceptually to the whole method being in its own code block that I can look at along with the method body. Call it "brain muscle memory" I guess.

Furthermore, removing the space from "fragment 3" doesn't make the errors go away. Switching away and back and they're still there. Run Analyser and the errors are gone but the gutter markers remain until you click within the method editor.

My suggestion is that it would be great if Objo could report errors in parsing the parameter definition before bothering to even try compiling the method body, and maybe put a marker before the "Parameters:" textbox, or something of that nature.

Garry

Thanks for the detailed report. This has now been fixed for the next release: https://feedback.objo.dev/bug/896

There were two separate problems involved.

First, the parameters field was accepting malformed text such as "fragment 3" and inserting it into the method declaration. When the compiler encountered that declaration, its error recovery lost track of the method boundary and consequently treated lines from the method body as module members. That caused the repeated and misleading “Expected module member declaration” errors.

The parameters field is now validated using the compiler’s own parameter grammar. Invalid text remains in the field so it can be corrected, but it is not written into the project. Studio displays the error beside the field and also shows an error indicator in the method header when the metadata panel is collapsed.

The resulting message for this example now explains that parameter names cannot contain spaces and that parameters must be separated with commas.

I 've also improved compiler recovery. If a malformed method declaration is encountered in existing source, the compiler now skips to the matching End Sub, End Function, or equivalent terminator instead of reporting errors against each line of the body.

Finally, method metadata edits now trigger the same live-diagnostics refresh as code edits. Correcting the parameters field therefore removes the old errors and gutter markers immediately, without requiring Analyse or an extra click in the editor.

Thanks again. The reproduction details made all three parts of the problem straightforward to identify.

bgrommes

Garry Wonderful! Thanks gain, Garry.

Garry

You're very welcome 🙂