[CI] change spell checker from codespell to typos

[andyxning]

Currently, codespell can not help in finding all possible typos. According to this comparison, it seems typos has more good performance and correctness. typos also supports both pre-commit and Github actions.

[github-actions[bot]]

👋 Hi! Thank you for contributing to the vLLM project.

💬 Join our developer Slack at https://slack.vllm.ai to discuss your PR in #pr-reviews, coordinate on features in #feat- channels, or join special interest groups in #sig- channels.

Just a reminder: PRs would not trigger full CI run by default. Instead, it would only run fastcheck CI which starts running only a small and essential subset of CI tests to quickly catch errors. You can run other CI tests on top of those by going to your fastcheck build on Buildkite UI (linked in the PR checks section) and unblock them. If you do not have permission to unblock, ping simon-mo or khluu to add you in our Buildkite org.

Once the PR is approved and ready to go, your PR reviewer(s) can run CI to test the changes comprehensively before merging.

To run CI, PR reviewers can either: Add ready label to the PR or enable auto-merge.

🚀

[DarkLight1337]

@mgoin can you verify that the changes to the kernels are OK?

[andyxning]

Overall this looks reasonable to me. Can you remove the codespell config from pyproject.toml?

@DarkLight1337 Done.

[andyxning]

I think it will be annoying and error-prone if developers need to define functional exceptions like this during their work

Yes. this is true. Some trade-off needs to be done if we decide to apply this PR.

[mergify[bot]]

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

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

[andyxning]

It seems that most special escapes in spell checking are about cuda and nvml.

https://github.com/vllm-project/vllm/pull/18711/files#diff-51afc5d77bc899fd07f13239bccc4c8042af7062b994c4ce493d8123f905f5a4R21-R48

Other changes in this PR are clean and clear enough. There are two options about this spell check change to the later developing overhead:

1. ignore checking all the c++ and nvml related files. This should make most special escapes deleted and has the lowest overhead for developing the project laterly.
2. keep current special escapes and make them maintained as needed in the later developing phase. This will involve some manual operations, but since the codebase has been analysed and most special escapes has been discovered, the manual operations overhead depends on the develop frequencies in cuda and nvml related code. This should be not so much, imho. Correct me if i am wrong.

So, i prefer option 2.

/cc @mgoin

[mergify[bot]]

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

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

[andyxning]

/cc @DarkLight1337 @mgoin

[mergify[bot]]

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

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

[mergify[bot]]

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

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

[andyxning]

Some ci test about speculative decoding still failed, will fix it asap.

[mgoin]

@andyxning that test is unrelated and failing on main. I think we can force merge

[andyxning]

that test is unrelated and failing on main. I think we can force merge

@mgoin I am not 100 percent about this. Actually i have checked some merged prs and pending prs for the ci status about speculative decoding tests, it seems that it passed. So i am currently working on reproducing it on a gpu vm. If you can help me confirm that speculative decoding test fail has nothing to do with this PR, can you pls help me merge this pr?

[mgoin]

See the tracking issue https://github.com/vllm-project/vllm/issues/18954

[aarnphm]

I don't think this PR affects the spec decode change. We can force merge this

[andyxning]

Ok, seems that this pr can be merged for now, the only failed ci are well known. @mgoin @DarkLight1337 Can you help me merge this pr?

i will take a look at #18954 later.