On 9/2/2026 23:18, David Malcolm wrote:
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]
}
}
I think the above two should be tested and raise an error.
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)
I think this case should raise a warning instead of an error, because we
might add a new format for the target string in the future. This indeed
happens on other architectures like RISC-V.
I will update them for the next revision.
Thanks,
Yangyu Chen
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
