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
Opposite of --filter-paths. Slither will only be run on paths matching the regex values of this --include-paths clarg. Or maybe it's "only-include-paths" for clarity. Maybe it should throw if user selects both include-paths and filter-paths as it doesn't seem like it would be needed and it can be difficult to try and incorporate both.
This is useful, for example on an audit of a large repo but the scope is only on certain files.
As a hack, I just altered the current behavior of --filter-paths and it worked as I had hoped:
The text was updated successfully, but these errors were encountered:
As a workaround in the meantime, we can use the regex ^(?!.*<target>) to filter out anything that doesn't start with our target path
eg --filter-paths='^(?!.*the/only/path/i/care/about),tests' will filter out everything that is not inside the/only/path/i/care/about and also filter out the/only/path/i/care/about/tests
Describe the desired feature
Opposite of
--filter-paths
. Slither will only be run on paths matching the regex values of this--include-paths
clarg. Or maybe it's "only-include-paths" for clarity. Maybe it should throw if user selects both include-paths and filter-paths as it doesn't seem like it would be needed and it can be difficult to try and incorporate both.This is useful, for example on an audit of a large repo but the scope is only on certain files.
As a hack, I just altered the current behavior of --filter-paths and it worked as I had hoped:
The text was updated successfully, but these errors were encountered: