Uploaded image for project: 'Groovy'
  1. Groovy
  2. GROOVY-11402

STC: inferred type of this.name within closure

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • 3.0.21, 5.0.0-alpha-8, 4.0.21
    • 5.0.0-alpha-9
    • Static Type Checker
    • None

    Description

      Consider the following:

      class C extends HashMap<String,String> {
        private Object f = 'field'
        private static Object g = 'field'
        @groovy.transform.TypeChecked
        void test() {
          {->
            println      f // entry
            println      g // field
            println this.f // entry or field (if SC)
            println this.g // field
          }()
        }
      }
      new C().test()
      

      Fixes in Groovy 3 [1][3] and 4 [2][3] have made it so that "g" and "this.g" resolve to the static field (even from outer class). Groovy 5 has dropped this special case and should go through the closure's getProperty protocol (see GROOVY-10985). This is at least consistent with "g" and "this.g" appearing outside of a closure.

      However, "f" and "this.f" have some inconsistencies. "f" resolves to entry for STC and SC. "this.f" resolves to field at compile time for STC and SC. But to entry for STC and field for SC at run time. In Groovy 5, both "this.f" and "this.g" exhibit this difference.

      Should "this.f" be entry within closure as "f" is for all cases? Or should only the STC inferred type be fixed to match the run time behavior, leaving SC unchanged?

      GROOVY-5001, GROOVY-5491, GROOVY-8555, GROOVY-11367, GROOVY-11387, GROOVY-11401

      [1] https://github.com/apache/groovy/commit/419ce2f91754f101d8e65977da4dc7e8e6b6265f
      [2] https://github.com/apache/groovy/commit/3c2266e053c4a9a9127be43921afb0c5135725f6
      [3] https://github.com/apache/groovy/commit/da99cd99e4fd3f4c8084622a07cb93dd4e388653

      Attachments

        Activity

          People

            emilles Eric Milles
            emilles Eric Milles
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: