[GROOVY-10152] Parrot can't parse closure

• Type: Bug
• Status: Open
• Priority: Minor
• Resolution: Unresolved
• Affects Version/s: 3.0.8
• Component/s: parser-antlr4
• Assignee: Unassigned
• Reporter: Christopher Smith
• Created: 28/Jun/21 03:27
• Updated: 30/Dec/21 01:58

Description

I have this "cleanup" method in an ETL project. The intent is to call a static method returning Try<String> that attempts to normalize a phone number, then check whether we had an error processing any of them; if so, return a failure, but if success, replace the existing phone numbers with the normalized ones and return the record.

    static Try<IdentityRecord> normalizePhones(IdentityRecord record) {
        Map<String, Try<String>> normalized = record.phones.collectEntries { ctx, number ->
            [ctx, PhoneRules.normalize(number)]
        }

        return normalized.entrySet().stream()
            .filter { it.value.failure }
            .findFirst()
            .map { Try.failure(new ValidationException("${it.key}: ${it.value.cause.message}")) }
            .orElseGet {
                record.phones = normalized.collectEntries { ctx, tr -> ctx, tr.value }
                Try.success(record)
            }
    }

Parrot is giving me a generic parse error on the closure for the orElseGet call, and I can't figure out why. Commenting out the assignment statement removes the error (but of course prevents the intended modification). Adding _ -> does not change the error, and neither does inserting semicolons in various places.

Groovy:Unexpected input: '{'

Update: It appears that my attempted more-minimal workaround still triggers the problem:

    static void groovy10152(IdentityRecord record, Map<String, String> normalized) {
        normalized.collectEntries { ctx, tr -> ctx, tr.value }
    }

results in the same error at the opening of the closure:

Groovy:Unexpected input: '{'

(And now, finally, I am realizing that what's confusing it is the comma expression at the end. While this should be legal syntax and result in a type-checking error, it's causing a parser error instead. Even in this case, though, the grammar appears to be causing the error to be reported at a substantially incorrect location. Marking the priority down since fixing the semantic error also fixes the parser error.)