clang-format version detection is slightly broken (and definitely so for trunk builds)

Open
#188 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
35/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Stale
Tech stack
vim
Domain
tooling

Research direction

Start in autoload/codefmt/clangformat.vim at the version parsing around lines 32-38, and compare its behavior with the numeric and trunk-style clang-format --version outputs shown in the issue. Verify that literal dotted versions are parsed correctly and that non-standard versions receive the intended feature handling.

Written by the indexing model from the issue text.

Description

bug

At https://github.com/google/vim-codefmt/blob/293c208/autoload/codefmt/clangformat.vim#L32-34, we have this code:

    let l:version_string = matchstr(l:version_output, '\v\d+(.\d+)+')
    " If no version string was matched, cached version will be an empty list.
    let s:clang_format_version = map(split(l:version_string, '\.'), 'v:val + 0')

which is trying to find a version number (possibly "1.2.3" or "1.2" or just "1") in the output of clang-format --version:

$ clang-format --version
clang-format version 7.0.1-8+deb10u2 (tags/RELEASE_701/final)

However, for trunk builds, the output looks something like:

 clang-format --version
clang-format version mainline (4321b9f2e9842982d13234920a643e3a4657c60b)

(where "mainline" can be any string the configurer chooses).

However:

  • matchstr(l:version_output, '\v\d+(.\d+)+') has . matching any character. That probably was intended to be a literal (\.) instead, otherwise the pattern could just have been \v\d.+.
  • As a result, we consider any trunk build to be a version "number" containing the numeric start of the hex string (i.e. version 4321 in the above example).
  • This means that we usually consider trunk builds to have all features (good), but only if their version string starts with enough non-zero/non-hex digits (bad).

We probably should do something like:

  1. Change the regexp to use \. instead to match a literal.
  2. Consider a non-standard version to always have the feature rather than not have it (at https://github.com/google/vim-codefmt/blob/293c208/autoload/codefmt/clangformat.vim#L38.
Dominant language
Vim Script
Stars
1.1k
Forks
102
No merged PRs in 30d

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from google/vim-codefmt

All issues in google/vim-codefmt

Similar issues

More DevTools issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.