Confusing behavior between interesting exit code and interesting regexp, at least with treereduce-rust

[pacak]

Consider options --interesting-exit-code and --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

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.

[langston-barrett]

Hey, thanks for the report! I agree that this is confusing.

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.

I agree that this would be very clear, but it would unfortunately make the CLI a bit more verbose, and less analogous with that of Halfempty.

Perhaps instead, we could have each interestingness condition be an Option, and && the Somes together, only falling back to the exit code of 0 when all of them are None?

[pacak]

Perhaps instead, we could have each interestingness condition be an Option, and && the Somes together, only falling back to the exit code of 0 when all of them are None?

Yea, this would work as well. "Default interesting exit code is 0 unless there are other criterias".