[jira] [Commented] (GROOVY-7647) Incorrect line information for debug
[
https://issues.apache.org/jira/browse/GROOVY-7647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16696417#comment-16696417
]
ASF GitHub Bot commented on GROOVY-7647:
GitHub user paulk-asert opened a pull request:
https://github.com/apache/groovy/pull/830
GROOVY-7647: Incorrect line information for debug
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/paulk-asert/groovy groovy7647
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/groovy/pull/830.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #830
commit ae3bb53f64396f9b95fa7f592397b11542397ee9
Author: Paul King
Date: 2018-11-23T06:29:06Z
GROOVY-7647: Incorrect line information for debug
> Incorrect line information for debug
>
>
> Key: GROOVY-7647
> URL: https://issues.apache.org/jira/browse/GROOVY-7647
> Project: Groovy
> Issue Type: Bug
> Components: class generator, Compiler
>Affects Versions: 2.4.5
>Reporter: Egor Ushakov
>Priority: Major
>
> Try to debug the code:
> {code}
> boolean boolVar = false; //line 15
> if (boolVar) { // set breakpoint here and step over //line 16
> print "ok"; //line 17
> } // end of file //line 18
> {code}
> It steps over to the line with print even though it is not executed.
> Seems that compiler does not generate line info for the last block (line 18):
> {code}
> public java.lang.Object run();
> descriptor: ()Ljava/lang/Object;
> flags: ACC_PUBLIC
> Code:
> stack=3, locals=3, args_size=1
> 0: invokestatic #18 // Method
> $getCallSiteArray:()[Lorg/codehaus/groovy/runtime/callsite/CallSite;
> 3: astore_1
> 4: iconst_0
> 5: istore_2
> 6: iload_2
> 7: pop
> 8: iload_2
> 9: ifeq 28
> 12: aload_1
> 13: ldc #41 // int 1
> 15: aaload
> 16: aload_0
> 17: ldc #43 // String ok
> 19: invokeinterface #47, 3 // InterfaceMethod
> org/codehaus/groovy/runtime/callsite/CallSite.callCurrent:(Lgroovy/lang/GroovyObject;Ljava/lang/Object;)Ljava/lang/Object;
> 24: areturn
> 25: goto 30
> 28: aconst_null
> 29: areturn
> 30: aconst_null
> 31: areturn
> LocalVariableTable:
> Start Length Slot Name Signature
> 0 30 0 this Lsdfklajsdlkjas/test;
> 6 24 2 boolVar Z
> LineNumberTable:
> line 15: 4
> line 16: 8
> line 17: 12
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] groovy pull request #830: GROOVY-7647: Incorrect line information for debug
GitHub user paulk-asert opened a pull request: https://github.com/apache/groovy/pull/830 GROOVY-7647: Incorrect line information for debug You can merge this pull request into a Git repository by running: $ git pull https://github.com/paulk-asert/groovy groovy7647 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/groovy/pull/830.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #830 commit ae3bb53f64396f9b95fa7f592397b11542397ee9 Author: Paul King Date: 2018-11-23T06:29:06Z GROOVY-7647: Incorrect line information for debug ---
[jira] [Commented] (GROOVY-8882) CS: Loop over elements of String has different element type
[
https://issues.apache.org/jira/browse/GROOVY-8882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16696274#comment-16696274
]
Paul King commented on GROOVY-8882:
---
For consistency, I think the proposed change is the only one we can consider.
We'd like the internal and external iterator approaches to have similar
behavior and both dynamic Groovy and CS use String for the internal iterators.
Additional detail: InvokerHelper.asIterator() on a String returns an iterator
of String, so String is used as the parameter type for:
each, eachWithIndex, any, every, count, collect, find, findAll, findResult,
grep, retainAll, removeAll, split, inject, findIndexOf, findLastIndexOf,
findIndexValues, etc.
> CS: Loop over elements of String has different element type
> ---
>
> Key: GROOVY-8882
> URL: https://issues.apache.org/jira/browse/GROOVY-8882
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.4.15
>Reporter: Eric Milles
>Assignee: Paul King
>Priority: Minor
> Labels: breaking
>
> When the method below is executed as-is, the output is "java.lang.String" x3.
> When {{@CompileStatic}} is uncommented, the output is "java.lang.Character"
> x3. Is it possible to have dynamic groovy match the static compilation
> result?
> {code:groovy}
> //@groovy.transform.CompileStatic
> void meth() {
> for (c in 'abc')
> println c.class.name
> }
> {code}
> Similarly, {{'abc'*.anything}} applies to Strings of length one instead of
> Characters. Although, spread-dot is not supported against strings under
> static compilation. Is it possible to add that support?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8863) Groovy compiler doesn't generate InnerClasses attribute for nested class names mentioned in the class file
[
https://issues.apache.org/jira/browse/GROOVY-8863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16696259#comment-16696259
]
Paul King commented on GROOVY-8863:
---
I had a quick look at this. I did a quick spike to see if we could hack
AsmClassGenerator. I added an additional call to cv.visitInnerClass within the
places which use types: visitField, visitConstructorOrMethod for params,
visitStdMethod for return type, visitCastExpression, visitClassExpression,
visitAnnotationDefaultExpression for class constants. Doing it this way is a
kind of a hack since we don't record such usages in earlier visitor passes.
This worked in most cases but still broke a bunch of tests. I wasn't setting
the access modifiers properly (limitation of spike) which explains some of the
breakages but others broke due to loss of information in the classnode. Inner
classes aren't identified correctly as InnerClassNodes by ClassSignatureParser.
My hack used a simplistic approach of looking for $ in the class name. This
would need to be made quite a bit smarter for the hack approach to work to
account for inner inner classes, closures in classes, local inner classes etc.
To me it indicates that we should fix the loss of information during class
resolution.
> Groovy compiler doesn't generate InnerClasses attribute for nested class
> names mentioned in the class file
> --
>
> Key: GROOVY-8863
> URL: https://issues.apache.org/jira/browse/GROOVY-8863
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 2.5.3
>Reporter: Alexander Udalov
>Priority: Major
>
> It seems that the Groovy compiler does not generate correct InnerClasses
> attributes when Groovy code uses inner classes, even if those are Java
> classes compiled separately.
> For example, the following code:
> {{class Test {}}
> {{ void f(Thread.State t) {}}}
> {{}}}
> (where java.lang.Thread.State is just an example nested class from JDK) will
> compile by Groovy to a class file Test.class which has no InnerClasses
> attribute. If compiled by Java though, it has the following:
> {{InnerClasses:}}
> {{ public static final #10= #9 of #18; //State=class
> java/lang/Thread$State of class java/lang/Thread}}
> While I couldn't find a statement requiring this attribute to be present for
> all nested classes mentioned in the class file in the JVMS, I believe
> [§4.7.6|https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.7.6]
> sort of hints at that with the following:
> {quote}If the constant pool of a class or interface C contains at least one
> {{CONSTANT_Class_info}} entry
> ([§4.4.1|https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1])
> which represents a class or interface that is not a member of a package,
> then there must be exactly one {{InnerClasses}} attribute in the
> {{attributes}} table of the {{ClassFile}} structure for C.
> {quote}
> In this case, there's certainly a CONSTANT_Class_info entry in the
> Groovy-generated class file which represents a non-top-level class, but the
> InnerClasses attribute is missing, so I'd say this violates the spec.
> We've met this issue when refactoring the internal implementation of class
> file reader in the Kotlin compiler, where we [got
> rid|https://github.com/JetBrains/kotlin/commit/9df02b236620e413ef70cea0d1d8ed93cd0b474e]
> of the heuristic that calculated the full class name by replacing dollar
> characters with dots, and started to rely only on the InnerClasses attribute
> to correctly map JVM names to the "real" names of classes. This looked
> correct because at least class files generated by javac always have
> InnerClasses for all nested classes mentioned in the class file (not only in
> signatures, even those used only in method bodies!). However, for Groovy this
> [turned out|https://youtrack.jetbrains.com/issue/KT-27874] not to be the
> case. We'll probably workaround this problem somehow, for example by
> attempting to determine the class name twice, first by InnerClasses attribute
> values and second, by the aforementioned heuristic, but it'll be nice to get
> rid of the latter code in the future once this issue is fixed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8899) Add DGSM `first` and `last`
[
https://issues.apache.org/jira/browse/GROOVY-8899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16696109#comment-16696109
]
Jochen Theodorou commented on GROOVY-8899:
--
I am wondering though... why not just
Stream.of(2, 3, 6, 5).first()
why go through a Collector
> Add DGSM `first` and `last`
> ---
>
> Key: GROOVY-8899
> URL: https://issues.apache.org/jira/browse/GROOVY-8899
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 3.0.0-alpha-4
>
>
> {code:java}
> void testFirst() {
> assert 2 == Stream.of(2, 3, 6, 5).collect(Collectors.first()).get()
> }
> void testLast() {
> assert 5 == Stream.of(2, 3, 6, 5).collect(Collectors.last()).get()
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8897) Methods generated for Groovy properties do not carry over annotations
[
https://issues.apache.org/jira/browse/GROOVY-8897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16696089#comment-16696089
]
Eric Milles commented on GROOVY-8897:
-
I tried this as an experiment in {{Verifier.visitProperty}} and the method was
run before the allowed targets were resolved for the annotation. So I ended up
with errors for annotations on methods that were not meant for them like
{{@Min}} and so on.
{code:java}
if (getterBlock != null) {
MethodNode getter =
new MethodNode(getterName, getterModifiers, node.getType(),
Parameter.EMPTY_ARRAY, ClassNode.EMPTY_ARRAY, getterBlock);
// GRECLIPSE add
node.getField().getAnnotations().stream().filter(a ->
a.isTargetAllowed(AnnotationNode.METHOD_TARGET)).forEach(getter::addAnnotation);
// GRECLIPSE end
getter.setSynthetic(true);
addPropertyMethod(getter);
visitMethod(getter);
{code}
> Methods generated for Groovy properties do not carry over annotations
> -
>
> Key: GROOVY-8897
> URL: https://issues.apache.org/jira/browse/GROOVY-8897
> Project: Groovy
> Issue Type: Improvement
>Affects Versions: 2.4.15, 2.5.4
>Reporter: Eric Milles
>Priority: Major
>
> Consider the following:
> {code:groovy}
> class C {
> @Deprecated
> boolean condition
> }
> {code}
> Methods {{isCondition}}, {{getCondition}}, {{setCondition}} that are added by
> {{Verifier.visitProperty}} do not have the {{java.lang.Deprecated}}
> annotation. The PropertyNode has a link to the {{FieldNode}} so deprecated
> can be checked for there. But the generated methods do not have this link.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] groovy pull request #829: GROOVY-8900: Make class `Tuple0`, `Tuple1`...`Tupl...
GitHub user danielsun1106 opened a pull request: https://github.com/apache/groovy/pull/829 GROOVY-8900: Make class `Tuple0`, `Tuple1`...`Tuple16` final You can merge this pull request into a Git repository by running: $ git pull https://github.com/danielsun1106/groovy GROOVY-8900 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/groovy/pull/829.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #829 commit a9004a38c01401e0b92f8ff50003154e6347cf4d Author: danielsun1106 Date: 2018-11-22T16:21:16Z GROOVY-8900: Make class `Tuple0`, `Tuple1`...`Tuple16` final ---
[jira] [Commented] (GROOVY-8900) Make class `Tuple0`, `Tuple1`...`Tuple16` final
[ https://issues.apache.org/jira/browse/GROOVY-8900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16696087#comment-16696087 ] ASF GitHub Bot commented on GROOVY-8900: GitHub user danielsun1106 opened a pull request: https://github.com/apache/groovy/pull/829 GROOVY-8900: Make class `Tuple0`, `Tuple1`...`Tuple16` final You can merge this pull request into a Git repository by running: $ git pull https://github.com/danielsun1106/groovy GROOVY-8900 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/groovy/pull/829.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #829 commit a9004a38c01401e0b92f8ff50003154e6347cf4d Author: danielsun1106 Date: 2018-11-22T16:21:16Z GROOVY-8900: Make class `Tuple0`, `Tuple1`...`Tuple16` final > Make class `Tuple0`, `Tuple1`...`Tuple16` final > --- > > Key: GROOVY-8900 > URL: https://issues.apache.org/jira/browse/GROOVY-8900 > Project: Groovy > Issue Type: Improvement >Reporter: Daniel Sun >Assignee: Daniel Sun >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GROOVY-8900) Make class `Tuple0`, `Tuple1`...`Tuple16` final
Daniel Sun created GROOVY-8900: -- Summary: Make class `Tuple0`, `Tuple1`...`Tuple16` final Key: GROOVY-8900 URL: https://issues.apache.org/jira/browse/GROOVY-8900 Project: Groovy Issue Type: Improvement Reporter: Daniel Sun Assignee: Daniel Sun -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8899) Add DGSM `first` and `last`
[
https://issues.apache.org/jira/browse/GROOVY-8899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16696070#comment-16696070
]
ASF GitHub Bot commented on GROOVY-8899:
GitHub user danielsun1106 opened a pull request:
https://github.com/apache/groovy/pull/828
GROOVY-8899: Add DGSM `first` and `last`
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/danielsun1106/groovy enhance-collectors
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/groovy/pull/828.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #828
commit dbeb1881633c4ed43188b2ee9d4bf845fd8a8ff9
Author: danielsun1106
Date: 2018-11-22T16:07:16Z
GROOVY-8899: Add DGSM `first` and `last`
> Add DGSM `first` and `last`
> ---
>
> Key: GROOVY-8899
> URL: https://issues.apache.org/jira/browse/GROOVY-8899
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 3.0.0-alpha-4
>
>
> {code:java}
> void testFirst() {
> assert 2 == Stream.of(2, 3, 6, 5).collect(Collectors.first()).get()
> }
> void testLast() {
> assert 5 == Stream.of(2, 3, 6, 5).collect(Collectors.last()).get()
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] groovy pull request #828: GROOVY-8899: Add DGSM `first` and `last`
GitHub user danielsun1106 opened a pull request: https://github.com/apache/groovy/pull/828 GROOVY-8899: Add DGSM `first` and `last` You can merge this pull request into a Git repository by running: $ git pull https://github.com/danielsun1106/groovy enhance-collectors Alternatively you can review and apply these changes as the patch at: https://github.com/apache/groovy/pull/828.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #828 commit dbeb1881633c4ed43188b2ee9d4bf845fd8a8ff9 Author: danielsun1106 Date: 2018-11-22T16:07:16Z GROOVY-8899: Add DGSM `first` and `last` ---
[jira] [Created] (GROOVY-8899) Add DGSM `first` and `last`
Daniel Sun created GROOVY-8899:
--
Summary: Add DGSM `first` and `last`
Key: GROOVY-8899
URL: https://issues.apache.org/jira/browse/GROOVY-8899
Project: Groovy
Issue Type: Improvement
Reporter: Daniel Sun
Assignee: Daniel Sun
Fix For: 3.0.0-alpha-4
{code:java}
void testFirst() {
assert 2 == Stream.of(2, 3, 6, 5).collect(Collectors.first()).get()
}
void testLast() {
assert 5 == Stream.of(2, 3, 6, 5).collect(Collectors.last()).get()
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8897) Methods generated for Groovy properties do not carry over annotations
[
https://issues.apache.org/jira/browse/GROOVY-8897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16696033#comment-16696033
]
Eric Milles commented on GROOVY-8897:
-
{code:groovy}
import com.fasterxml.jackson.annotation.JsonProperty
class X {
@JsonProperty('whatever')
String value
}
{code}
I'm not sure if the expectation would be to copy this annotation to the
generated methods or leave it on the field only.
> Methods generated for Groovy properties do not carry over annotations
> -
>
> Key: GROOVY-8897
> URL: https://issues.apache.org/jira/browse/GROOVY-8897
> Project: Groovy
> Issue Type: Improvement
>Affects Versions: 2.4.15, 2.5.4
>Reporter: Eric Milles
>Priority: Major
>
> Consider the following:
> {code:groovy}
> class C {
> @Deprecated
> boolean condition
> }
> {code}
> Methods {{isCondition}}, {{getCondition}}, {{setCondition}} that are added by
> {{Verifier.visitProperty}} do not have the {{java.lang.Deprecated}}
> annotation. The PropertyNode has a link to the {{FieldNode}} so deprecated
> can be checked for there. But the generated methods do not have this link.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8834) Making "public" - BinaryExpression.leftExpression and similar fields
[
https://issues.apache.org/jira/browse/GROOVY-8834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16695937#comment-16695937
]
Eric Milles commented on GROOVY-8834:
-
The general approach to AST mutation is to implement the transformExpression
methods, which allows you an opportunity to substitute another expression for
the BinaryExpression or other expression type. Allowing mutability of all
expression properties makes AST processing more brittle/problematic. Once an
AST visitor has saved an expression reference, it should be able to reasonably
expect that the expression is unchanging, except maybe for some node metadata.
> Making "public" - BinaryExpression.leftExpression and similar fields
>
>
> Key: GROOVY-8834
> URL: https://issues.apache.org/jira/browse/GROOVY-8834
> Project: Groovy
> Issue Type: Wish
>Reporter: Anton Pryamostanov
>Priority: Major
> Labels: ast
>
> This is a general request related to AST API.
>
> Currently BinaryExpression.leftExpression and similar fields are having
> Private access.
> So to change the value, we need to replace the whole BinaryExpression with
> new one.
> This is not useful as it requires coding outside of Visitor methods, and I do
> not see reason why it should be private. It will greatly simplify visitor
> methods and transformations, if all Expression fields will have Public access.
> Alternatively please add setter methods with Public access.
> List of fields to be changed from Private to Public:
> {code:java}
> ArrayExpression->expressions
> ArrayExpression->sizeExpression
> BitwiseNegationExpression->expression
> BooleanExpression->expression
> CastExpression->expression
> ConstructorCallExpression->arguments
> GStringExpression->strings
> GStringExpression->values
> ListExpression->expressions
> MapExpression->mapEntryExpressions
> MethodPointerExpression->expression
> MethodPointerExpression->methodName
> PropertyExpression->property
> RangeExpression->from
> RangeExpression->to
> SpreadExpression->expression
> SpreadMapExpression->expression
> StaticMethodCallExpression->arguments
> TernaryExpression->booleanExpression
> TernaryExpression->trueExpression
> TernaryExpression->falseExpression
> TupleExpression->expressions
> UnaryMinusExpression->expression
> UnaryPlusExpression->expression{code}
> Note: those fields with "final" modifier should also be made re-assignable.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8882) CS: Loop over elements of String has different element type
[
https://issues.apache.org/jira/browse/GROOVY-8882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16695932#comment-16695932
]
Eric Milles commented on GROOVY-8882:
-
Is it possible to have dynamic groovy match the CS choice? I think it better
to support iteration over characters and this could be extended to anything
that implements CharSequence.
> CS: Loop over elements of String has different element type
> ---
>
> Key: GROOVY-8882
> URL: https://issues.apache.org/jira/browse/GROOVY-8882
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.4.15
>Reporter: Eric Milles
>Assignee: Paul King
>Priority: Minor
> Labels: breaking
>
> When the method below is executed as-is, the output is "java.lang.String" x3.
> When {{@CompileStatic}} is uncommented, the output is "java.lang.Character"
> x3. Is it possible to have dynamic groovy match the static compilation
> result?
> {code:groovy}
> //@groovy.transform.CompileStatic
> void meth() {
> for (c in 'abc')
> println c.class.name
> }
> {code}
> Similarly, {{'abc'*.anything}} applies to Strings of length one instead of
> Characters. Although, spread-dot is not supported against strings under
> static compilation. Is it possible to add that support?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GROOVY-8898) Annotation value cannot take inline constant from enum.
Samotsvet Dmitrii created GROOVY-8898:
-
Summary: Annotation value cannot take inline constant from enum.
Key: GROOVY-8898
URL: https://issues.apache.org/jira/browse/GROOVY-8898
Project: Groovy
Issue Type: Bug
Components: Compiler
Affects Versions: 2.5.4
Environment: - Windows 10
- IntelliJ Idea 2018
Reporter: Samotsvet Dmitrii
I've had enum MyProfiles
{code:java}
public enum MyProfiles {
/**some code is here
*/
public final static String FIRST_PROFILE = "FIRST";
public final static String SECOND_PROFILE = "SECOND";
}
{code}
And I've used next code in Spock test
{code:java}
@ActiveProfiles([FIRST_PROFILE ,SECOND_PROFILE ])
{code}
So, i've got next error at compile time
Error: Groovyc: Expected 'MyProfiles.FIRST_PROFILE' to be an inline constant of
type java.lang.String not a property expression in
@org.springframework.test.context.ActiveProfiles
Error: Groovyc:Attribute 'value' should have type java.lang.String but found
type java.lang.Object in @org.springframework.test.context.ActiveProfiles
But it works if i use 'class' instead of 'enum'
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
