[pull] master from glideapps:master#65
Merged
Merged
Conversation
quicktype(), quicktypeMultiFile(), and quicktypeMultiFileSync() are now
generic over the language name, so passing a literal `lang` narrows
`rendererOptions` to that language's option map: unknown option names
and invalid enum values are compile errors. Callers that don't pin
`lang` to a literal keep the old, unchecked behavior, and there is no
runtime validation.
This also fixes OptionKey, which fell through to the Option class type
for non-enum options, making even valid string-option values like
`{ namespace: "Acme" }` fail to typecheck. Boolean options accept
booleans and their string forms, which is what BooleanOption.getValue
implements.
The type-level behavior is tested with vitest's typecheck mode via
@ts-expect-error assertions in renderer-options.test-d.ts.
The dead renderer options this uncovered in test/languages.ts
(C++ `unions`, TypeScript/Flow `declare-unions`, Zod/Effect
`array-type`, PropTypes `runtime-typecheck`) stay removed.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…double Instead of a fixed int64 check, each TargetLanguage now declares its supported integer range — the inclusive range of whole numbers its integer type can round-trip, as decimal strings since the boundaries exceed exact doubles. The default is int64; JavaScript-family languages (including Elm, whose Int is a JS number at runtime) are exact only within ±(2^53 - 1); Crystal renders integers as Int32; Python, Ruby, Elixir, and Pike have arbitrary-precision integers, and JSON Schema's `integer` is unbounded, so they have no limit. Some languages' integer width depends on a renderer option — cJSON's integer-size can narrow it down to int8_t — so the range is exposed as getSupportedIntegerRange(rendererOptions), and both the CLI and jsonInputForTargetLanguage pass the renderer options through when constructing JSON input. Both JSON parsers consult the range: the CLI's streaming parser checks the exact digit string, and the JSON.parse-based core parser checks the double's exact decimal value via toFixed(0), which errs toward `double` at range boundaries the double can't represent. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…ions fix(core): enforce rendererOptions keys in the type system
fix(core): infer whole numbers outside the target's integer range as double
Replace the Vitest unit test (which checked Rust output strings for one language) with a standard JSON Schema fixture exercising the same shape: an allOf nested inside a oneOf inside another oneOf, taken from the issue #2913 repro. The fixture runs against every language in CI, round-trips a positive instance, and expects failure on a malformed union member for languages with the "union" feature. Verified end-to-end locally with schema-golang and schema-typescript; all 22 CI target languages generate successfully from the schema. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
…e not checked (known limitation) (#2) cjson's generated parser does not validate invalid types in unions, maps, and arrays (documented above this skip list), so it silently coerces the fixture's expected-failure instance (array where an object is required) into an empty object instead of rejecting it. Skip the schema for cjson, exactly like the existing class-with-additional, go-schema-pattern-properties, and multi-type-enum skips. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
These languages cannot pass the fixture's expected-failure sample: - scala3: the test driver prints the circe DecodingFailure and exits 0, so a rejected input is indistinguishable from success. - kotlin / kotlin-jackson: the generated deserializer accepts an array where a union of two classes is expected instead of rejecting it. - haskell: the test driver encodes the Maybe result, so a failed decode prints "null" and exits 0. The scala3 and kotlin legs failed on exactly this in CI; haskell was cancelled by fail-fast but has the same structural limitation. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Maps of empty objects render as Map<String, X> with typealias X =
JsonObject, but Klaxon's reflective deserializer never consults custom
converters for map values, so parsing fails with "Couldn't find a
suitable constructor for class JsonObject to initialize with {}".
Adds unit tests expecting such fields to be handled by a field-level
converter, and re-enables the bug2037.json fixture for Kotlin/Klaxon
that #2877 had to skip. The unit tests currently fail; the fix follows
in the next commit.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Empty object types render as `typealias X = JsonObject`, and a custom
converter registered for JsonObject::class handles them. But Klaxon's
DefaultConverter looks up converters for map values with
`findConverterFromClass(typeValue.javaClass, ...)`, where
`typeValue.javaClass` is `java.lang.Class` rather than the value type,
so custom converters are never consulted for map values. Klaxon then
falls back to constructing JsonObject reflectively and fails with
"Couldn't find a suitable constructor for class JsonObject to
initialize with {}".
Klaxon does consult field-level converters, so properties whose type
is a map (possibly nested in further maps) with empty-object values
now get a generated `@KlaxonJsonObjectMap` field annotation, backed by
a registered field converter that returns the parsed JsonObject (which
already is a `Map<String, JsonObject>` at runtime) as-is.
Fixes #2881
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…union Fix nested intersections in union flattening
…maps Kotlin/Klaxon: fix deserialization of maps with empty-object values
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )