Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Add regexpdynamicpattern linter: flag non-constant regexp compile patterns #50674
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
Uh oh!
There was an error while loading. Please reload this page.
Add regexpdynamicpattern linter: flag non-constant regexp compile patterns #50674
Changes from all commits
976cf4fb8af75a0a95123File filter
Filter by extension
Conversations
Uh oh!
There was an error while loading. Please reload this page.
Jump to
Uh oh!
There was an error while loading. Please reload this page.
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[/tdd]
regexp.CompilePOSIXandregexp.MustCompilePOSIXare not checked here, but they carry the same dynamic-pattern risk as their non-POSIX counterparts.💡 Suggested fix
Extend the name check:
Add testdata fixtures for the POSIX variants to keep the test specification complete.
@copilot please address this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[/tdd] The
len(call.Args) == 0guard is a good defensive check, but there is no test fixture verifying a zero-argument call toregexp.Compile()is silently skipped rather than crashing. Zero-arg calls are technically invalid Go code, but the analyzer should not panic on malformed ASTs under analysis.💡 Suggested test case
Since
analysistestruns against valid Go, add a comment in the testdata noting this guard and consider a brief unit-test that exerciseshasConstantStringPatterndirectly with a syntheticast.CallExpr{Args: nil}to document the invariant.@copilot please address this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Test coverage doesn't exercise the two false-positive scenarios the package doc explicitly claims to handle (aliased
regexpimport, shadowed local identifier namedregexp).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[/tdd] The testdata does not cover an aliased import of
regexp(e.g.import re "regexp"). The analyzer claims to handle aliased imports via type-checker resolution, but this case is not proven by a test fixture.💡 Suggested fixture additions
This would give confidence that
isRegexpCompileCallreally resolvespkgName.Imported().Path()correctly regardless of local alias.@copilot please address this.
Uh oh!
There was an error while loading. Please reload this page.