Hi Greg and Sasha,
On Sat, 10 Jun 2023 17:56:18 +0000 SeongJae Park sj@kernel.org wrote:
On Sat, 10 Jun 2023 12:15:55 +0800 David Gow davidgow@google.com wrote:
[-- Attachment #1: Type: text/plain, Size: 2275 bytes --]
On Sat, 10 Jun 2023 at 03:09, SeongJae Park sj@kernel.org wrote:
Hi David and Brendan,
On Tue, 2 May 2023 08:04:20 +0800 David Gow davidgow@google.com wrote:
[-- Attachment #1: Type: text/plain, Size: 1473 bytes --]
On Tue, 2 May 2023 at 02:16, 'Daniel Latypov' via KUnit Development kunit-dev@googlegroups.com wrote:
Writing `subprocess.Popen[str]` requires python 3.9+. kunit.py has an assertion that the python version is 3.7+, so we should try to stay backwards compatible.
This conflicts a bit with commit 1da2e6220e11 ("kunit: tool: fix pre-existing `mypy --strict` errors and update run_checks.py"), since mypy complains like so
kunit_kernel.py:95: error: Missing type parameters for generic type "Popen" [type-arg]
Note: `mypy --strict --python-version 3.7` does not work.
We could annotate each file with comments like `# mypy: disable-error-code="type-arg" but then we might still get nudged to break back-compat in other files.
This patch adds a `mypy.ini` file since it seems like the only way to disable specific error codes for all our files.
Note: run_checks.py doesn't need to specify `--config_file mypy.ini`, but I think being explicit is better, particularly since most kernel devs won't be familiar with how mypy works.
Fixes: 695e26030858 ("kunit: tool: add subscripts for type annotations where appropriate") Reported-by: SeongJae Park sj@kernel.org Link: https://lore.kernel.org/linux-kselftest/20230501171520.138753-1-sj@kernel.or... Signed-off-by: Daniel Latypov dlatypov@google.com
Thanks for jumping on this.
Looks good to me!
Reviewed-by: David Gow davidgow@google.com
Looks like this patch is still not merged in the mainline. May I ask the ETA, or any concern if you have?
We've got this queued for 6.5 in the kselftest/kunit tree[1], so it should land during the merge window. But I'll look into getting it applied as a fix for 6.4, beforehand.
Thank you for the kind answer, Gow! I was thinking this would be treated as a fix, and hence merged into the mainline before next merge window. I'm actually getting my personal test suite failures due to absence of this fix. It's not a critical problem, but it would definitely better for me if this could be merged into the mainline as early as possible.
This patch is now in the mainline (e30f65c4b3d671115bf2a9d9ef142285387f2aff). However, this fix is not in 6.4.y yet, so the original issue is reproducible on 6.4.y. Could you please add this to 6.4.y? I confirmed the mainline commit can cleanly applied on latest 6.1.y tree, and it fixes the issue.
Thanks, SJ
Thanks, SJ
-- David