最初に回避方法を書くと、 --top
オプションと一緒にseverityを指定してやるとこの現象は回避できる。
--top オプションが指定されると、severityが設定されてなかったら1 (最も厳しい) に設定されることが分かった。なんかバグってる? と思ったけどこういうものなのか、そして .perlcriticrc で設定した severity は無視されるように見えてきびしい、そういうものですか?https://t.co/zpbZM32kFP
— うたがわきき (@utgwkk) 2020年11月12日
.perlcriticrc に severity = 3 を渡しつつコマンドライン引数にも -3 を渡す、という振る舞いが行われることとなりました
— うたがわきき (@utgwkk) 2020年11月12日
これは実装を読むと実際そうなっているし、 perldoc perlcritic
にもそう書いてある。
普通にperlcriticを使っていたらハマらなかったと思うけど、sfodje.perlcritic というVSCode拡張機能を通してperlcriticを使おうとしてハマった。
--profile
あるいは -p
オプションがいずれも渡されてなかったら、拡張機能の設定項目にあるseverityをコマンドライン引数に渡す、という実装の条件式が間違っていたので修正した。すると、 --profile .perlcriticrc
というオプションを渡していて、かつ .perlcriticrc には severity = 3
しか書いてないのに、severityが2以下の警告がどんどん出てくる。
出したPRの実装がまずかったのかと思ったが、どうやら .perlcriticrc は読み込まれていて、severityの設定が効いていないようである。sfodje.perlcriticの実装を読みに行くと --top
オプションを渡していて、これが怪しいのではないかとアタリを付けたところ的中した。
2005年には --top
オプションを指定することでseverity 1になるように実装されていて、すぐ後にseverityが指定されてないときだけseverity 1にするように修正された。つまり15年ぐらいこの挙動であるということが分かる。
記事の冒頭にも書いたが、 --top
オプションと一緒にseverityを指定してやるとこの現象は回避できる。sfodje.perlcriticの設定として書くならこういう感じになる。
{ "perlcritic.additionalArguments": [ "--profile", ".perlcriticrc", "-3" ] }
perlcriticとsfodje.perlcriticの両方の実装を眺めないと問題に気づけなかった。