google / google/vim-codefmt

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

オープン
#188 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る
bug
主要言語
Vim Script
スター
1.1k
フォーク
102
PR マージ指標
30日以内にマージされた PR はありません

説明

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

```viml
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`:

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

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

```sh
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.

コントリビューションガイド

コントリビューションガイドを開く

調査の方向性

autoload/codefmt/clangformat.vim の 32〜38 行目付近にあるバージョン解析から始め、issue に示されている数値形式および trunk 形式の clang-format --version 出力とその動作を比較します。ドットを含むリテラルなバージョンが正しく解析され、標準外のバージョンに意図した機能処理が適用されることを確認してください。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
vim
領域
tooling
issue の種類
バグ
難易度
2/5
見積もり時間
1〜3時間
活発さ
停滞
明瞭さ
明確に書かれている
初心者へのやさしさ
35/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。