<div dir="ltr">Ah, forgot one more thing: clang-tidy suggests to add -header-filter='.*' in some cases. This needs to be updated as well.<br><div class="gmail_extra"><br></div><div class="gmail_extra">-- Alex<br><div class="gmail_quote">On Mon, Jul 27, 2015 at 2:35 PM, Aaron Ballman <span dir="ltr"><<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Jul 27, 2015 at 6:56 AM, Alexander Kornienko <<a href="mailto:alexfh@google.com">alexfh@google.com</a>> wrote:<br>
> Manuel, thanks for the correction. Omitting quotes would be a problem with<br>
> `-checks *`, not `-checks=*` (which is used in the docs).<br>
><br>
> Aaron, this patch looks almost good then. Note that the description of<br>
> command-line arguments is just a dump of `clang-tidy -help`, so you need to<br>
> fix the documentation in the code and then paste `clang-tidy -help` output<br>
> to the .rst file and indent it appropriately.<br>
<br>
</span>Thank you for pointing that out, I've corrected in this patch.<br>
<span class=""><br>
> Could you also check whether the -config=... examples work on windows?<br>
<br>
</span>They do work, from my simple tests.<br>
<br>
~Aaron<br>
<span class=""><br>
> It might also be useful to add a section describing the windows-specific<br>
> aspects of clang-tidy usage some time in the future.<br>
><br>
> -- Alex<br>
><br>
><br>
</span><span class="">> On Mon, Jul 27, 2015 at 11:57 AM, Manuel Klimek <<a href="mailto:klimek@google.com">klimek@google.com</a>> wrote:<br>
>><br>
>> I think that something starts with -check= on the disk is low probability<br>
>> enough that we don't lose much by not escaping it for unix users, while<br>
>> gaining a lot less confusion on windows.<br>
>><br>
</span>>> On Fri, Jul 24, 2015 at 5:39 PM Alexander Kornienko <<a href="mailto:alexfh@google.com">alexfh@google.com</a>><br>
<span class="">>> wrote:<br>
>>><br>
>>> I think, we need to leave the examples valid for unix-like shells and add<br>
>>> a short section describing differences of shells or giving windows-specific<br>
>>> usage instructions. Some examples are just impossible to make compatible<br>
>>> with all shells (e.g. -checks='*', even though this is not particularly<br>
>>> useful).<br>
>>><br>
>>><br>
</span>>>> On Fri, Jul 24, 2015 at 4:52 PM, Aaron Ballman <<a href="mailto:aaron@aaronballman.com">aaron@aaronballman.com</a>><br>
>>> wrote:<br>
>>>><br>
>>>> On Fri, Jul 24, 2015 at 8:44 AM, Manuel Klimek <<a href="mailto:klimek@google.com">klimek@google.com</a>><br>
>>>> wrote:<br>
>>>> > On Fri, Jul 24, 2015 at 2:34 PM Aaron Ballman <<a href="mailto:aaron@aaronballman.com">aaron@aaronballman.com</a>><br>
>>>> > wrote:<br>
>>>> >><br>
>>>> >> On Fri, Jul 24, 2015 at 8:32 AM, Manuel Klimek <<a href="mailto:klimek@google.com">klimek@google.com</a>><br>
<div class="HOEnZb"><div class="h5">>>>> >> wrote:<br>
>>>> >> > Seems like we need different instructions for different shells then<br>
>>>> >> > :(<br>
>>>> >> > The problem is that otherwise the -*... can be subject to shell<br>
>>>> >> > expansion if<br>
>>>> >> > it happens to match some files.<br>
>>>> >><br>
>>>> >> Ah, I kind of wondered if this was a shell issue. Thank you for the<br>
>>>> >> verification!<br>
>>>> >><br>
>>>> >> Do you think it makes sense to update the option parsing code to<br>
>>>> >> strip<br>
>>>> >> the single quotes if they are present?<br>
>>>> ><br>
>>>> ><br>
>>>> > No, I don't think it's the tool's job to handle idiosyncrasies of the<br>
>>>> > various shells.<br>
>>>> > For the docs I see two possibilities:<br>
>>>> > a) have 2 versions, one for cmd.exe, one for *sh.<br>
>>>> > b) the probability that users will actually have file named<br>
>>>> > -something, is<br>
>>>> > not that high, we use the non-quoted version<br>
>>>><br>
>>>> I kind of lean towards (b) with the understanding (which may be<br>
>>>> incorrect) that users of the shell are expected to understand when to<br>
>>>> quote arguments and when not to. That being said, I don't have a<br>
>>>> strong opinion on it.<br>
>>>><br>
>>>> ~Aaron<br>
>>>><br>
>>>> ><br>
>>>> > Alex, thoughts?<br>
>>>> ><br>
>>>> >><br>
>>>> >><br>
>>>> >> ~Aaron<br>
>>>> >><br>
>>>> >> ><br>
>>>> >> ><br>
>>>> >> > On Thu, Jul 23, 2015 at 7:49 PM Aaron Ballman<br>
</div></div><div class="HOEnZb"><div class="h5">>>>> >> > <<a href="mailto:aaron@aaronballman.com">aaron@aaronballman.com</a>><br>
>>>> >> > wrote:<br>
>>>> >> >><br>
>>>> >> >> This patch addresses two issues (I can split the patch if it is<br>
>>>> >> >> desired):<br>
>>>> >> >><br>
>>>> >> >> 1) The docs have some non-ASCII characters in them that aren't<br>
>>>> >> >> really<br>
>>>> >> >> required.<br>
>>>> >> >> 2) The docs suggest setting the checks using single quotes, which<br>
>>>> >> >> does<br>
>>>> >> >> not work (at least, on Windows).<br>
>>>> >> >><br>
>>>> >> >> When you specify checks like -checks='-*,misc-some-check', the<br>
>>>> >> >> single<br>
>>>> >> >> quotes are not stripped by the option parser. When converting the<br>
>>>> >> >> flags into globs to pass along to regex, the single quotes remain<br>
>>>> >> >> as<br>
>>>> >> >> part of the regular expression, and do not match appropriately.<br>
>>>> >> >> When<br>
>>>> >> >> the single quotes are left off, the globs are correctly generated.<br>
>>>> >> >><br>
>>>> >> >> ~Aaron<br>
>>><br>
>>><br>
><br>
</div></div></blockquote></div><br><br>
</div></div>