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.

Sign up for GitHub

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

Jump to bottom

SONARPY-2345 Document new S1172 FN when super class is ambiguous #2164

Merged
merged 2 commits into from
Nov 19, 2024
Merged

SONARPY-2345 Document new S1172 FN when super class is ambiguous #2164

merged 2 commits into from
Nov 19, 2024

Conversation

thomas-serre-sonarsource
Copy link
Contributor

@thomas-serre-sonarsource thomas-serre-sonarsource commented Nov 18, 2024 •
edited by jira bot
Loading

SONARPY-2345

Part of

guillaume-dequenne-sonarsource
guillaume-dequenne-sonarsource approved these changes Nov 19, 2024
View reviewed changes
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good!
As mentioned in the comment, the root cause of the problem already has a dedicated ticket, so I'm not entirely sure of the value of this new one.

...on-checks/src/test/resources/checks/unusedFunctionParameter/unusedFunctionParameterImport.py Outdated

class ChildFromDuplicated(ParentWithDuplicatedParent):

def do_something(self, a): # FN SONARPY-2347 ChildFromDuplicated has an unresolved type hierarchy, because of the duplicated parent classes
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is a consequence of SONARPY-1829: DuplicatedParent, being a class, is not propagated like other types. In unusedFunctionParameterImported.py, the hierarchy of ParentWithDuplicatedParent should be clearly defined, as the second definition of DuplicatedParent always overrides the first one.
I'm not sure we need SONARPY-2347 as a result. Now that it's here, we can probably mark it as blocked by SONARPY-1829 though (or just add the example in SONARPY-1829 and archive SONARPY-2347 as duplicate).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright! I canceled the SONARPY-2347 and changed the reference in the unit test to SONARPY-1829. Thanks for noticing it!

@sonarqube-next SonarQube-Next
Copy link

Quality Gate passed Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarQube

@thomas-serre-sonarsource thomas-serre-sonarsource merged commit 1df1fc5 into master Nov 19, 2024
10 of 11 checks passed
@thomas-serre-sonarsource thomas-serre-sonarsource deleted the ts/SONARPY-2345 branch November 19, 2024 16:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@guillaume-dequenne-sonarsource guillaume-dequenne-sonarsource guillaume-dequenne-sonarsource approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@thomas-serre-sonarsource @guillaume-dequenne-sonarsource