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.

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

Code cleanups from running type checking lints #11938

Merged
merged 7 commits into from
Jul 20, 2023

Conversation

eli-schwartz
Copy link
Member

  • refactor to allow mypy to actually check some code
  • move more mypy-only imports into TYPE_CHECKING blocks
  • enable a new mypy error category

@@ -2068,7 +2068,7 @@ def _generate_deps(self, state: 'ModuleState', library: str, packages: T.List[st
ofile.write(package + '\n')
return build.Data([mesonlib.File(True, outdir, fname)], install_dir, install_dir, mesonlib.FileMode(), state.subproject)

def _get_vapi_link_with(self, target: build.CustomTarget) -> T.List[build.LibTypes]:
def _get_vapi_link_with(self, target: CustomTarget) -> T.List[build.LibTypes]:
Copy link
Contributor

Choose a reason for hiding this comment

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

Seems like you could remove the build from build.LibTypes here too.

Copy link
Member Author

@eli-schwartz eli-schwartz Jul 5, 2023

Choose a reason for hiding this comment

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

Technically yes, but also not really. It could be done if that also gets imported at the top level, which it currently isn't.

What I did so far is remove build. from any objects that were already imported anyway, since in all those cases we might as well use it now that we went to all the effort of importing it.

@eli-schwartz
Copy link
Member Author

Yeah, looks like functools.singledispatch actually uses type annotations at runtime, similar to pydantic, so while PEP 563 postponed evaluation is totally fine, not importing the module is a problem. I can roll back that specific import.

@tristan957
Copy link
Contributor

Looks like this PR will eventually conflict with the one that I just opened :(

@xclaesse
Copy link
Member

There are now conflicts and CI has issues, but other than that, LGTM.

A linker mixin has to be able to align with the base linker it will be
used for, in order to reference super(). Since they weren't inherited,
calls to super() resulted in mypy errors, which we ignored, and casting.

Use the same trick we use for compilers, and make the linker inherit
from the base linker type when running under mypy, and from object at
runtime.
These don't have new errors or old ignored ones, but add them anyway so
we can generally validate their sanity.
This detects cases where module A imports a function from B, and C
imports that same function from A instead of B. It's not part of the API
contract of A, and causes innocent refactoring to break things.
We already import a bunch of objects directly from ..build but don't use
them nearly as much as we can. This resulted both in longer lines and s
minor performance difference since python has to resolve the name
binding the long way. There's no reason not to rewrite these names to
use the direct imports.

Found while investigating the fact that Executable was imported but
never used. It's easier to just use it.
Mostly detected with flake8-type-checking. Also quote T.cast() first
arguments, since those are not affected by future annotations.
@eli-schwartz eli-schwartz merged commit 0bb1647 into mesonbuild:master Jul 20, 2023
@eli-schwartz eli-schwartz deleted the type-checking-lints branch July 20, 2023 01:57
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.

4 participants