Consider options --interesting-exit-code and --interesting-stderr.
Right now the reduction is considered to be interesting when either condition matches:
|
let is_interesting = (interesting_code || stdout_match || stderr_match) |
Suppose I'm tracking a specific compiler crash, I would pass --interesting-stderr my-error and don't specify any interesting exit code. This leaves it at a default value of 0 and treereduce-rust quickly reduces the example to empty file - "code 0 is interesting" according to default command line options.
Next attempt is me passing an expected exit code along with interesting stderr, but this can lead to minimization for some other compiler crash.
As a result to track a specific crash I need to pass --interesting-stderr my-error as well as --interesting-exit-code 12345 - some exit code that doesn't match.
There's several ways to solve it, least confusing would be to get rid of default code of 0 and ask user to specify at least one interesting criteria - exit code or regexp.
Consider options
--interesting-exit-codeand--interesting-stderr.Right now the reduction is considered to be interesting when either condition matches:
treereduce/crates/treereduce/src/check.rs
Line 228 in 15e338b
Suppose I'm tracking a specific compiler crash, I would pass
--interesting-stderr my-errorand don't specify any interesting exit code. This leaves it at a default value of 0 andtreereduce-rustquickly reduces the example to empty file - "code 0 is interesting" according to default command line options.Next attempt is me passing an expected exit code along with interesting stderr, but this can lead to minimization for some other compiler crash.
As a result to track a specific crash I need to pass
--interesting-stderr my-erroras well as--interesting-exit-code 12345- some exit code that doesn't match.There's several ways to solve it, least confusing would be to get rid of default code of 0 and ask user to specify at least one interesting criteria - exit code or regexp.