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

Provide a mechanism to prioritise AST transforms running at the same stage

Details

    • Improvement
    • Status: Closed
    • Major
    • Resolution: Fixed
    • None
    • 4.0.0-rc-1
    • None
    • None

    Description

      Overview

      As compilation proceeds, the compiler's data structures typically gain additional information as the various parts of the compiler enrich that data. Ideally, AST transforms should be invoked once all of the compiler mdata they need is ready. However, the order of processing becomes a secondary factor in determining what phase a transform will run.

      AST Transforms target a particular phase with transforms in earlier phases running first. For transforms in the same phase, the order they appear in the source code determines which ones run first. If framework writers rely on certain transforms to run first, they might delay some transforms to later stages. This places additional constraints on framework writers which are further compounded when using annotation collectors (meta-annotations) since they list component transforms in a particular order.

      This issue is to allow framework developers some ability to order transforms in the same phase using a priority. Transforms with a higher priority (determined by an integer value) run first.

      If no priority is given, a priority of 0 is assumed. Transforms with the same priority run in the order in which they appear. To make a transform run before others, give it a higher positive value. A negative priority will send the transform to the end of the list. AST transforms need to implement the TransformWithPriority interface if they want to alter their priority. Positive values will run ahead of those with priority 0 which run ahead of those with negative priorities. Transforms typically run after all of the inbuilt compiler steps have been undertaken. This behavior hasn't changed, just the order within the normal AST transformation processing steps is potentially changed.

      Out of Scope

      • Widescale changing many of the internal Groovy transforms away from the default priority of 0 (TupleConstructor has a slightly raised priority so that constructors it creates will be available to other transforms also at the same phase)
      • Any mechanism for negotiating priority between frameworks (frameworks can choose how they assign priorities)
      • Any mechanism for end users to alter the priority (it is baked into the AST transform definition not usage of the transform annotation)

      Attachments

        Activity

          paulk Paul King added a comment -

          Proposed PR merged.

          paulk Paul King added a comment - Proposed PR merged.
          emilles Eric Milles added a comment -

          Is there any concern that once this is out there for a while, you'll have priority 1 and 2 xforms and then someone needs theirs to go in between?  Is using a float a step too far?  Is there docs or rule-of-thumb to use certain numbers so that there are gaps, like in BASIC line numbers would typically be incremented by 10.

          emilles Eric Milles added a comment - Is there any concern that once this is out there for a while, you'll have priority 1 and 2 xforms and then someone needs theirs to go in between?  Is using a float a step too far?  Is there docs or rule-of-thumb to use certain numbers so that there are gaps, like in BASIC line numbers would typically be incremented by 10.
          paulk Paul King added a comment -

          If I was a framework choosing my priorities I would indeed follow a scheme like used in early BASIC programming. Indeed, we used priority 5 rather than say 1 for TupleConstructor. I have had several frameworks ask me for this facility (some have rolled their own in various forms in previous times). Having said that, I am not sure we need to document any rule-of-thumb but rather leave that up to frameworks to decide. Depending on what schemes they use, they might want to give advice to their AST transform/plugin writers. If in core Groovy, we start using them more, we should probably then include some more guidance. I have yet to augment the release notes/doco about priorities but I will do so soon.

          paulk Paul King added a comment - If I was a framework choosing my priorities I would indeed follow a scheme like used in early BASIC programming. Indeed, we used priority 5 rather than say 1 for TupleConstructor . I have had several frameworks ask me for this facility (some have rolled their own in various forms in previous times). Having said that, I am not sure we need to document any rule-of-thumb but rather leave that up to frameworks to decide. Depending on what schemes they use, they might want to give advice to their AST transform/plugin writers. If in core Groovy, we start using them more, we should probably then include some more guidance. I have yet to augment the release notes/doco about priorities but I will do so soon.

          People

            paulk Paul King
            paulk Paul King
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0h
                0h
                Logged:
                Time Spent - 20m
                20m