[Misc][BE] Turn on strict type coverage for vllm/compilation

[Lucaskabela]

Purpose

This PR follows up

• [Misc][BE] Type coverage for vllm/compilation [3/3] #31748
• [Misc][BE] Type coverage for vllm/compilation [2/3] #31744
• [Misc][BE] Type coverage for vllm/compilation [1/3] #31554
  And adds strict type checking to our linter/pyproject.toml, turning it on in the compilation repo as a test pilot

Test Plan

mypy vllm/compilation

Test Result

Success: no issues found in 28 source files

---

Essential Elements of an Effective PR Description Checklist

• The purpose of the PR, such as "Fix some issue (link existing issues this PR will resolve)".
• The test plan, such as providing test command.
• The test results, such as pasting the results comparison before and after, or e2e results
• (Optional) The necessary documentation update, such as updating supported_models.md and examples for a new model.
• (Optional) Release notes update. If your change is user facing, please update the release notes draft in the Google Doc.

---

Note

Turns on strict mypy for vllm/compilation and updates pre-commit to run --strict on that directory.

• Adds [tool.mypy.overrides] for vllm.compilation.* in pyproject.toml (disallow untyped/incomplete defs, warn return any)
• Updates tools/pre_commit/mypy.py to detect strict paths and run separate mypy invocations for strict and non-strict groups
• Type-safety refactors across vllm/compilation/* (e.g., explicit variable annotations/returns, boolean casts, None handling, and targeted type: ignore on decorators/union attrs)
• No functional behavior changes; modifications are to satisfy strict typing

^{Written by Cursor Bugbot for commit 251bdb337dcd680d68673cd8755c230fb9e07862. This will update automatically on new commits. Configure here.}

---

Note

Turns on strict type checking for the compilation package and adapts tooling to enforce it.

• Adds mypy override for vllm.compilation.* in pyproject.toml (disallow untyped/incomplete defs, warn on Any returns)
• Updates tools/pre_commit/mypy.py to detect strict paths and run separate mypy invocations (--strict for vllm/compilation, non-strict elsewhere)
• Applies typing fixes in vllm/compilation/* (explicit annotations, temporary vars for returns, boolean casts, None checks, and scoped type: ignore on decorators/union attrs)

No functional behavior changes; changes are to satisfy stricter typing.

^{Written by Cursor Bugbot for commit 9e82cb8ae68eeb2f549c28a86c851178a5b7cfed. This will update automatically on new commits. Configure here.}

[gemini-code-assist]

Code Review

This pull request commendably enables strict mypy checking for the vllm/compilation module, a significant step towards improving code quality and maintainability. The changes are extensive and well-executed, adding necessary type hints and configurations. I have identified one area for improvement in vllm/compilation/decorators.py concerning the use of TypeVar, which, if addressed, would further enhance type safety and eliminate the need for several type: ignore suppressions.

[mergify]

This pull request has merge conflicts that must be resolved before it can be
merged. Please rebase the PR, @Lucaskabela.

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

[Lucaskabela]

note for reviewer: This is not strict = True because this would cause cascading strict imports to other modules from follow_imports when checked with pre-commit only

Instead we default to a few sensible options here

[ProExpertProg]

I see a ton of type[ignore]s - what are those for? Can we not fix them somehow? Because to me I think the noise of those ignores reduces the benefits of strict type checking

[ProExpertProg]

We should just use the utils for hashing here that we use for other compile_hash functions (I think sha256)

[Lucaskabela]

This should be the same util I believe (safe_hash)- we are just making the type checker happy by saying it is str type (since we run hexdigest()) and we reformat it due changing the line length

[Lucaskabela]

Gemini bot caught a good bug here - _T should be type[_T] since it is the cls type

[ProExpertProg]

how is this not already bool haha

[Lucaskabela]

with skip follow_imports mode, it gets treated as Any by type checker - I know it is a bit silly, but imo the benefits of having strict type checking outweighs the extra syntax

[zou3519]

seems reasonable to me. @ProExpertProg thoughts on having strict typing? I don't think we need to block on resolving the type ignores before turning on strict typing

[mergify]

Hi @Lucaskabela, the pre-commit checks have failed. Please run:

uv pip install pre-commit
pre-commit install
pre-commit run --all-files

Then, commit the changes and push to your branch.

For future commits, pre-commit will run automatically on changed files before each commit.

Tip

Is mypy or markdownlint failing?

mypy and markdownlint are run differently in CI. If the failure is related to either of these checks, please use the following commands to run them locally:

# For mypy (substitute "3.10" with the failing version if needed)
pre-commit run --hook-stage manual mypy-3.10
# For markdownlint
pre-commit run --hook-stage manual markdownlint

[hmellor]

May I ask, what is the purpose of enabling --strict typing here?

The current goal we have for mypy is to enable --follow-imports. Adding in this second access for strict makes this harder.