Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a way to debug rules #98

Closed
quasilyte opened this issue Oct 25, 2020 · 0 comments
Closed

Add a way to debug rules #98

quasilyte opened this issue Oct 25, 2020 · 0 comments
Assignees

Comments

@quasilyte
Copy link
Owner

quasilyte commented Oct 25, 2020

It's especially important to have a mechanism to debug how the rule is being executed, what types submatches have, etc.

Suppose we have a rule file like this:

package gorules
import "github.com/quasilyte/go-ruleguard/dsl/fluent"
func unslice(m fluent.Matcher) {
  m.Match(`$s[:]`).Where(m["s"].Type.Is(`string`)).Suggest(`$s`)
}

And a test Go file like this:

package example

func f(s string, a [10]int, b []byte) {
  _ = a[:] // no match
  _ = b[:] // no match
  _ = s[1:] // no match
  _ = s[:] // match
}

Debug output could look like:

$ ruleguard -debug-group unslice -rules rules.go example.go 
example.go:4: rejected ($s type filter)
  $s [10]int: a
example.go:5: rejected ($s type filter)
  $s []byte: b
example.go:7:6: suggestion: s

package gorules

import "github.com/quasilyte/go-ruleguard/dsl/fluent"

func gocriticArgOrder(m fluent.Matcher) {
	m.Match(`strings.HasPrefix($s1, $s2)`).
		Where(m["s1"].Const && !m["s2"].Const).
		Suggest(`strings.HasPrefix($s2, $s1)`)
}
package example

import "strings"

func _(v1, v2 string) {
	strings.HasPrefix("", "")
	strings.HasPrefix(v1, v2)
	strings.HasPrefix("", v2)
	strings.HasPrefix(v1, "")
}
$ ruleguard -debug-group gocriticArgOrder -rules rules2.go example2.go 
example2.go:6: rejected ($s2 is const)
  $s1 string: ""
  $s2 string: ""
example2.go:7: rejected ($s1 is not const)
  $s1 string: v1
  $s2 string: v2
example2.go:9: rejected ($s2 is const)
  $s1 string: v1
  $s2 string: ""
example2.go:8:2: suggestion: strings.HasPrefix(v2, "")
@quasilyte quasilyte self-assigned this Oct 29, 2020
quasilyte added a commit that referenced this issue Oct 30, 2020
When ruleguard is called with -debug-group=<string> arg,
it'll print rejected matches explanations to the stderr
for the specified rules group.

By default, this argument is an empty string that means "no debug".

Explanation includes:

	* Submatch nodes (with types)
	* Rejection reason (sometimes approx)
	* Rejected node location

Here is an example of how explanations can look like:

	example.go:4: rejected ($s type filter)
	  $s [10]int: a

	example2.go:9: rejected ($s2 is const)
	  $s1 string: v1
	  $s2 string: ""

	example2.go:7: rejected ($s1 is not const)
	  $s1 string: v1
	  $s2 string: v2

The debug output format is experimental and can change over time.
Any feedback is appreciated.

Refs #98

Signed-off-by: Iskander Sharipov <[email protected]>
quasilyte added a commit that referenced this issue Oct 30, 2020
When ruleguard is called with -debug-group=<string> arg,
it'll print rejected matches explanations to the stderr
for the specified rules group.

By default, this argument is an empty string that means "no debug".

Explanation includes:

	* Submatch nodes (with types)
	* Rejection reason (sometimes approx)
	* Rejected node location

Here is an example of how explanations can look like:

	example.go:4: rejected ($s type filter)
	  $s [10]int: a

	example2.go:9: rejected ($s2 is const)
	  $s1 string: v1
	  $s2 string: ""

	example2.go:7: rejected ($s1 is not const)
	  $s1 string: v1
	  $s2 string: v2

The debug output format is experimental and can change over time.
Any feedback is appreciated.

Refs #98

Signed-off-by: Iskander Sharipov <[email protected]>
quasilyte added a commit that referenced this issue Oct 30, 2020
When ruleguard is called with -debug-group=<string> arg,
it'll print rejected matches explanations to the stderr
for the specified rules group.

By default, this argument is an empty string that means "no debug".

Explanation includes:

	* Submatch nodes (with types)
	* Rejection reason (sometimes approx)
	* Rejected node location

Here is an example of how explanations can look like:

	example.go:4: rejected ($s type filter)
	  $s [10]int: a

	example2.go:9: rejected ($s2 is const)
	  $s1 string: v1
	  $s2 string: ""

	example2.go:7: rejected ($s1 is not const)
	  $s1 string: v1
	  $s2 string: v2

The debug output format is experimental and can change over time.
Any feedback is appreciated.

Refs #98

Signed-off-by: Iskander Sharipov <[email protected]>
quasilyte added a commit that referenced this issue Oct 30, 2020
When ruleguard is called with -debug-group=<string> arg,
it'll print rejected matches explanations to the stderr
for the specified rules group.

By default, this argument is an empty string that means "no debug".

Explanation includes:

	* Submatch nodes (with types)
	* Rejection reason (sometimes approx)
	* Rejected node location

Here is an example of how explanations can look like:

	example.go:4: rejected ($s type filter)
	  $s [10]int: a

	example2.go:9: rejected ($s2 is const)
	  $s1 string: v1
	  $s2 string: ""

	example2.go:7: rejected ($s1 is not const)
	  $s1 string: v1
	  $s2 string: v2

The debug output format is experimental and can change over time.
Any feedback is appreciated.

This change also adds Line:int and Group:string fields to the rules info.

	Line is a rules file line that declared this rule
	Group is a containing function name

Refs #98

Signed-off-by: Iskander Sharipov <[email protected]>
quasilyte added a commit that referenced this issue Oct 30, 2020
When ruleguard is called with -debug-group=<string> arg,
it'll print rejected matches explanations to the stderr
for the specified rules group.

By default, this argument is an empty string that means "no debug".

Explanation includes:

	* Submatch nodes (with types)
	* Rejection reason (sometimes approx)
	* Rejected node location

Here is an example of how explanations can look like:

	example.go:4: rejected by rules.go:6 ($s type filter)
	  $s [10]int: a

	example2.go:9: rejected rules2.go:8 ($s2 is const)
	  $s1 string: v1
	  $s2 string: ""

	example2.go:7: rejected rules2.go:8 ($s1 is not const)
	  $s1 string: v1
	  $s2 string: v2

The debug output format is experimental and can change over time.
Any feedback is appreciated.

This change also adds Line:int and Group:string fields to the rules info.

	Line is a rules file line that declared this rule
	Group is a containing function name

Refs #98

Signed-off-by: Iskander Sharipov <[email protected]>
quasilyte added a commit that referenced this issue Oct 30, 2020
When ruleguard is called with -debug-group=<string> arg,
it'll print rejected matches explanations to the stderr
for the specified rules group.

By default, this argument is an empty string that means "no debug".

Explanation includes:

	* Submatch nodes (with types)
	* Rejection reason (sometimes approx)
	* Rejected node location

Here is an example of how explanations can look like:

	example.go:4: rejected by rules.go:6 ($s type filter)
	  $s [10]int: a

	example2.go:9: rejected rules2.go:8 ($s2 is const)
	  $s1 string: v1
	  $s2 string: ""

	example2.go:7: rejected rules2.go:8 ($s1 is not const)
	  $s1 string: v1
	  $s2 string: v2

The debug output format is experimental and can change over time.
Any feedback is appreciated.

This change also adds Line:int and Group:string fields to the rules info.

	Line is a rules file line that declared this rule
	Group is a containing function name

Refs #98

Signed-off-by: Iskander Sharipov <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant