Fix python.lang.correctness.baseclass-attribute-override #3434
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The rule depended on Semgrep unifying two identifiers, corresponding to methods in two different classes, that were not the same but just had the same "string" name.
semgrep-ci bot
pushed a commit
to semgrep/semgrep
that referenced
this pull request
Jul 22, 2024
…emgrep/semgrep-proprietary#1877) Applying name equivalences on a global id forks matching, trying all its "alternate names", while erasing the id_info. We were applying equivalences right away, before even knowing if it was required. If a metavariable matched a global id, instead of being just bound to that global id, it ended up bound multiple times with each one of the alternate names (with no id_info). In #1751 we added the `semgrep-internal-metavariable-name` operator, and its implementation required some "hacks" partly because of this issue. Ideally, we analyze the sources and record a set of `Name.t`s of our interest, then we just check if `...-metavariable-name` binds to one of those `Name.t`s. But this doesn't work because `...-metavariable-name` was binding to plain strings without id_info. This should enable us to clean up #1751. Closes CODE-7336 As a side-effect, Semgrep was unifying different global ids that just happened to have the same string name, and I had to fix one rule that was relying on this behavior: semgrep/semgrep-rules#3434. For backwards compatibility I added the `unify_ids_strictly` option, which can be disabled to unify ids ignoring their id_info. The option could remain undocumented/experimental for now, the best way to write those rules is probably as we did in semgrep/semgrep-rules#3434, by using two different metavariables and then comparing them like `comparison: str($X) == str($Y)`. test plan: SEMGREP_LOG_SRCS=semgrep.matching bin/semgrep-core-proprietary -deep_inter_file \ -lang python -e '$FLASK(__name__)' OSS/tests/rules//sym_prop_decorator.py -debug #^ This now produces one match instead of two, and via -debug it can be checked #^ that we now bind $FLASK with the id `flask` preserving its id_info. synced from Pro 8ed835e5a9f692f49c9a227bad500b0f00751e3c
semgrep-ci bot
pushed a commit
to semgrep/semgrep
that referenced
this pull request
Jul 23, 2024
…emgrep/semgrep-proprietary#1877) Applying name equivalences on a global id forks matching, trying all its "alternate names", while erasing the id_info. We were applying equivalences right away, before even knowing if it was required. If a metavariable matched a global id, instead of being just bound to that global id, it ended up bound multiple times with each one of the alternate names (with no id_info). In #1751 we added the `semgrep-internal-metavariable-name` operator, and its implementation required some "hacks" partly because of this issue. Ideally, we analyze the sources and record a set of `Name.t`s of our interest, then we just check if `...-metavariable-name` binds to one of those `Name.t`s. But this doesn't work because `...-metavariable-name` was binding to plain strings without id_info. This should enable us to clean up #1751. Closes CODE-7336 As a side-effect, Semgrep was unifying different global ids that just happened to have the same string name, and I had to fix one rule that was relying on this behavior: semgrep/semgrep-rules#3434. For backwards compatibility I added the `unify_ids_strictly` option, which can be disabled to unify ids ignoring their id_info. The option could remain undocumented/experimental for now, the best way to write those rules is probably as we did in semgrep/semgrep-rules#3434, by using two different metavariables and then comparing them like `comparison: str($X) == str($Y)`. test plan: SEMGREP_LOG_SRCS=semgrep.matching bin/semgrep-core-proprietary -deep_inter_file \ -lang python -e '$FLASK(__name__)' OSS/tests/rules//sym_prop_decorator.py -debug #^ This now produces one match instead of two, and via -debug it can be checked #^ that we now bind $FLASK with the id `flask` preserving its id_info. synced from Pro 8ed835e5a9f692f49c9a227bad500b0f00751e3c
semgrep-ci bot
pushed a commit
to semgrep/semgrep
that referenced
this pull request
Jul 24, 2024
…emgrep/semgrep-proprietary#1877) Applying name equivalences on a global id forks matching, trying all its "alternate names", while erasing the id_info. We were applying equivalences right away, before even knowing if it was required. If a metavariable matched a global id, instead of being just bound to that global id, it ended up bound multiple times with each one of the alternate names (with no id_info). In #1751 we added the `semgrep-internal-metavariable-name` operator, and its implementation required some "hacks" partly because of this issue. Ideally, we analyze the sources and record a set of `Name.t`s of our interest, then we just check if `...-metavariable-name` binds to one of those `Name.t`s. But this doesn't work because `...-metavariable-name` was binding to plain strings without id_info. This should enable us to clean up #1751. Closes CODE-7336 As a side-effect, Semgrep was unifying different global ids that just happened to have the same string name, and I had to fix one rule that was relying on this behavior: semgrep/semgrep-rules#3434. For backwards compatibility I added the `unify_ids_strictly` option, which can be disabled to unify ids ignoring their id_info. The option could remain undocumented/experimental for now, the best way to write those rules is probably as we did in semgrep/semgrep-rules#3434, by using two different metavariables and then comparing them like `comparison: str($X) == str($Y)`. test plan: SEMGREP_LOG_SRCS=semgrep.matching bin/semgrep-core-proprietary -deep_inter_file \ -lang python -e '$FLASK(__name__)' OSS/tests/rules//sym_prop_decorator.py -debug #^ This now produces one match instead of two, and via -debug it can be checked #^ that we now bind $FLASK with the id `flask` preserving its id_info. synced from Pro 8ed835e5a9f692f49c9a227bad500b0f00751e3c
semgrep-ci bot
pushed a commit
to semgrep/semgrep
that referenced
this pull request
Jul 24, 2024
…emgrep/semgrep-proprietary#1877) Applying name equivalences on a global id forks matching, trying all its "alternate names", while erasing the id_info. We were applying equivalences right away, before even knowing if it was required. If a metavariable matched a global id, instead of being just bound to that global id, it ended up bound multiple times with each one of the alternate names (with no id_info). In #1751 we added the `semgrep-internal-metavariable-name` operator, and its implementation required some "hacks" partly because of this issue. Ideally, we analyze the sources and record a set of `Name.t`s of our interest, then we just check if `...-metavariable-name` binds to one of those `Name.t`s. But this doesn't work because `...-metavariable-name` was binding to plain strings without id_info. This should enable us to clean up #1751. Closes CODE-7336 As a side-effect, Semgrep was unifying different global ids that just happened to have the same string name, and I had to fix one rule that was relying on this behavior: semgrep/semgrep-rules#3434. For backwards compatibility I added the `unify_ids_strictly` option, which can be disabled to unify ids ignoring their id_info. The option could remain undocumented/experimental for now, the best way to write those rules is probably as we did in semgrep/semgrep-rules#3434, by using two different metavariables and then comparing them like `comparison: str($X) == str($Y)`. test plan: SEMGREP_LOG_SRCS=semgrep.matching bin/semgrep-core-proprietary -deep_inter_file \ -lang python -e '$FLASK(__name__)' OSS/tests/rules//sym_prop_decorator.py -debug #^ This now produces one match instead of two, and via -debug it can be checked #^ that we now bind $FLASK with the id `flask` preserving its id_info. synced from Pro 8ed835e5a9f692f49c9a227bad500b0f00751e3c
aryx
pushed a commit
to semgrep/semgrep
that referenced
this pull request
Jul 24, 2024
…emgrep/semgrep-proprietary#1877) Applying name equivalences on a global id forks matching, trying all its "alternate names", while erasing the id_info. We were applying equivalences right away, before even knowing if it was required. If a metavariable matched a global id, instead of being just bound to that global id, it ended up bound multiple times with each one of the alternate names (with no id_info). In #1751 we added the `semgrep-internal-metavariable-name` operator, and its implementation required some "hacks" partly because of this issue. Ideally, we analyze the sources and record a set of `Name.t`s of our interest, then we just check if `...-metavariable-name` binds to one of those `Name.t`s. But this doesn't work because `...-metavariable-name` was binding to plain strings without id_info. This should enable us to clean up #1751. Closes CODE-7336 As a side-effect, Semgrep was unifying different global ids that just happened to have the same string name, and I had to fix one rule that was relying on this behavior: semgrep/semgrep-rules#3434. For backwards compatibility I added the `unify_ids_strictly` option, which can be disabled to unify ids ignoring their id_info. The option could remain undocumented/experimental for now, the best way to write those rules is probably as we did in semgrep/semgrep-rules#3434, by using two different metavariables and then comparing them like `comparison: str($X) == str($Y)`. test plan: SEMGREP_LOG_SRCS=semgrep.matching bin/semgrep-core-proprietary -deep_inter_file \ -lang python -e '$FLASK(__name__)' OSS/tests/rules//sym_prop_decorator.py -debug #^ This now produces one match instead of two, and via -debug it can be checked #^ that we now bind $FLASK with the id `flask` preserving its id_info. synced from Pro 8ed835e5a9f692f49c9a227bad500b0f00751e3c
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The rule depended on Semgrep unifying two identifiers, corresponding to methods in two different classes, that were not the same but just had the same "string" name.