apple/pkl · error · VmException

cannotAmendPropertyDefinition

cannotAmendPropertyDefinition

Error message

cannotAmendPropertyDefinition

What it means

When a property is defined with both a type annotation and an object body (`prop: Type { ... }`) inside an amendment, Pkl cannot tell whether you intend to define or amend the property, so it rejects the combination with cannotAmendPropertyDefinition, pointing at the whole definition entry. Object bodies without a type annotation are treated as amendments of the existing property.

Source

Thrown at pkl-core/src/main/java/org/pkl/core/ast/builder/AstBuilder.java:2078

    var annotationNodes = doVisitAnnotations(annotations, propertyName);

    return symbolTable.enterProperty(
        propertyName,
        getConstLevel(modifiers),
        scope -> {
          ExpressionNode bodyNode;

          if (expr != null) { // prop = expr
            if (VmModifier.isExternal(modifiers)) {
              throw exceptionBuilder()
                  .evalError("externalMemberCannotHaveBody")
                  .withSourceSection(headerSection)
                  .build();
            }
            bodyNode = visitExpr(expr);
          } else if (!objectBodies.isEmpty()) { // prop { ... }
            if (typeAnnotation != null) {
              throw exceptionBuilder()
                  .evalError("cannotAmendPropertyDefinition")
                  .withSourceSection(createSourceSection(entry))
                  .build();
            }
            bodyNode =
                doVisitObjectBody(
                    objectBodies,
                    new ReadSuperPropertyNode(
                        unavailableSourceSection(),
                        scope.getName(),
                        scope.getConstLevel() == ConstLevel.ALL));
          } else { // no value given
            if (isLocal) {
              assert typeAnnotation != null;
              throw missingLocalPropertyValue(typeAnnotation);
            }
            if (VmModifier.isExternal(modifiers)) {
              bodyNode =

View on GitHub (pinned to f3efcbfc9b)

Solutions

  1. Drop the type annotation: `prop { ... }` amends the existing property.
  2. Provide an explicit value (`prop: Type = new Type { ... }`) if you intend a full redefinition.
  3. Mark the property `local` if it is a genuinely new definition.

Example fix

// before (in an amendment)
server: Server { port = 8080 }

// after
server { port = 8080 }
Defensive patterns

Strategy: validation

Validate before calling

// In amendments, reject `prop: Type { ... }` combined forms:
if (isAmendment && propTypeAnnotation != null && hasObjectBody(prop) && propValueExpr == null) {
  report(prop, "drop the type annotation or provide an explicit value");
}

Prevention

When it happens

Trigger: Writing `prop: SomeType { ... }` where the property has no `= expr` value, a non-empty object body, and a non-null typeAnnotation, in a context where the property amends an existing definition.

Common situations: Amending an object-typed property in a layered config while copy-pasting its type annotation along; adding member bodies to an inherited object property.

Understand the failure class

Background: "Invalid value" and "allowed values are" config errors: what your library rejected and how to fix it — this error's family across 41 libraries.

Related errors


AI-assisted analysis of apple/pkl@f3efcbfc9b (2026-09-08). Data as JSON: /api/errors/11374a0e5b0c68ff. Report an issue: GitHub.