On 05.08.2017 14:58, sun...@apache.org wrote:
Repository: groovy Updated Branches: refs/heads/GROOVY_2_6_X edd461375 -> a6e5328f8 Refine the node position of path expression (cherry picked from commit 3b59585) Project: http://git-wip-us.apache.org/repos/asf/groovy/repo Commit: http://git-wip-us.apache.org/repos/asf/groovy/commit/a6e5328f Tree: http://git-wip-us.apache.org/repos/asf/groovy/tree/a6e5328f Diff: http://git-wip-us.apache.org/repos/asf/groovy/diff/a6e5328f Branch: refs/heads/GROOVY_2_6_X Commit: a6e5328f81c1580f943f7799f3f61635ffa34faf Parents: edd4613 Author: sunlan <sun...@apache.org> Authored: Sat Aug 5 20:54:56 2017 +0800 Committer: sunlan <sun...@apache.org> Committed: Sat Aug 5 20:58:03 2017 +0800 ---------------------------------------------------------------------- .../groovy/control/CompilerConfiguration.java | 4 ++++ .../transform/stc/DelegatesToSTCTest.groovy | 23 ++++++++++++++++++-- .../apache/groovy/parser/antlr4/AstBuilder.java | 6 ++--- 3 files changed, 28 insertions(+), 5 deletions(-) ---------------------------------------------------------------------- http://git-wip-us.apache.org/repos/asf/groovy/blob/a6e5328f/src/main/org/codehaus/groovy/control/CompilerConfiguration.java ---------------------------------------------------------------------- diff --git a/src/main/org/codehaus/groovy/control/CompilerConfiguration.java b/src/main/org/codehaus/groovy/control/CompilerConfiguration.java index 17ac7cf..8a0d26f 100644 --- a/src/main/org/codehaus/groovy/control/CompilerConfiguration.java +++ b/src/main/org/codehaus/groovy/control/CompilerConfiguration.java @@ -905,4 +905,8 @@ public class CompilerConfiguration { public void setBytecodePostprocessor(final BytecodeProcessor bytecodePostprocessor) { this.bytecodePostprocessor = bytecodePostprocessor; } + + public boolean isAntlr2Parser() { + return antlr2Parser; + } }
I think we should not have this method in a public API like CompilerConfiguration or at least make it deprecated from the start. Of course I am aware of us needing that information and that it would fit in this class best, but from the API side I would not want to introduce methods that hint for the specific technology used if possible. So I guess I would be also ok with some kind of parser version for example.
bye Jochen
