Skip to content

Fix another non module root #2744

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

Merged

Conversation

temyurchenko
Copy link
Contributor

@temyurchenko temyurchenko commented May 13, 2025

This fixes Unknown nodes that are created in ObjectModel without a parent. Furthermore, it forbids creation of Unknown nodes without a parent.

It also creates an xfailing test for #2743.

Type of Changes

Type
🐛 Bug fix
🔨 Refactoring

Description

Refs #2739, #2743.

Closes #120

Copy link
Member

@Pierre-Sassoulas Pierre-Sassoulas left a comment

Choose a reason for hiding this comment

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

Thank you for chiming in and investigating the root cause ! LGTM, just wondering if we should backport or wait for 4.0.

Comment on lines 4964 to 4969
def __init__(
self,
parent: NodeNG,
lineno: None = None,
col_offset: None = None,
parent: None = None,
*,
Copy link
Member

Choose a reason for hiding this comment

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

Should we consider this a breaking change ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You are right, it is.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

What is the procedure for handling this?

Copy link
Member

Choose a reason for hiding this comment

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

We'll wait for 4.0 to release it, and in astroid we just add a mildly strongly worded changelog entry. Or maybe we're not going to, I'm sure @DanielNoord will have an opinion about it :)

@@ -493,8 +493,8 @@ def __init__(self):
super().__init__()

@property
def attr___annotations__(self) -> node_classes.Unkown:
return node_classes.Unknown()
def attr___annotations__(self) -> node_classes.Unknown:
Copy link
Member

Choose a reason for hiding this comment

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

Nice catch, strange that this typo was not a problem anywhere.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

My local checker (not mypy, pyright) found other typing issues in that file. Maybe mypy isn't running on this file for whatever reason.

Copy link
Member

Choose a reason for hiding this comment

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

Yeah, mypy doesn't run on a lot of file at the moment. Lots of dynamic things that are very hard to type. I would have thought that actual import of something that does not exist would have been an error, but it seems it's not.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think it's due to from __future__ import annotations at the top. It makes python treat every annotation as a string. Without it, it would have been checked.

Copy link

codecov bot commented May 13, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 93.24%. Comparing base (97aac52) to head (db6a898).
Report is 1 commits behind head on main.

Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##             main    #2744      +/-   ##
==========================================
- Coverage   93.25%   93.24%   -0.01%     
==========================================
  Files          93       93              
  Lines       11072    11073       +1     
==========================================
  Hits        10325    10325              
- Misses        747      748       +1     
Flag Coverage Δ
linux 93.10% <100.00%> (-0.01%) ⬇️
pypy 93.24% <100.00%> (-0.01%) ⬇️
windows 93.22% <100.00%> (-0.01%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines Coverage Δ
astroid/interpreter/objectmodel.py 96.23% <100.00%> (ø)
astroid/nodes/node_classes.py 94.98% <100.00%> (+<0.01%) ⬆️
astroid/nodes/node_ng.py 92.33% <100.00%> (-0.31%) ⬇️
astroid/protocols.py 89.85% <100.00%> (ø)
🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@Pierre-Sassoulas
Copy link
Member

@DanielNoord release in 4.0.0 as breaking or backport in 3.3.11 ?

@DanielNoord
Copy link
Collaborator

I think back porting is fine :)

@Pierre-Sassoulas Pierre-Sassoulas merged commit e7a8669 into pylint-dev:main May 13, 2025
22 checks passed
Copy link
Contributor

The backport to maintenance/3.3.x failed:

The process '/usr/bin/git' failed with exit code 1

To backport manually, run these commands in your terminal:

# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-maintenance/3.3.x maintenance/3.3.x
# Navigate to the new working tree
cd .worktrees/backport-maintenance/3.3.x
# Create a new branch
git switch --create backport-2744-to-maintenance/3.3.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 e7a8669fcc586228ddb3774f9b6fc7ea184b98fe
# Push it to GitHub
git push --set-upstream origin backport-2744-to-maintenance/3.3.x
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-maintenance/3.3.x

Then, create a pull request where the base branch is maintenance/3.3.x and the compare/head branch is backport-2744-to-maintenance/3.3.x.

@temyurchenko temyurchenko deleted the fix-another-non-module-root branch May 13, 2025 22:42
@Pierre-Sassoulas Pierre-Sassoulas removed this from the 3.3.11 milestone May 14, 2025
@Pierre-Sassoulas
Copy link
Member

Sadly the fix can't be applied on 3.3.11 because SYNTHETIC_ROOT was added later and is not available on the maintenance branch.

@Pierre-Sassoulas Pierre-Sassoulas added this to the 4.0.0 milestone May 14, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Raise an error if .root() is not a module
3 participants