• Stephan Bergmann's avatar
    New compilerplugins/clang unit tests · 645583df
    Stephan Bergmann yazdı
    ...to check that loplugin produces warnings/errors as expected:
    
    * Clang has a -verify switch that makes it easy to write test input .cxx files
      that list in comments all the warnings/errors that are expected, and let Clang
      check those expectations instead of generating object code.  See
      include/clang/Frontend/VerifyDiagnosticConsumer.h in the Clang source tree for
      documentation.
    
    * Introduce a CompilerTest gbuild class that uses the existing LinkTarget class
      as much as possible.  Checking the input files is implicitly phony, as the
      compilation step doesn't generate any object files, and the link step does
      nothing because there is no gb_LinkTarget_set_targettype for CompilerTest.
      The setup at least works for Clang on Linux (will need adaptions for Clang on
      Windows; compilers other than Clang are not relevant for now given this is
      used to check compilerplugins).
    
    * Definition of gb_CFLAGS_WERROR in solenv/gbuild/platform/com_GCC_defs.mk needs
      to be lazy ('=' vs. ':=') so that CompilerTest can override it:  The Clang
      -verify mode wants the input files to specify whether the loplugin diagnostics
      are warnings or errros, so they consistently need to be errors independent of
      --enable-werror configuration.
    
    * A first (example) test is in compilerplugins/clang/test/salbool.cxx.  The
      corresponding gbuild CompilerTest instance is in
      solenv/CompilerTest_compilerplugins_clang.mk for now.  The reason for that odd
      split across compilerplugins/ and solenv/ is that there is no
      compilerplugins/Modules_compilerplugins.mk file, so this setup is the easiest
      hack for now (to be cleaned up).  (Another area that could be improved is that
      all test files need to be listed explicitly in the CompilerTest_*.mk file,
      instead of, say, using all .c/.cxx/.m/.mm files in a specified directory.)
    
    * The test is run somewhat late during a top-level 'make', after loplugin has
      already been used in compilation.  But it can be run manually (e.g., 'make
      solenv') when making changes to loplugin during development.
    
    Change-Id: I01e12fb84887d264ac03ef2484807458c2075af4
    645583df