On Mon, 2026-02-09 at 10:09 -0500, David Malcolm wrote:
> On Tue, 2026-02-03 at 01:49 +0800, Yangyu Chen wrote:
[...snip...]
>
> > diff --git a/gcc/testsuite/gcc.target/i386/tct-0.json
> > b/gcc/testsuite/gcc.target/i386/tct-0.json
> > new file mode 100644
> > index 000000000000..9dc712e66e2b
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/i386/tct-0.json
> > @@ -0,0 +1,5 @@
> > +{
> > + "foo": {
> > + "x86_64": ["arch=x86-64-v2", "arch=x86-64-v3", "arch=x86-
> > 64-
> > v4"]
> > + }
> > +}
>
> FWIW the testsuite doesn't have any coverage for invalid JSON input.
> How gracefully do we handle e.g. a missing comma in the input?
Sorry, I was sloppy with terminology here (malformed vs invalid); I
should have said:
* should the testsuite have coverage for malformed JSON input? (e.g. a
missing comma)
{
"foo": {
"x86_64": ["arch=x86-64-v2", "arch=x86-64-v3" "arch=x86-64-v4"]
}
}
* should the testsuite have coverage for invalid JSON input? (e.g.
something that isn't a string in the list)
{
"foo": {
"x86_64": ["arch=x86-64-v2", "arch=x86-64-v3", 42]
}
}
Plus:
* should the testsuite have coverage for an option that is a string but
doesn't parse? e.g.
{
"foo": {
"x86_64": ["lorem ipsum"]
}
}
(or an unrecognized arch? not sure about this one)
>
> Should we ship JSON schemata for the JSON input formats we support?
> (so
> that users can validate their files, and potentially have IDE support
> for typesafe editing of them)
>
> Hope this is constructive
> Dave
>
