[bug]: tuple `items: [...]` crashes parser with no line/context in the error

[Spikhalskiy]

Version or commit

v0.12.3

Affected area

OpenAPI 3.1 supported construct

Minimal OpenAPI fragment

openapi: "3.1.0"
info:
  title: repro
  version: "1.0.0"
paths:
  /example:
    post:
      operationId: example
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: "#/components/schemas/Body"
      responses:
        "200":
          description: OK
components:
  schemas:
    Body:
      type: object
      required: [pair]
      properties:
        pair:
          type: array
          minItems: 2
          maxItems: 2
          items:
            - type: string
            - type: string

Configuration and command

No special config. Reproduced on openapi-to-rust.dev/playground (equivalent to openapi-to-rust generate spec.yaml).

Actual behavior

Fails with:

Failed to parse OpenAPI spec: data did not match any variant of untagged enum Schema

The message carries no path, schema name, or line number, so finding the offending field in a real (much bigger) spec means
testing each component schema in isolation — with internal $refs rewritten to a stub, so a neighbour's problem cannot poison the result.

Swapping items for a single schema, or for prefixItems, parses fine, so it's specifically the positional items: [A, B] form that trips the untagged-enum match.

Expected behavior

1. Parse the positional items: [...] tuple form (FastAPI/pydantic v1 emits it under openapi: "3.1.0") the same way prefixItems is already handled.
2. Separately, when a schema fails to match any Schema variant, include the JSON pointer/path (and ideally line/column) of the offending node in the error instead of a bare untagged-enum message.

Environment

v0.12.3
Reproduced via the official web playground (openapi-to-rust.dev/playground) and a local install.

Checks

• I removed credentials and private API data.
• I searched existing issues for this behavior.
• This is not a security vulnerability.

[lightsofapollo]

on it

[lightsofapollo]

going out in 0.13.0

[lightsofapollo]

fixed in #61

[lightsofapollo]

clarification- the crash is fixed- there is a second issue where the typings are coming out as serde json so I am fixing that now