groovy

Method call expression parsed differently in 1.8 compared to 1.7

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Blocker Blocker
  • Resolution: Fixed
  • Affects Version/s: 1.8.0, 1.8.1, 1.9-beta-1
  • Fix Version/s: 1.8.4, 2.0-beta-1
  • Component/s: parser-antlr
  • Labels:
    None
  • Number of attachments :
    0

Description

Some method call expressions are parsed differently in 1.8 compared to 1.7. This causes one of Gradle's AST transforms to fail. According to Jochen, this looks like a bug in the 1.8 ANTLR grammar.

task copy(type: Copy) { x = 10 }
g1.7: this.task(this.copy(...))
g1.8: this.task(this.copy(...))

task copy(type: Copy) { println 10 }
g1.7: this.task(this.copy(...))
g1.8: task.copy(...)

The first expression is parsed the same in 1.7 and 1.8, but the second expression is parsed differently.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Guillaume Laforge added a comment -

Another similar problem reported to me by Roshan, in Grails' url mappings:

name xxx: "/c/$authCode"(controller: 'foo', action: 'bar') {
    constraints {
        authCode blank: false
    }
}
Show
Guillaume Laforge added a comment - Another similar problem reported to me by Roshan, in Grails' url mappings: name xxx: "/c/$authCode" (controller: 'foo', action: 'bar') { constraints {     authCode blank: false } }
Hide
Permalink
Guillaume Laforge added a comment -

And as a workaround for now, putting back the parentheses make things work:

name(xxx: "/c/$authCode"(controller: 'foo', action: 'bar')) {
    constraints {
        authCode blank: false 
    }
}
Show
Guillaume Laforge added a comment - And as a workaround for now, putting back the parentheses make things work: name(xxx: "/c/$authCode" (controller: 'foo', action: 'bar')) { constraints { authCode blank: false } }
Hide
Permalink
blackdrag blackdrag added a comment -

the reason for the bug was not because of a wrong or grammar rule, it was because of some semantic action executed only in certain cases, that was causing this. Took a while, but seems to be fixed now

Show
blackdrag blackdrag added a comment - the reason for the bug was not because of a wrong or grammar rule, it was because of some semantic action executed only in certain cases, that was causing this. Took a while, but seems to be fixed now

People

  • Assignee:
    blackdrag blackdrag
    Reporter:
    Peter Niederwieser
Vote (0)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved: