We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
Describe the bug If a local variable has the same name as an imported package, Semgrep mistakes the two. Please see the example issue below.
To Reproduce https://semgrep.dev/playground/s/j203Y
package main import ( testalias "fmt" ) func main() { _, fmt := testalias.Println("Hello, 世界") if fmt != nil { testalias.Println(fmt) } }
rules: - id: python-fstring languages: - go severity: ERROR message: Potential `$FOO` nil dereference when `$BAR` is called patterns: - pattern: | $FOO.$BAR(...) ... if $FOO != nil { ... }
Expected behavior I would expect no matches - the testalias.Println is called, but a completely independent fmt variable is checked againt nil.
testalias.Println
fmt
nil
With other name collisions Semgrep behaces as expected. See example here: https://semgrep.dev/playground/s/10e4w
package main import "fmt" var x = 1 func main() { fmt.Println(x) x := 2 fmt.Println(x, "x") }
rules: - id: python-fstring languages: - go severity: ERROR message: Matched $X patterns: - pattern: | fmt.Println($X) $X := ...
No matches. Semgrep figured out that the first $X in Println is different from the newly created variable.
$X
Println
What is the priority of the bug to you?
Use case This bug causes false positive with Trail of Bits nil-check-after-call rule.
nil-check-after-call
The text was updated successfully, but these errors were encountered:
No branches or pull requests
Describe the bug
If a local variable has the same name as an imported package, Semgrep mistakes the two. Please see the example issue below.
To Reproduce
https://semgrep.dev/playground/s/j203Y
Expected behavior
I would expect no matches - the
testalias.Println
is called, but a completely independentfmt
variable is checked againtnil
.With other name collisions Semgrep behaces as expected. See example here: https://semgrep.dev/playground/s/10e4w
No matches. Semgrep figured out that the first
$X
inPrintln
is different from the newly created variable.What is the priority of the bug to you?
Use case
This bug causes false positive with Trail of Bits
nil-check-after-call
rule.The text was updated successfully, but these errors were encountered: