8000 mypy lintrunner is wrong · Issue #133867 · pytorch/pytorch · GitHub
[go: up one dir, main page]
Skip to content

mypy lintrunner is wrong #133867

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
Closed
DeinAlptraum opened this issue Aug 19, 2024 · 5 comments
Closed

mypy lintrunner is wrong #133867

DeinAlptraum opened this issue Aug 19, 2024 · 5 comments
Labels
module: typing Related to mypy type annotations triaged This issue has been looked at a team member, and triaged and prioritized into an appropriate module

Comments

@DeinAlptraum
Copy link
Contributor
DeinAlptraum commented Aug 19, 2024 •
edited by pytorch-bot bot
Loading

🐛 Describe the bug

The mypy lintrunner currently misses some type errors. I do not know the extent of this problem but an example can be seen here. This is clearly wrong, sympy.expr does not exist, sympy.Expr is meant and I found this immedtiately the first time I ran mypy on the repo. However, running lintrunner locally did not produce any error, and moreover, after doing this once, the error does not show up anymore when directly running mypy either!
We can also see that the CI is green on #132937 which introduced the typing error.

Versions

Collecting environment information...
PyTorch version: 2.5.0.dev20240809
Is debug build: False
CUDA used to build PyTorch: Could not collect
ROCM used to build PyTorch: N/A

OS: Arch Linux (x86_64)
GCC version: (GCC) 14.2.1 20240805
Clang version: 18.1.8
CMake version: version 3.30.2
Libc version: glibc-2.40

Python version: 3.12.4 | packaged by Anaconda, Inc. | (main, Jun 18 2024, 15:12:24) [GCC 11.2.0] (64-bit runtime)
Python platform: Linux-6.10.3-arch1-2-x86_64-with-glibc2.40
Is CUDA available: False
CUDA runtime version: 12.5.82
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: GPU 0: NVIDIA GeForce RTX 3050 Laptop GPU
Nvidia driver version: 555.58.02
cuDNN version: Probably one of the following:
/usr/lib/libcudnn.so.9.2.1
/usr/lib/libcudnn_adv.so.9.2.1
/usr/lib/libcudnn_cnn.so.9.2.1
/usr/lib/libcudnn_engines_precompiled.so.9.2.1
/usr/lib/libcudnn_engines_runtime_compiled.so.9.2.1
/usr/lib/libcudnn_graph.so.9.2.1
/usr/lib/libcudnn_heuristic.so.9.2.1
/usr/lib/libcudnn_ops.so.9.2.1
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

CPU:
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 39 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Vendor ID: GenuineIntel
Model name: 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz
CPU family: 6
Model: 140
Thread(s) per core: 2
Core(s) per socket: 4
Socket(s): 1
Stepping: 1
CPU(s) scaling MHz: 45%
CPU max MHz: 4200.0000
CPU min MHz: 400.0000
BogoMIPS: 4840.00
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb cat_l2 cdp_l2 ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rdt_a avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb intel_pt avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves split_lock_detect user_shstk dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp hwp_pkg_req vnmi avx512vbmi umip pku ospke avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq rdpid movdiri movdir64b fsrm avx512_vp2intersect md_clear ibt flush_l1d arch_capabilities
Virtualization: VT-x
L1d cache: 192 KiB (4 instances)
L1i cache: 128 KiB (4 instances)
L2 cache: 5 MiB (4 instances)
L3 cache: 8 MiB (1 instance)
NUMA node(s): 1
NUMA node0 CPU(s): 0-7
Vulnerability Gather data sampling: Mitigation; Microcode
Vulnerability Itlb multihit: Not affected
Vulnerability L1tf: Not affected
Vulnerability Mds: Not affected
Vulnerability Meltdown: Not affected
Vulnerability Mmio stale data: Not affected
Vulnerability Reg file data sampling: Not affected
Vulnerability Retbleed: Not affected
Vulnerability Spec rstack overflow: Not affected
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2: Mitigation; Enhanced / Automatic IBRS; IBPB conditional; RSB filling; PBRSB-eIBRS SW sequence; BHI SW loop, KVM SW loop
Vulnerability Srbds: Not affected
Vulnerability Tsx async abort: Not affected

Versions of relevant libraries:
[pip3] audio2numpy==0.1.4
[pip3] mypy==1.10.0
[pip3] mypy-extensions==1.0.0
[pip3] numpy==2.0.1
[conda] blas 1.0 mkl
[conda] mkl 2023.1.0 h213fc3f_46344
[conda] numpy 2.0.1 pypi_0 pypi
[conda] pytorch-mutex 1.0 cpu pytorch-nightly

cc @ezyang @malfet @xuzhao9 @gramster
@malfet malfet added the module: typing Related to mypy type annotations label Aug 19, 2024
@Skylion007
Copy link
Collaborator

I think the issue might be the error code is inconsistent with dmypy @ezyang , I reran the same code with tons of type error for #133816 and had one PR green and then many more issues flagged on a later PR.

@soulitzer soulitzer added the triaged This issue has been looked at a team member, and triaged and prioritized into an appropriate module label Aug 20, 2024
@Skylion007
Copy link
Collaborator

@ezyang Any idea why aren't getting any coverage of these types?

@ezyang
Copy link
Contributor
ezyang commented Aug 21, 2024

I'm not convinced there is necessarily a problem here. In particular, when I checkout 2ad011c and run mypy torch/_inductor/codegen/simd.py I don't get any type error. But if I change sympy.expr to BLAHBLAH.expr I correctly get an error, even when I use dmypy.

>>> Lint for torch/_inductor/codegen/simd.py:                                                                                                  
                                                                                                                                               
  Error (MYPY) [name-defined]                                                                                                                  
    Name "BLAHBLAH" is not defined
                                   
        1782  |                for node in EnableReduction.filter(node_schedule)                                    
        1783  |                if isinstance(node, scheduler.SchedulerNode)
        1784  |            ]                                                                                                                   
    >>> 1785  |            new_tilings: OrderedSet[Tuple[BLAHBLAH.expr]] = OrderedSet()
        1786  |            for node_range in node_ranges:
        1787  |                # Collapse leading dims, to fit in the maximum dimensionality.
        1788  |                num_leading_dims = max(0, len(node_range) - config.triton.max_tiles)

What is likely happening is sympy is being treated as a missing import by mypy in some situations. Notably, we have

follow_imports = normal

[mypy-sympy]
ignore_missing_imports = True

[mypy-sympy.*]
ignore_missing_imports = True

in our config. I think if we want to fix this problem, we have to work out how to get mypy to reliably attempt to typecheck into sympy sources.

@DeinAlptraum
Copy link
Contributor Author

Fair point. Seems that was my mistake, because I somehow managed to get a Name "sympy.expr" is not defined error the first time I ran mypy on the repo. Still confused how that happened, because it shouldn't be possible. mypy doesn't check for missing names from unannotated modules (which is a bit counter-intuitive). I will probably open a PR to fix this specific annotation one of these days.
Closing this issue.

@DeinAlptraum
Copy link
Contributor Author

FYI: I recently got support for this feature merged into mypy, and it has been released in 1.14: python/mypy#17712

We should consider activating this, though it might significantly increase the runtime of our mypy check

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
module: typing Related to mypy type annotations triaged This issue has been looked at a team member, and triaged and prioritized into an appropriate module
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@ezyang @Skylion007 @malfet @soulitzer @DeinAlptraum
0