Currently we assume through Github CI that all the various cfg-permutations get touched and tested at some level.
This despite that github does not guarantee either what target arch / cpu features are available.
Wondering first if it would be feasible to check the codegen from these intrinistics so it stays as the expected / previously recorded / tested.
Secondly I would generally scan all the cfg-gates and maybe run some type of sanity / validation that the stuff under gets covered in the CI test-matrix.
This would catch any toolchain / build configurations where e.g. some bug deep down gets triggered only through some build gating and where the said code was not covered / tested etc.
ref: celabshq/libcrux#1255 (there was a bug hidden through a specific target_feature)
Currently we assume through Github CI that all the various cfg-permutations get touched and tested at some level.
This despite that github does not guarantee either what target arch / cpu features are available.
Wondering first if it would be feasible to check the codegen from these intrinistics so it stays as the expected / previously recorded / tested.
Secondly I would generally scan all the cfg-gates and maybe run some type of sanity / validation that the stuff under gets covered in the CI test-matrix.
This would catch any toolchain / build configurations where e.g. some bug deep down gets triggered only through some build gating and where the said code was not covered / tested etc.
ref: celabshq/libcrux#1255 (there was a bug hidden through a specific target_feature)