Fix false positive for unused-import when disabling both used-before-assignment and undefined-variable

[DudeNr33]

• Add a ChangeLog entry describing what your PR does.
• If it's a new feature, or an important bug fix, add a What's New entry in
  doc/whatsnew/<current release.rst>.
• Write a good description on what the PR does.
• If you used multiple emails or multiple names when contributing, add your mails
  and preferred name in script/.contributors_aliases.json

Type of Changes

	Type
✓	🐛 Bug fix
	✨ New feature
	🔨 Refactoring
	📜 Docs

Description

This should fix the false positive reported in #6089 (yes I named my branch wrong 😉).
But as I am not very familar with this part of the code base, I would like to ask @jacobtylerwalls for a review if moving this check can have other side effects than just a small performance loss.
Test suite is passing locally.

Closes #6089

[jacobtylerwalls]

Great analysis. I think this condition and the instance variables it manages should just be deleted. Does it make sense to do it in a follow up PR or here?

If the check is moved even lower to leapfrog over the last CONTINUE action, then it's not accomplishing much. (Even _is_only_type_annotation() is good about short-circuiting.)

[coveralls]

Pull Request Test Coverage Report for Build 2085456668

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.001%) to 94.41%

---

Totals
Change from base Build 2085390512:	-0.001%
Covered Lines:	15537
Relevant Lines:	16457

---

💛 - Coveralls

[jacobtylerwalls]

I think this is unused now ⬇️

https://github.com/PyCQA/pylint/blob/5e1926e77fb5956f3776f7a75b18e809bce56a62/pylint/checkers/variables.py#L1093-L1095

[DudeNr33]

self._is_used_before_assignment_enabled has been removed with the latest commit.

[DudeNr33]

@Pierre-Sassoulas how do you handle backports?
Merge the current PR into main and then merge it manually also into the maintenance branch for 2.13?
Should I update the ChangeLog and whatsnew entry to include the change in the sections for 2.13.5 in this PR already?

[Pierre-Sassoulas]

how do you handle backports?

The full doc

TLDR we squash on the main branch so we only have to cherry-pick one commit on the maintenance branch later. (What is not said is that I cherry-pick everything in chronological order just before the release, so you can just label "Need backport", We could do it just after merging too)

Should I update the ChangeLog and whatsnew entry to include the change in the sections for 2.13.5 in this PR already?

Yes, in the current patch version 2.13.5 for the changelog and the whatsnew for 2.13.

[DudeNr33]

Thanks for the info! I have updated the ChangeLog and whatsnew/2.13.rst.
But I fear that something went wrong when I tried to merge the current main branch, as it now displays an awful lot of changed files...

[Pierre-Sassoulas]

I think it should be a rebase instead of a merge, it's probably fixable with git rebase origin/main.

[Pierre-Sassoulas]

You need to disregard what git is telling you when you're pushing and actually rewrite the history by using git push --force

[DudeNr33]

Thanks a ton, that did the trick. I'm still struggling with git sometimes... 😀

[DudeNr33]

Thanks @jacobtylerwalls, removed the entries for 2.14.

[Pierre-Sassoulas]

👍