[clang-tools-extra] r264563 - clang-tidy: Fix broken buildbot

[Richard via cfe-commits]

In article <CAOweq9+EGaM9FfW0ZoPWMWexb+m9+XA9-oSS75YCYDvaOOubuQ at mail.gmail.com>,
    Alexander Kornienko <alexfh at google.com> writes:
> 
> On Mon, Mar 28, 2016 at 6:15 AM, Richard Thomson via cfe-commits <
> cfe-commits at lists.llvm.org> wrote:
> 
> > Author: legalize
> > Date: Sun Mar 27 23:15:41 2016
> > New Revision: 264563
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=264563&view=rev
> > Log:
> > clang-tidy: Fix broken buildbot
> >
> > VS 2013 does not support char16_t or char32_t

> I'm not sure I understand what this test has to do with VS2013.

I incorrectly stated it as VS 2013 and not the Windows buildbot
configuration as being the root cause.

If you look at the failed build message, it is clearly saying "error:
unknown type name 'char16_t'" and "error: unknown type name 'char32_t'".
<http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/10921/steps/ninja%20check%202/logs/FAIL%3A%20Clang%20Tools%3A%3Amodernize-raw-string-literal.cpp>

I could either do something that would fix the build quickly (which is
what I chose to do), or I could reverse out the entire changeset.

I chose the former as the best means of getting the builds green
again.  The existing raw string literal check doesn't yet process
character literals other than ASCII literals, so there is nothing lost
in commenting out these lines of the test file.

> Clang-tidy
> should be able to parse this code, and if it doesn't (e.g. due to
> -fms-compatibility being turned on by default on windows), we should put
> unsupported constructs under an appropriate #ifdef, not comment them out
> completely.

That is why I added a TODO comment instead of just removing the lines.

Feel free to patch it such that it does some kind of CMake based
feature check for char16_t and char32_t and then configures a header
file with HAS_xxx style check macros, include that generated header
file in the test sources and then use the preprocessor to conditionally
include the lines in the test file based on compiler support.

To me, that is a significant chunk of work, which is why I opted
instead for commenting out these (not too important yet) lines of test
code and add a TODO comment.  That TODO can be addressed when the
check is expanded to handle non-ASCII string literals.
-- 
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
     The Computer Graphics Museum <http://ComputerGraphicsMuseum.org>
         The Terminals Wiki <http://terminals.classiccmp.org>
  Legalize Adulthood! (my blog) <http://LegalizeAdulthood.wordpress.com>