Kotlin and Groovy type attribution gaps behind AttributeValue's degraded classification

[MBoegers]

What's the issue?

• Add AttributeValue trait for non-literal annotation attribute values #8166 introduced the AttributeValue trait (Annotated trait cannot read non-literal attribute values (class literals, enum constants, constant references) #8160), which classifies annotation attribute values syntax-first and discriminates enum constants via Flag.Enum (JVMS ACC_ENUM) on the referenced JavaType.Variable — the contract javac-attributed Java fulfills. On Kotlin and Groovy sources the same code degrades (enum constants classify as CONSTANT_REFERENCE, constant references don't fold), not because of the trait but because of parser/type-mapping gaps. The divergences are captured as @ExpectedToFail tests in rewrite-groovy/.../AttributeValueTraitTest and rewrite-kotlin/.../AttributeValueTraitTest, asserting the Java-aligned semantics — each flips red the moment its gap is fixed.
• Kotlin: set Flag.Enum on enum entries in KotlinTypeMapping #8178 fixed the Kotlin part of this issue.

The gaps

1. Kotlin: Flag.Enum is never set on enum entries (one-line fix)

KotlinTypeMapping.kt:1171 — variableType(FirVariable, …) computes flags via mapToFlagsBitmap(visibility, modality, isStatic) with no enum-entry branch, even though enum entries flow through this very method (:519-520) and the enum class does get the bit (:446-447, flags or (1L shl 14)). Fix: add the bit when variable is FirEnumEntry. Unblocks AttributeValue#isEnumConstant(..) on Kotlin.

2. Groovy: property-access references carry no fieldType at all

GroovyParserVisitor#visitPropertyExpression converts the property name to a J.Identifier with fieldType hard-coded null — the resolved FieldNode is never looked up, although GroovyTypeMapping.variableType(FieldNode) exists and declared enum constants get proper attribution (GroovyParserVisitor:850). Groovy's enum-constant FieldNodes carry ACC_ENUM at Phases.CANONICALIZATION (set by EnumHelper), so attaching typeMapping.variableType(classNode.getField(name)) when the receiver's static type resolves would fix enum discrimination and give getReferencedField() to all Groovy constant references, including idiomatic bare class refs (@Foo(type = String)). Needs scoping to statically unambiguous receivers (dynamic dispatch).

3. Both: no JavaType.Annotation element values → no constant fold

Neither type mapping constructs ElementValues (zero references in either module), so AttributeValue#getConstantValue() cannot resolve Constants.NAME on these sources, while javac paths fold even binary-dependency constants (ReloadableJava17TypeMapping.listAnnotations:644, Attribute.Constant fold at :704). Larger effort — possibly split per language.

4. Both: list/collection literals are opaque to array normalization

G.ListLiteral/K.ListLiteral are not J.NewArray and cannot be referenced from rewrite-java, so AttributeValue#getElements() returns them as one opaque value. This one is likely not a parser fix (mapping them to J.NewArray would break print fidelity) — it wants a trait extension seam or a shared interface in rewrite-java. Listed here for completeness; could be split out.

Expected behavior

The @ExpectedToFail test markers: ENUM_CONSTANT:isEnum=true, folded CONSTANT_REFERENCE:n, ARRAY:elements=2, and CLASS_LITERAL for Groovy bare class references.

[MBoegers]

thanks @timtebeek for fixing the kotlin part.