You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
cmd/compile/internal/gc/asm_test.go contains code generation tests for all architectures. The tests are grouped in very long arrays, one for each architecture. For example the amd64 codegen tests are inside an array named linuxAMD64Tests spanning ~1500 lines of code (from 279 line to line 1770). All the architectures arrays are one after the other.
Working on the file is slightly annoying because when writing, reading or grepping through it you can never tell inside which architecture's array you are, so I find myself constantly scrolling/jumping back in the file until I find the start of the array, where I can read the name of the variable that holds it and determine which architecture tests I'm looking at.
Reviewing changes to the file is also difficult, because a reviewer will need to expand potentially hundreds of unchanged lines in the diff just to be sure that a new test is being added to the rigth array.
I propose we split the tests into files, one for each architecture. We can keep asm_test.go for the non-arch-specific tests, and for the helper functions and the codegen driver, and put the arrays with the tests in their own files named codegen_amd64_test.go, and so on.
The text was updated successfully, but these errors were encountered:
cmd/compile/internal/gc/asm_test.go
contains code generation tests for all architectures. The tests are grouped in very long arrays, one for each architecture. For example the amd64 codegen tests are inside an array namedlinuxAMD64Tests
spanning ~1500 lines of code (from 279 line to line 1770). All the architectures arrays are one after the other.Working on the file is slightly annoying because when writing, reading or grepping through it you can never tell inside which architecture's array you are, so I find myself constantly scrolling/jumping back in the file until I find the start of the array, where I can read the name of the variable that holds it and determine which architecture tests I'm looking at.
Reviewing changes to the file is also difficult, because a reviewer will need to expand potentially hundreds of unchanged lines in the diff just to be sure that a new test is being added to the rigth array.
I propose we split the tests into files, one for each architecture. We can keep
asm_test.go
for the non-arch-specific tests, and for the helper functions and the codegen driver, and put the arrays with the tests in their own files namedcodegen_amd64_test.go
, and so on.The text was updated successfully, but these errors were encountered: