[pull] master from glideapps:master#70
Merged
Merged
Conversation
…and source code generation
Only conflict was the import block in Kotlin/language.ts: kept master's ESM .js import paths and re-added the PR's type imports (PrimitiveStringTypeKind, TransformedStringTypeKind, StringTypeMapping) in the same style. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Register strict ISO converters on the generated ObjectMapper for OffsetDateTime, LocalDate and OffsetTime via the existing convert() infrastructure instead of requiring jackson-datatype-jsr310: the module's serializers don't round-trip faithfully (OffsetTime pads "23:20:50.52Z" to "23:20:50.520Z"), while the ISO formatters do, and this way generated code needs no extra dependency. Also fix union deserialization when several members are guarded by the same node type: date, time, date-time and enum values are all TextNode, so the previous output had duplicate 'is TextNode ->' branches of which only the first could ever match. Members sharing a guard now parse in a single branch that tries each member in sequence, strictest first (transformed strings, then enums, then plain strings). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The klaxon renderer's matchType calls were missing the transformedStringType matcher the base renderer maps to java.time types, so any schema with date/time formats in a union crashed generation with "Unsupported type date-time in non-exhaustive match". Add the matchers, register Klaxon converters that parse the java.time types from ISO strings and re-serialize them via the ISO formatters (exact round-trip), and give union members that share the 'is String' guard the same sequential-parse treatment as the Jackson renderer. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…va.time
With date/time inference now mapping to java.time types, two groups of
misc inputs fail the round-trip comparison: files with non-RFC3339
date-times (space-separated, no offset) that OffsetDateTime.parse
rejects, and files whose fractional seconds have trailing zeros that
the ISO formatters legitimately trim (".000Z" -> "Z"). Skip them for
both Kotlin variants, mirroring what Go already does for the first
group.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…erence With the default recognizer now requiring RFC 3339 (T separator and timezone offset), space-separated timestamps like "2013-06-15 21:10:28" are inferred as plain strings, so these eight misc fixtures round-trip for both kotlin variants without skips (verified per file; f6a65.json also verified end-to-end with kotlinc). The nine remaining skips are unchanged: their values are RFC 3339-valid but carry trailing-zero fractional seconds (e.g. ".000Z") that java.time does not re-serialize identically. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The Kotlin language's stringTypeMapping maps JSON Schema date, time, and date-time formats to java.time types for every framework, but the kotlinx renderer was never taught about them: it emitted @serializable data classes with OffsetDateTime/LocalDate/OffsetTime properties, which don't compile because kotlinx.serialization has no built-in serializers for java.time ("Serializer has not been found for type 'OffsetDateTime'"). Emit custom KSerializer objects for the java.time types that appear in the type graph and register them file-wide with @file:UseSerializers. Like the Jackson and Klaxon converters, they parse with .parse and format with the ISO formatters so values round-trip faithfully. There is no kotlinx fixture in CI, so cover this with a unit test asserting the serializers and file annotation are emitted (and not emitted when no date/time types occur). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
# Conflicts: # packages/quicktype-core/src/language/Kotlin/KotlinJacksonRenderer.ts # packages/quicktype-core/src/language/Kotlin/KotlinKlaxonRenderer.ts # packages/quicktype-core/src/language/Kotlin/KotlinXRenderer.ts
…erence Merging master brought in the kotlinx fixture coverage from #2950, whose skip lists were tuned against master, where Kotlin had no date-time support. With this branch's date/time mapping: - Declare the "date-time" feature for KotlinXLanguage. date-time.schema itself stays skipped because its union-array properties hit the kotlinx sealed-class union limitation; the emitted KSerializers are exercised by JSON inputs with inferred date-times instead. - Skip the misc JSON inputs whose date-times carry trailing zeros in the fractional seconds, which java.time doesn't re-serialize identically — the same set already skipped for klaxon and jackson. - Skip date-time-or-string.schema: its string|date-time property was a plain string before and now becomes a union. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Instead of skipping test inputs whose date-time strings java.time does not re-serialize byte-identically, give Kotlin a DateTimeRecognizer (the existing facility for this, mirroring SwiftDateTimeRecognizer) that refuses to infer date/time types from such strings in the first place. Rejected strings simply stay plain strings. The rules, all verified against java.time's actual parse/format behavior (ISO_LOCAL_DATE / ISO_OFFSET_TIME / ISO_OFFSET_DATE_TIME): - no trailing zeros in fractional seconds (java.time formats the shortest fraction: ".000" disappears, ".500" becomes ".5"), - at most 9 fractional digits (java.time's nanosecond precision; more don't parse), - offset "Z" or a nonzero "±hh:mm" within java.time's ±18:00 range (zero offsets format back as "Z", larger ones don't parse), - uppercase "T" and "Z" (lowercase forms format back in uppercase), - no Feb 29 outside leap years (java.time refuses to parse it). This only affects inference from JSON samples — JSON Schema's "format": "date-time" maps to OffsetDateTime regardless, which is the correct behavior for schema-driven input. The nine date-time-related misc-JSON skips on the Kotlin fixtures are lifted; every date/time-like string in the test inputs that the new recognizer accepts was verified to round-trip byte-identically through java.time (5692 strings checked). 77392.json and b4865.json stay skipped for kotlinx only, for the unrelated top-level-JsonArray reason. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
feat(kotlin): Support for date and datetime from JSON schema
Fixes for the header/source split feature (header-only=false): - startSourceFile now takes the header filename at every call site and derives the source filename itself. Previously the multi-source call sites passed the source filename, so every generated .c file began with an unguarded self-include (#include <ClassName.c>) that made compilation recurse infinitely. - The redundant unconditional emitIncludeLine(headerFilename, true) after startSourceFile is gone. In header-only mode it made every generated header include itself (an unintended change to the pre-existing multi-source output); in split mode it duplicated the include emitted by startSourceFile. - The source file's include of its own header is now a quoted include, matching the existing convention: quoted includes for generated files, angle brackets only for system and vendored headers. - getSourceNameFromHeaderName anchors the extension swap (/\.h$/), so a header named my.house.h maps to my.house.c, not my.couse.h. - The header-only option is a BooleanOption instead of a string EnumOption, giving the usual --[no-]header-only CLI flags. - The five duplicated finishHeaderFile/finishSourceFile blocks are factored into finishCurrentFile, and a comment typo is fixed. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- The vendored dependencies (cJSON, hashtable, list) are downloaded into a deps/ subdirectory and included with -isystem instead of -I.. Angle-bracket includes now resolve only in deps/, while quoted includes resolve relative to the including file, so a generated #include <TopLevel.h> fails to compile and the include-style convention is enforced by the build. - second.c is a second translation unit including TopLevel.h. It is compiled and linked in the split-mode compile commands, verifying that split output supports multi-TU builds (issue #2617). - Three minimal mode fixtures run one complex input (nbl-stats.json, which produces enums, unions and 22 type pairs) through the remaining option combinations: - cjson-default: single-source, header-only (the pre-existing default output mode) - cjson-multi-header: multi-source, header-only (single TU; header-only output cannot link from multiple TUs) - cjson-multi-split: multi-source with header/source pairs, compiled with *.c so every generated source file is linked - The cjson comment-injection target's output is TopLevel.h; with header-only=false a proposed filename of TopLevel.c would have named both generated files TopLevel.c. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Renders a small input through the quicktype API and asserts, for the multi-source modes, that every header gets a source file, that no generated file includes itself, that generated files are referenced with quoted includes (never angle brackets), that each source file includes its own header first, and that header-only mode emits no source files. Also pins the output filenames for a proposed filename with an inner ".h" (my.house.h -> my.house.c). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
[FEATURE]: cJSON - generate source/header pairs
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.
3 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 : )