I'm not opposed, but not entirely convinced either. I don't think there's significant risk of breaking things for others, thanks to conditional sections: ['arch in (riscv32, riscv64)', stuff_here_wont_break_others]. Needing to get OWNERS approvals is an extra step of course, but since those are trivial reviews, I'd hope that you're getting responses very quickly usually?
My biggest concern is that while a split in two is probably acceptable, I wouldn't want to open the floodgates to having ten different expectations files in the future that make it hard to find relevant definitions. For example, I find dealing with Blink test expectations (in the Chromium repo) rather painful for this reason. With this thought in mind, a possible compromise: rather than introducing RISCV-specific status files as a special case, we could split them into "officially supported platforms" (i.e. ia32, x64, arm, arm64 currently) and "community maintained platforms" (all others). Then the logic of which status files to load could even move into the test runner, rather than import statements of some sort in the primary status file; note that for community-maintained platforms we'd need to load both status files. Does that sound viable to you? For the record, I'm also fine with just continuing to have conditional sections as needed in a single status file. On Mon, Aug 18, 2025 at 11:33 AM Kasper Lund <[email protected]> wrote: > Hi all, > > I'm working on the RISC-V port of V8. It would be very useful for us to > have a way to separate the test expectations for the architectures we cover > in separate *-riscv.status files, so we can change them without the risk of > breaking things for others. Given the OWNER setup we're using, this will > also allow us to avoid pestering core team members with small status file > updates :) > > It shouldn't be too hard to add support for some level of modularity to > the status file support, but clearly it comes with the cost of having to > worry about multiple places to find the status for a specific test. Maybe > that cost and the extra complexity in the status file parser outweigh the > benefits. > > One way of doing it would be to allow importing other status files with > extra conditions implicitly added to the imported statuses - and another > would be to check that all conditions in the imported statuses satisfy the > import arch requirements: > > ['arch in [riscv32, riscv64]', IMPORT, 'mjsunit-riscv.status'] > > Thoughts? > > Regards, > Kasper > > -- > -- > v8-dev mailing list > [email protected] > http://groups.google.com/group/v8-dev > --- > You received this message because you are subscribed to the Google Groups > "v8-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/d/msgid/v8-dev/CAKaTMyLW-%2BVERD0iQ2k-pbRNGZqBZUO5QTa%2BNOFYvk0dh5z%2BFw%40mail.gmail.com > <https://groups.google.com/d/msgid/v8-dev/CAKaTMyLW-%2BVERD0iQ2k-pbRNGZqBZUO5QTa%2BNOFYvk0dh5z%2BFw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/v8-dev/CAKSzg3T2OgMNNqHRce2ZzbVwqntk%3D_LfA3NAnZ5sK8KYz2pmeg%40mail.gmail.com.
