<p dir="ltr">I think, it would be more consistent to have clang-tidy insert a link to the check documentation (on<a href="http://llvm.org"> </a><a href="http://llvm.org">llvm.org</a>) into each warning. The documentation pages already contain links to the relevant rules. We could even version documentation pages, if we think it's important (but afaiu, we don't do this for clang, for example). This way we can control link integrity and describe implementation-specific details, which can sometimes be important.</p>
<div class="gmail_quot<blockquote class=" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Oct 6, 2015 at 4:12 PM Aaron Ballman <<a href="mailto:aaron.ballman@gmail.com" target="_blank">aaron.ballman@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">aaron.ballman added a comment.<br>
<br>
In <a href="http://reviews.llvm.org/D13368#260672" rel="noreferrer" target="_blank">http://reviews.llvm.org/D13368#260672</a>, @klimek wrote:<br>
<br>
> In <a href="http://reviews.llvm.org/D13368#260669" rel="noreferrer" target="_blank">http://reviews.llvm.org/D13368#260669</a>, @aaron.ballman wrote:<br>
><br>
> > This wasn't a comment on the rule so much as a comment on the diagnostic not being very helpful.In this case, you're telling the user to not do something, but it is unclear how the user would structure their code to silence this diagnostic. Perhaps there is no way to word this to give the user a clue, but we should at least try. If I got this diagnostic as it is now, I would scratch my head and quickly decide to ignore it.<br>
><br>
><br>
> The cpp core guidelines are written in a way that they should be referenceable by links - do we want to add links to the relevant portions of the core guidelines from the clang-tidy checks?<br>
<br>
<br>
I'd be hesitant to do that. It would add a lot of verbiage to diagnostics that are likely to be chatty, and if the links ever go dead mid-release cycle for us, we're stuck looking bad with no way to fix it. CERT's guidelines are also linkable in the same fashion (as would be hypothetical checks for MISRA, JSF, etc), and I would have the same hesitation for those as well due to the potential dead link issue.<br>
<br>
I think that having the links within the user-facing documentation is a must-have though (and something we've been pretty good about thus far) because those can be updated live from ToT. So perhaps a permanent short link to our own documentation might be useful (if a bit obtuse since our docs mostly just point to other docs elsewhere)? I'd still be a bit worried about expired short links or something, but maybe we already host a service for this sort of thing?</blockquote><div><br></div><div>I'll postulate that a) github will not go away anytime soon and b) github will have a hard time changing their link structure so linking into revision N in branch M doesn't work any more.</div><div>Thus, I think if we link into the github release of the core guildelines, we'll be fine.</div></div></div>
</div>