Skip to content

corpus: message-literal list elements in 10_literal_args + carrier golden (#176) - #178

Merged
trendvidia merged 2 commits into
mainfrom
corpus-176-message-literal-list
Jul 25, 2026
Merged

corpus: message-literal list elements in 10_literal_args + carrier golden (#176)#178
trendvidia merged 2 commits into
mainfrom
corpus-176-message-literal-list

Conversation

@trendvidia

Copy link
Copy Markdown
Owner

Closes #176.

Pairs the corpus with trendvidia/protocompile#127trendvidia/protocompile#128 (merged post-v0.21.0): the reference parser now accepts message literals as list elements at annotation arguments, so the corpus pins the shape.

What changed

  • 10_literal_args.proto — new annotation samples(values: any) + a fourth Order field using @samples([Money{currency: "USD", units: 5}, Money{currency: "EUR", units: 7}]). The unused protowire/schema/v1/annotations.proto import is dropped (the incidental hygiene note in Corpus: message-literal list elements in 10_literal_args + 11 carrier golden (RFC-001 §8.1 LiteralValue.literal) #176 — the fixture only uses locally-declared annotations).
  • 11_literal_carrier_golden.textproto — pins the lowered list-of-message shape: each element is LiteralValue.literal wrapping Literal.message, its own google.protobuf.Any serialized at lowering (EUR/7 wire bytes \n\003EUR\020\007). While re-authoring, the golden is realigned to the actual reference-lowered carrier (verified by compiling the fixture with pxf build on the bumped fork and dumping ext 50401): the fixture writes every argument positionally, so AnnotationArg.name is empty per §8.1's "empty for positional", and location.file is the fixture's import path 10_literal_args.proto rather than the old notional fixtures/literals.proto. The previous name: "value"/notional-path entries predated the toolchain (authored at spec: finalize Literal carrier shape (RFC-001 §8.1) #99/spec: pin message-literal source grammar (RFC-001 §5.1) #108).
  • invalid/untyped_list_element.proto — MUST-NOT-COMPILE fixture for the untyped form [{...}] under an any-typed parameter (RFC-001 §5.1 literal rule 1), plus its manifest row. Rejected with exactly protocompile's documented diagnostic: message-literal list element in argument "values" ... requires an explicit type name.
  • go.mod — fork bump v0.20.0v0.21.1-0.20260725214716-467a41569c93 (the CI: no build coverage for editors/ — vscode and jetbrains changes merge unverified #128 merge commit; includes v0.21.0). Consequences picked up:
    • checkKnownGaps entry for reserved_sensitive_class.proto removed — protocompile#123 closed in v0.21.0 and TestCheckInvalidFixtures now asserts genuine rejection (no skip).
    • Stale protocompile#121 drift note in 14_refinement_kinds.proto updated (fixed in v0.21.0).

internal/schemaext (nested test-only module) stays on v0.20.0 — its harness compiles fixtures 01–06 only and is untouched by this change.

Verification

  • go test ./... clean on the bumped fork.
  • Golden authored from actual lowered output (not hand-derived): pxf build over the fixture, carrier dumped via pwsv1.E_FieldAnnotations and diffed against the golden.
  • pxf build --check invalid/untyped_list_element.proto fails with the expected explicit-type-name diagnostic.

Downstream

Un-blocks revisiting the @http responses parameter deferral — tracked in #177.

Precedent: trendvidia/protocompile#121/#123/#127 corpus/toolchain pairing.

…lden (#176)

Pairs the corpus with trendvidia/protocompile#127 (fixed in #128,
merged post-v0.21.0): message literals as list elements at annotation
arguments.

- 10_literal_args.proto: new @samples([Money{...}, Money{...}]) use
  site; drop the unused annotations.proto import (hygiene note in
  #176).
- 11_literal_carrier_golden.textproto: pin the lowered list-of-message
  shape (LiteralValue.literal wrapping an Any per element) and realign
  the golden to actual reference-lowered output — positional args
  carry no name (§8.1 "empty for positional") and location.file is
  the fixture's import path, not the old notional path.
- invalid/untyped_list_element.proto: MUST-NOT-COMPILE fixture for the
  untyped form [{...}] under an any-typed parameter (§5.1 rule 1) +
  manifest row.
- go.mod: fork bump v0.20.0 -> v0.21.1-0.20260725214716-467a41569c93
  (includes v0.21.0). checkKnownGaps entry for
  reserved_sensitive_class.proto removed: protocompile#123 closed in
  v0.21.0 and the fixture is now genuinely rejected. Stale drift note
  for protocompile#121 in 14_refinement_kinds.proto updated.
@trendvidia
trendvidia force-pushed the corpus-176-message-literal-list branch from f307a89 to 1b7983a Compare July 25, 2026 22:04
trendvidia added a commit that referenced this pull request Jul 25, 2026
The deferral's parser precondition closed
(trendvidia/protocompile#127 -> #128; corpus pinned by #176 / PR
#178), leaving demand — and none exists. Records the decision in
RFC-001-issues.md §#80: derived-only stands, and the deferral
converts into a principled bar (authored per-status responses are
unverifiable claims, per the Gap-3 @SInCE and #112 @Encrypted
reasoning). A future proposal needs a concrete consumer, with a
narrow defaulted scalar preferred over an authored per-status
vocabulary. No normative spec change: §5.2 already carries no
responses parameter and its §#80 rationale pointer is unchanged.
trendvidia added a commit that referenced this pull request Jul 25, 2026
The deferral's parser precondition closed
(trendvidia/protocompile#127 -> #128; corpus pinned by #176 / PR
#178), leaving demand — and none exists. Records the decision in
RFC-001-issues.md §#80: derived-only stands, and the deferral
converts into a principled bar (authored per-status responses are
unverifiable claims, per the Gap-3 @SInCE and #112 @Encrypted
reasoning). A future proposal needs a concrete consumer, with a
narrow defaulted scalar preferred over an authored per-status
vocabulary. No normative spec change: §5.2 already carries no
responses parameter and its §#80 rationale pointer is unchanged.
@trendvidia
trendvidia merged commit e53ccd5 into main Jul 25, 2026
6 checks passed
@trendvidia
trendvidia deleted the corpus-176-message-literal-list branch July 25, 2026 23:11
trendvidia added a commit that referenced this pull request Jul 25, 2026
Replaces the post-v0.21.0 pseudo-version
(v0.21.1-0.20260725214716-467a41569c93, pinned by #176/PR #178 for the
message-literal list-element fix #128) with the tagged release that
contains it, and aligns the nested internal/schemaext test-only module
(v0.20.0 -> v0.22.0) so both modules ride one fork version.

New in v0.22.0 beyond the pseudo-version: #130 — broken and cyclic
alias bases are diagnosed at the declaration site even when
unreferenced (spec-correct tightening). No corpus fixture carries a
broken or cyclic alias, so no golden or known-gap change; full suite
and the schemaext round trip are green on the tag.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Corpus: message-literal list elements in 10_literal_args + 11 carrier golden (RFC-001 §8.1 LiteralValue.literal)

1 participant