As of #288, the spec wil require resource identifiers to be strings: schema:ethdebug/format/materials/id is type: string (previously number | string), and type/reference.id is string-only. These constraints land with the ids-to-strings spec change.
Two external implementations exercised by the conformance suite still emit numeric ids, so their live output no longer validates against the schema.
- soldb (walnuthq/soldb, which the conformance workflow checks out at
main) assumes numeric source ids throughout, not at a single serialization site: crates/soldb-ethdebug/src/metadata.rs declares struct SourceLocation { source_id: u64, … }, parses ethdebug with code.get("source")?.get("id")?.as_u64()? — so a string id makes as_u64() return None and source resolution fails silently rather than erroring — and keys its sources as BTreeMap<u64, String>.
- solc (checked out at
develop) emits numeric source indices, which soldb consumes.
Both are pinned to moving branches this repo doesn't control (SOLIDITY_REF=develop, SOLDB_REF=main), so the mismatch can't be resolved here alone; it needs coordinated upstream changes to solc's ETHDebug emitter and to soldb's u64 plumbing.
Until then, a transitional carve-out keeps the conformance suite runnable: packages/conformance/src/runner.ts (validateSchema) downgrades exactly the numeric-materials/id validation failure on external output to a loud warning that points back to this issue. Every other validation failure still fails hard, and no data is rewritten before validation. The in-repo consumer (bugc) already emits string ids.
Once solc and soldb emit string resource ids, close out the transition:
As of #288, the spec wil require resource identifiers to be strings:
schema:ethdebug/format/materials/idistype: string(previouslynumber | string), andtype/reference.idis string-only. These constraints land with the ids-to-strings spec change.Two external implementations exercised by the conformance suite still emit numeric ids, so their live output no longer validates against the schema.
main) assumes numeric source ids throughout, not at a single serialization site:crates/soldb-ethdebug/src/metadata.rsdeclaresstruct SourceLocation { source_id: u64, … }, parses ethdebug withcode.get("source")?.get("id")?.as_u64()?— so a string id makesas_u64()returnNoneand source resolution fails silently rather than erroring — and keys its sources asBTreeMap<u64, String>.develop) emits numeric source indices, which soldb consumes.Both are pinned to moving branches this repo doesn't control (
SOLIDITY_REF=develop,SOLDB_REF=main), so the mismatch can't be resolved here alone; it needs coordinated upstream changes to solc's ETHDebug emitter and to soldb'su64plumbing.Until then, a transitional carve-out keeps the conformance suite runnable:
packages/conformance/src/runner.ts(validateSchema) downgrades exactly the numeric-materials/idvalidation failure on external output to a loud warning that points back to this issue. Every other validation failure still fails hard, and no data is rewritten before validation. The in-repo consumer (bugc) already emits string ids.Once solc and soldb emit string resource ids, close out the transition:
packages/conformance/src/runner.ts(validateSchema), so the suite validates ids strictly again.Materials.IdTypeScript type fromstring | numbertostring— it was left lenient during the transition so the type matches the carve-out's tolerance.