Upgrade Sourcemeta dependencies

[jviotti]

Signed-off-by: Juan Cruz Viotti jv@jviotti.com

[augmentcode]

🤖 Augment PR Summary

Summary:

• Updates the vendored Sourcemeta Blaze, Core, JSON BinPack, and jsonschema dependencies.
• Adapts One to the upgraded Blaze frame construction and traversal interfaces.
• Rebuilds schema-location artifact serialization from the new frame iteration APIs.
• Updates resolver fallback handling for dependency results that can borrow or own JSON.
• Aligns evaluation response validation with the upgraded annotation representation.
• Renames action, generator, search-scope, and related symbols to satisfy the new project conventions.
• Refreshes generated JavaScript evaluator opcode and annotation handling alongside Blaze.
• Updates vendored CMake/package metadata and dependency manifests required by the new versions.

Technical Notes:

• Schema framing now uses immutable constructor-based initialization and explicit location traversal.
• The generated locations payload retains separate static and dynamic URI maps and its existing API response schema.

_{🤖 Was this summary useful? React with 👍 or 👎}

[augmentcode]

Review completed. No suggestions at this time.

Comment augment review to trigger a new review at any time.

[cubic-dev-ai]

1 issue found across 262 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="src/index/generators.h">

<violation number="1" location="src/index/generators.h:369">
P2: GenerateFrameLocations now analyses the frame in Mode::Pointers, whereas the previous implementation (frame.analyse with Mode::Locations) analysed in Mode::Locations before emitting the locations output. These are semantically different frame modes, so the set of locations that for_each_location reports (and the relativeInstancePointer/type values) can change. The old code deliberately used Mode::Locations to populate this "locations" response; confirm Mode::Pointers yields the identical static/dynamic location set, otherwise anchors/resources or their pointers may be dropped from the generated locations schema.</violation>
</file>

<sub>Note: This PR contains a large number of files. cubic selects up to 200 of the highest-priority eligible files for this review, so some files may not have been reviewed.

Re-trigger cubic</sub>

[cubic-dev-ai]

P2: GenerateFrameLocations now analyses the frame in Mode::Pointers, whereas the previous implementation (frame.analyse with Mode::Locations) analysed in Mode::Locations before emitting the locations output. These are semantically different frame modes, so the set of locations that for_each_location reports (and the relativeInstancePointer/type values) can change. The old code deliberately used Mode::Locations to populate this "locations" response; confirm Mode::Pointers yields the identical static/dynamic location set, otherwise anchors/resources or their pointers may be dropped from the generated locations schema.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At src/index/generators.h, line 369:

<comment>GenerateFrameLocations now analyses the frame in Mode::Pointers, whereas the previous implementation (frame.analyse with Mode::Locations) analysed in Mode::Locations before emitting the locations output. These are semantically different frame modes, so the set of locations that for_each_location reports (and the relativeInstancePointer/type values) can change. The old code deliberately used Mode::Locations to populate this "locations" response; confirm Mode::Pointers yields the identical static/dynamic location set, otherwise anchors/resources or their pointers may be dropped from the generated locations schema.</comment>

<file context>
@@ -320,13 +361,64 @@ struct GENERATE_FRAME_LOCATIONS {
+          return resolver(identifier, callback);
+        }};
+    const sourcemeta::blaze::SchemaFrame frame{
+        sourcemeta::blaze::SchemaFrame::Mode::Pointers, contents,
+        sourcemeta::blaze::schema_walker, schema_resolver};
+    auto result{sourcemeta::core::JSON::make_object()};
</file context>

[github-actions]

Benchmark (community)

Details

Benchmark suite	Current: f88b20e	Previous: 0d088f2	Ratio
Add one schema (0 existing)	236 ms	310 ms	0.76
Add one schema (100 existing)	35 ms	35 ms	1
Add one schema (1000 existing)	97 ms	100 ms	0.97
Add one schema (10000 existing)	724 ms	707 ms	1.02
Update one schema (1 existing)	28 ms	28 ms	1
Update one schema (101 existing)	38 ms	37 ms	1.03
Update one schema (1001 existing)	95 ms	91 ms	1.04
Update one schema (10001 existing)	802 ms	791 ms	1.01
Cached rebuild (1 existing)	11 ms	11 ms	1
Cached rebuild (101 existing)	13 ms	12 ms	1.08
Cached rebuild (1001 existing)	47 ms	37 ms	1.27
Cached rebuild (10001 existing)	308 ms	300 ms	1.03
Index 100 schemas	444 ms	597 ms	0.74
Index 1000 schemas	1469 ms	1539 ms	0.95
Index 10000 schemas	12881 ms	12951 ms	0.99
Index 10000 schemas (custom meta-schema)	14873 ms	15308 ms	0.97
Index 10000 schemas ($ref fan-out)	14767 ms	15440 ms	0.96
test/e2e/html: Schema Fetch (p50)	419 us	414 us	1.01
test/e2e/html: Schema Fetch (p99)	506 us	493 us	1.03

This comment was automatically generated by workflow using github-action-benchmark.

[github-actions]

Benchmark (enterprise)

Details

Benchmark suite	Current: f88b20e	Previous: 0d088f2	Ratio
Add one schema (0 existing)	302 ms	393 ms	0.77
Add one schema (100 existing)	112 ms	120 ms	0.93
Add one schema (1000 existing)	157 ms	176 ms	0.89
Add one schema (10000 existing)	652 ms	789 ms	0.83
Update one schema (1 existing)	110 ms	112 ms	0.98
Update one schema (101 existing)	114 ms	124 ms	0.92
Update one schema (1001 existing)	157 ms	183 ms	0.86
Update one schema (10001 existing)	708 ms	805 ms	0.88
Cached rebuild (1 existing)	11 ms	12 ms	0.92
Cached rebuild (101 existing)	11 ms	17 ms	0.65
Cached rebuild (1001 existing)	29 ms	45 ms	0.64
Cached rebuild (10001 existing)	200 ms	340 ms	0.59
Index 100 schemas	529 ms	715 ms	0.74
Index 1000 schemas	1074 ms	1516 ms	0.71
Index 10000 schemas	10681 ms	12864 ms	0.83
Index 10000 schemas (custom meta-schema)	12302 ms	15214 ms	0.81
Index 10000 schemas ($ref fan-out)	12395 ms	15585 ms	0.80
enterprise/e2e/auth: Schema Anonymous (p50)	302 us	376 us	0.80
enterprise/e2e/auth: Schema Anonymous (p99)	448 us	479 us	0.94
enterprise/e2e/auth: Schema API Key Identity (p50)	302 us	380 us	0.79
enterprise/e2e/auth: Schema API Key Identity (p99)	411 us	495 us	0.83
enterprise/e2e/auth: Schema API Key SHA256 (p50)	309 us	389 us	0.79
enterprise/e2e/auth: Schema API Key SHA256 (p99)	448 us	540 us	0.83
enterprise/e2e/auth: Schema JWT (p50)	442 us	532 us	0.83
enterprise/e2e/auth: Schema JWT (p99)	613 us	722 us	0.85
test/e2e/html: Schema Fetch (p50)	302 us	384 us	0.79
test/e2e/html: Schema Fetch (p99)	400 us	473 us	0.85

This comment was automatically generated by workflow using github-action-benchmark.