Skip to content

Spike: measure pure-Rust CEL conformance against the official cel-spec suite #90

Description

@rrrodzilla

Workstream: Foundation · Part of #89

Context

Decision (#91): we build our own minimal CEL evaluator over DynamicValue (no upstream/vendored crate, no Cedar). This issue stands up the acceptance oracle that engine is built and verified against — the official google/cel-spec conformance corpus wired as a Rust test harness.

Critical framing: the SchemaForge subset, not the raw suite

A large fraction of google/cel-spec (wrappers, proto2, proto3, fields, enums, dynamic, type_deduction, unknowns) tests protobuf-message semantics we don't need (our value domain is DynamicValue). Target the relevant subset: basic, comparisons, logic, string, integer_math, fp_math, lists, macros/macros2, timestamps, conversions, optionals, string_ext, math_ext, encoders_ext, namespace, parse, plumbing — proto-message files excluded, exclusion logged (no silent truncation).

Scope

  • Vendor google/cel-spec tests/simple/testdata/*.textproto + the conformance protos needed to read them (cel/expr/conformance/test/simple.proto, suite.proto, cel.expr value/checked protos). Use the existing protoc toolchain (textproto → binary → prost decode) rather than a hand-rolled textproto parser.
  • A harness that runs an engine through the corpus, comparing each test's expr + bindings against expected value/eval_error.
  • Per-feature pass/fail reporting on the subset + logged exclusions.
  • Runs as a CI gate against our schema-forge-cel engine.

Acceptance


Dependencies: Parallelizable now. It is the test oracle the engine (#107/#108/#109) is built against. Soft.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions