Add support for filtering printer output about slither HOT 6 OPEN

Just a heads up that we are likely moving towards subcommands and that work may conflict. We may be able to make the filter a global arg and pass that down to the detect command and print command as outlined here:

Instead of filter, maybe we can use exclude and include (or similar names, but that works in both directions). We can then use the same options for detectors and printers, so something like

--exclude-filenames / --include-filenames
--exclude-contracts / --include-contracts
--exclude-functions / --include-functions. Maybe with both support for f(..) and contract.f(..), so we work with top level functions, and can filter similar functions across contracts in case of inheritance

@shortdoom I've been thinking about a way to expose info in a way that's easier to query. If we replaced the printer table output with something more structured that can be parsed we can do something like the following. This example queries for writes to is_killed and can be combined with a logical operator to further filter the query like /-is_killed && Sends ETH: no/. Wdyt of this approach?

from slither.

regex is not needed, all of the listed information is available to slither as formatted py object (string) in either Function or Contract class.

i think the Issue could be generalized to better control over any output as slither relies extensively on prettyTable for formatting cli display and on the other hand complex json data type for output with --json flag. both of those have drawbacks when integrating with other external to slither scripts. amazingly, as much as Slither allows for easy integration directly with Class objects, it's output pipeline is pretty "hardcoded" from what I've seen

some middleware allowing for specifying custom ouput easily is good idea (say, simplified-json). either in form of a standalone method accessible from the core (by user or other slither classes) or as a separate util.

from slither.

hi @lucas-manuel 👋🏽

Great idea.

We have talked about making slither-printer it's own thing which could take some clargs for filtering as well as output options as @shortdoom suggests. Would also be nice to have a toggle for --fully-derived-contracts only, for example, for certain printers.

Making slither-printer a separate command is not a requirement to this but it would be cleaner than trying to tack on more clargs to the base slither command.

I can work on this when I have some time (soon ™️) or if someone else wants to take a shot at implementing this we can provide guidance.

from slither.

@lucas-manuel @devtooligan @0xalpharush

if you are fine with having this as a separate "tool" and not as a "printer", I can make a PR today, just green-light following logic and reasoning behind it:

• printers are built around Contract class and do not accept any args. it's a problem because some of the data needed is residing in the Function class. basically, how printers are structured disallows, without some changes of AbstractPrinter or creating new type of abstract interface, to implement "filtering printer" effectively. hence why the "tool" and not printer. tooling interface allows for multiple arguments and it's more relaxed.

example use case:

"Return all functions without get* at the start that are external, have external calls, don't have any modifiers, and modify state."

example input:

slither-function-filter contract.sol --viz external --ext-call 1 --modifier 0 --state 1

where,

1 or 0 for true/fals, if --ext-call 1 == include all functions that make AT LEAST 1 external call

returns:

functions matching criteria printed to cli (guidance as to this may be needed, i didn't spent that much time on Output class, PR will just print to cli initially)

from slither.

@shortdoom yes a tool would be totally fine with me, that sounds good!

from slither.

i made a "draft" PR. it doesn't include requested regex matching but it's straight forward to implement if needed. i followed existing implementation of parser without sub-commands for now as this is the current state of dev branch. regardless, I think slither-function-filter tool still can provide functionality above of (to be updated) output control of printers/detectors. search -> match -> print is the specific flow of this tool.

as for the better control of outputs, I'll comment in the referenced Issue after having some closer look. but I am of a biased opinion that Python API outputs should be prioritized over cli for restructuring. for larger codebases API integration is go-to solution over parsing cli output. for cli I think that standardization of output is enough - making output parsable ie. <name>:<value> - exactly as presented on the screenshot.

from slither.