Allow attributes on list elements

[jonas-meyer]

With @yaml(,tag) (b1a58bd), CUE can emit custom YAML tags on struct fields. However, nested tags (tags on individual sequence elements) cannot be expressed because the grammar doesn't allow attributes on list elements.

Example: Authentik blueprints use !Format [pattern, !Env VAR]:

oidc_well_known_url: !Format
  - https://login.microsoftonline.com/%s/v2.0/.well-known/openid-configuration
  - !Env AZURE_TENANT_ID

The natural CUE would be:

oidc_well_known_url: [
  "https://login.microsoftonline.com/%s/v2.0/.well-known/openid-configuration",
  "AZURE_TENANT_ID" @yaml(,tag="!Env"),
] @yaml(,tag="!Format")

This is a syntax error today.

Prior issues

• Allow attributes for list elements #774 @mpvl: "it arguably should" be allowed, "list elements are almost indistinguishable from struct fields, so this would be consistent"
• ElemAttr TODO in cue/attribute.go and internal/attrs.go planned but never implemented
• Support attributes in let declaration #949 -- same limitation for let declarations

Proposal

Extend ElementList to allow trailing attributes, mirroring Field:

Element = Embedding { attribute } .

AST: a general AnnotatedExpr wrapper (reusable for future positions like let per #949):

type AnnotatedExpr struct {
    X     Expr
    Attrs []*Attribute
}

Parser: in parseListElement(), call parseAttributes() after the expression and wrap in AnnotatedExpr if present.

YAML encoder: in encode(), unwrap AnnotatedExpr and apply extractYAMLTag() to the resulting node.

This pattern also appears in CloudFormation (!Join containing !Ref) and other YAML-based config formats.

Purely additive, all existing CUE files remain valid, no change to evaluation semantics.

[mvdan]

@jonas-meyer for the sake of completeness, did you try this workaround in the original thread? That is, something like:

oidc_well_known_url: [
  "https://login.microsoftonline.com/%s/v2.0/.well-known/openid-configuration",
  {"AZURE_TENANT_ID", @yaml(,tag="!Env")},
] @yaml(,tag="!Format")

You can make the second list element multi-line if you prefer that formatting, too.

I suspect this might not work with the YAML encoder today, as we inspect attributes via the AST, but we could and arguably should make it work, regardless of whether we end up changing the language spec. I think it's worthwhile exploring this first, given that language changes are always more involved.

[jonas-meyer]

Tried it. The struct workaround parses but the YAML encoder doesn't handle it:

$ cue export --out yaml -
oidc_well_known_url: [
  "https://login.microsoftonline.com/%s/v2.0/.well-known/openid-configuration",
  {"AZURE_TENANT_ID", @yaml(,tag="!Env")},
] @yaml(,tag="!Format")

yaml: unsupported node "AZURE_TENANT_ID" (*ast.BasicLit)

encodeDecls skips *ast.Attribute decls and handles *ast.EmbedDecl separately, so the sibling attributes never get applied to the embedded value's YAML node. Happy to take a stab at fixing that if you'd prefer this path over a grammar change.

[mvdan]

Feel free to send a patch - I think we should fix this regardless of whether or not we want to do a language change later. The cue.Value API should support attributes of this form, as they're still attached to the list element itself, so we should have the same semantics when looking up attributes via cue/ast.

Assuming you'd still want the language change, feel free to reference this issue in the patch but without marking it as fixed, and we can keep it open to track further changes.