Feature request: Customisation of which passes run.

[vext01]

Hi again David,

Today I was reducing a Lua program which contained a loop like:

...
for A = 0, 100 do
  D:D()
end
...

And the loop bound 100 is important: it was selected because is a value under which the non-deterministic bug I am tracking down is quite frequent.

Shrinkray managed to reduce the file some, but it had replaced 100 with 66, thus making the bug less likely to trigger.

To solve this hackily, I commented out the pass that rewrites integer literals (inside the shrinkray source code in my virtualenv).

Have you considered making the pass "pipeline" user-configurable somehow? Maybe a config file and a tool to generate a default config file with all passes initially enabled? Or maybe --disable-<thepass> arguments? I'm not really sure what would be most user-friendly.

Again: great tool. Thanks for writing it. I've started using it exclusively, instead of cvise.

Cheers

[DRMacIver]

I'm not completely against the feature, but I feel like it's sortof... spiritually against how I want shrinkray to work. The ideal is that shrinkray should always be able to reduce things freely, and I'll often want to add new passes, and passes might have unexpected consequences. e.g. if you had something like:

for A = 0, 66 do
  // something unrelated and deletable
end

for A = 0, 100 do
  D:D()
end

Then shrinkray might get to the same reduction without that pass.

So I don't think disabling passes is a good way to achieve this.

I think the two sorts of changes I'd be more inclined to support something like this:

1. Just modify your interestingness test to require the string for A = 0, 100 do to appear in the test case.
2. Changes to shrinkray to get it to better handle nondeterministic interestingness tests, so it controls how many times to run itself.