-
Notifications
You must be signed in to change notification settings - Fork 566
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
Go: Unable to match specific members within a struct initialization when using pattern-inside
#5452
Comments
This issue is synced in Linear at https://linear.app/r2c/issue/PA-1453/go-unable-to-match-specific-members-within-a-struct-initialization. Note: this link is for r2c use only and is not accessible publicly. |
Something like https://semgrep.dev/s/j44N should work---we probably don't try and parse a pattern as being a field right now, although we could change that if using a |
Oh thanks! I didn't think of this. I'll see how far I can go with this for now, but I definitely do think that this is important to fix, as narrowing scope as much as possible using |
We actually do parse the pattern as a field (see -dump_pattern with PartialSingleField). The problem is that the Composite Literal (the tls.Config {xxx}) is internally parsed as a function call with keyword arguments instead of a Record, |
Hmm I think it's because the composite literal can also be written with the "fields" unnamed as long as they are in the same order. |
This closes #5452 test plan: test file included
This closes #5452 test plan: test file included
Describe the bug
I'm having trouble matching specific
MemberName: Value
pairs when using apattern-inside
along with apattern
to match specific members of a struct.To Reproduce
https://semgrep.dev/s/68B1
While playing around with it, I noticed that you can match the
MemberName
s, such asServerName
orInsecureSkipVerify
, but not theValue
s orMemberName: Value
pairs.Expected behavior
The
InsecureSkipVerify: true
should matchWhat is the priority of the bug to you?
Use case
Allow me to write more detailed Go rules
The text was updated successfully, but these errors were encountered: