1. 27 May, 2019 2 kayıt (commit)
  2. 23 May, 2019 1 kayıt (commit)
  3. 20 May, 2019 1 kayıt (commit)
  4. 27 Mar, 2019 1 kayıt (commit)
  5. 23 Mar, 2019 1 kayıt (commit)
  6. 22 Mar, 2019 1 kayıt (commit)
    • Stephan Bergmann's avatar
      Allow to pass additional options into generator's clang::tooling · ad7e2af4
      Stephan Bergmann yazdı
      In my macOS build, that clang::tooling::runToolOnCodeWithArgs invocation failed
      to find headers like cassert and assert.h, which works now with
      
        COMPILER_PLUGINS_TOOLING_ARGS=-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -isystem /Users/stephan/Software/llvm/inst/include/c++/v1
      
      added to my autogen.input (I build against my Clang trunk libc++ whose headers
      are at /Users/stephan/Software/llvm/inst/include/c++/v1).
      
      Change-Id: Idbffa39c9fd4a88743fd498b8f7b6c9c56d7630d
      Reviewed-on: https://gerrit.libreoffice.org/69538
      Tested-by: Jenkins
      Reviewed-by: 's avatarStephan Bergmann <sbergman@redhat.com>
      ad7e2af4
  7. 18 Mar, 2019 1 kayıt (commit)
  8. 12 Mar, 2019 1 kayıt (commit)
    • Luboš Luňák's avatar
      make (some) clang plugins share the same RecursiveASTVisitor · adb08e89
      Luboš Luňák yazdı
      Each plugin currently uses its own recursive AST run, which adds up.
      This patch adds another shared plugin which internally contains all
      (suitable) plugins and dispatches to them from the same one recursive
      run. This patch converts ~25 plugins and for starmath's accessibility.cxx
      reduces clang build time from 5.43s to 5.14s (and it's 4.39s without any
      plugins). As there are almost 50 more plugins to go, this can theoretically
      result in 4.56s final time, although probably not all plugins can be
      that easily converted, if at all.
      
      This mostly requires very little change in many plugins (see e.g.
      BadStatics), some even work without any functionality change (e.g.
      CharRightShift). Traverse* calls require some changes but are often
      not that difficult. WalkUp* probably can't be supported, although some
      plugins can(?) possibly be adjusted to not rely on them. And of course
      some plugins can be left as they are, using their own recursive run.
      See description at the top of generator.cxx for description of how to
      convert a plugin.
      
      The sharedvisitor.cxx source is generated based on scanning relevant
      plugin sources using a clang-based scanner/generator. The generated
      source is intentionally included instead of getting always generated,
      as the generating currently takes some time, so it should get updated
      in git whenever a change in a plugin triggers a source change in it.
      
      Change-Id: Ia0d2e3a5a464659503dbb4ed6c20b6cc89b4de01
      Reviewed-on: https://gerrit.libreoffice.org/68026
      Tested-by: Jenkins
      Reviewed-by: 's avatarNoel Grandin <noel.grandin@collabora.co.uk>
      Reviewed-by: 's avatarLuboš Luňák <l.lunak@collabora.com>
      adb08e89
  9. 18 Şub, 2019 2 kayıt (commit)
  10. 06 Ara, 2017 1 kayıt (commit)
    • Stephan Bergmann's avatar
      Remove CXXFLAGS_CXX11 from Clang plugin compilation · e754d093
      Stephan Bergmann yazdı
      CXXFLAGS_CXX11 is for the compiler used to compile LO proper.  The plugin needs
      to be compiled in a way compatible with compiling Clang, and the compiler and
      any relevant flags can be controlled with COMPILER_PLUGINS_CXX.  (And at least
      on macOS when compiling LO against a locally-built recent Clang trunk,
      CXXFLAGS_CXX11 will now contain -std=gnu++17, but COMPILER_PLUGINS_CXX can still
      point at Apple's Xcode clang++, which does not understand -std=gnu++17.)
      
      Also, if COMPILER_PLUGINS_CXX is not set, simply default it to g++ instead of
      trying to construct an acceptable CLANGCXX value from CXX (which would be
      Clang).  (The problem with using Clang without CXXFLAGS_CXX11 is that Clang,
      unlike GCC, typically defaults to C++03, but building compilerplugins requires
      C++11 at least.  That would cause e.g. the Gerrit/Jenkins linux_clang_dbgutil_64
      builds to fail---but which also needs COMPILER_PLUGINS_CXX to be explicitly set
      to "g++ -std=c++11" as GCC on those machines is still 4.8.5 defaulting to
      C++03.)
      
      Change-Id: Id4ee4e54fa871cb6e621069cd050ae5b31922b34
      Reviewed-on: https://gerrit.libreoffice.org/45856Tested-by: 's avatarJenkins <ci@libreoffice.org>
      Reviewed-by: 's avatarStephan Bergmann <sbergman@redhat.com>
      e754d093
  11. 30 Eyl, 2017 1 kayıt (commit)
    • Stephan Bergmann's avatar
      Support loplugin in clang-cl · 39e7a72b
      Stephan Bergmann yazdı
      This works at least with a recent Clang trunk (towards Clang 6.0).
      
      In order for the plugin.dll to find the LLVM/Clang symbols, it needs to be
      loaded into clang.exe not clang-cl.exe, so set CC/CXX to 'clang.exe
      --driver-mode=cl ...'.
      
      Buidling the plugin requires some linker flags that must go at the very end of
      the COMPILER_PLUGINS_CXX command line, after a /link switch, so introduce
      another COMPILER_PLUGINS_CXX_LINKFLAGS variable for that.  Also, clang.lib is
      not installed as part of LLVM's 'cmake --build ... --target install' step, so
      is not available under CLANGDIR and needs to be taken from the build tree
      instead, so introduce another CLANGLIBDIR variable for that.  autogen.input
      settings that work for me on Windows 8.1 with Microsoft Visual Studio 14.0 are:
      
      > CLANGDIR=C:/llvm/inst
      > CLANGLIBDIR=C:/llvm/build/lib
      > COMPILER_PLUGINS_CXX=C:/PROGRA~2/MICROS~3.0/VC/bin/amd64/cl.exe /IC:\PROGRA~2\MICROS~3.0\VC\INCLUDE /IC:\PROGRA~2\MICROS~3.0\VC\ATLMFC\INCLUDE /IC:\PROGRA~2\WI3CF2~1\10\include\100102~1.0\ucrt /IC:\PROGRA~2\WI3CF2~1\NETFXSDK\46D346~1.1\include\um /IC:\PROGRA~2\WI3CF2~1\8.1\include\shared /IC:\PROGRA~2\WI3CF2~1\8.1\include\um /IC:\PROGRA~2\WI3CF2~1\8.1\include\winrt
      > COMPILER_PLUGINS_CXX_LINKFLAGS=/LIBPATH:C:/PROGRA~2/MICROS~3.0/VC/LIB/amd64 /LIBPATH:C:/PROGRA~2/MICROS~3.0/VC/ATLMFC/LIB/amd64 /LIBPATH:C:/PROGRA~2/WI3CF2~1/10/lib/100102~1.0/ucrt/x64 /LIBPATH:C:/PROGRA~2/WI3CF2~1/NETFXSDK/46D346~1.1/lib/um/x64 /LIBPATH:C:/PROGRA~2/WI3CF2~1/8.1/lib/winv6.3/um/x64
      
      (The last two are "C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/
      amd64/cl.exe" and translations of %INCLUDE% and %LIB% as set in the "VS2015 x64
      Native Tools Command Prompt" shell.
      AC_CHECK_HEADER(clang/AST/RecursiveASTVisitor.h, ...) in configure.ac wouldn't
      like CXX to start with INCLUDE=... LIB=... environment variable settings, so it
      wouldn't work to instead pass %INCLUDE% and %LIB% to cl.exe that way.  See
      <https://wiki.documentfoundation.org/Development/clang-cl> for general
      information about building with clang-cl on Windows.)
      
      There's still some room for improvement marked "TODO".  (And some of the unused*
      plugins, which are not run by default anyway, use Unix-style functionality, so
      have been disabled for now.)
      
      Change-Id: I6c28bdeb801af39ce2bae03111f455e2338d66c9
      Reviewed-on: https://gerrit.libreoffice.org/42931Tested-by: 's avatarJenkins <ci@libreoffice.org>
      Reviewed-by: 's avatarStephan Bergmann <sbergman@redhat.com>
      39e7a72b
  12. 16 May, 2017 1 kayıt (commit)
  13. 30 Haz, 2016 2 kayıt (commit)
    • Stephan Bergmann's avatar
      Explain usage of -isystem instead of -I · 944ed686
      Stephan Bergmann yazdı
      Change-Id: Ib7153db5c2c1542ff7e9a0daa6d7124225c7701c
      944ed686
    • Stephan Bergmann's avatar
      Who needs that $(CLANGDIR)/tools/clang/include anyway? · 4d54e240
      Stephan Bergmann yazdı
      It was included ever since 02a8d36e "initial
      support for clang compiler plugins" but will probably point at either a non-
      existing dir or a dir in the Clang source tree (that does not even contain all
      the include files that the corresponding installation dir would contain, as some
      include files are generated during the build).  For a properly installed LLVM/
      Clang, all include files should be found underneath a single include/ dir.
      
      Change-Id: Ie23cb1ae701eed1ee78448eb6c828d07b15121c2
      4d54e240
  14. 29 Haz, 2016 1 kayıt (commit)
  15. 26 Şub, 2016 2 kayıt (commit)
  16. 11 Agu, 2015 1 kayıt (commit)
  17. 22 May, 2014 1 kayıt (commit)
  18. 17 May, 2014 1 kayıt (commit)
  19. 09 May, 2014 1 kayıt (commit)
  20. 25 Şub, 2014 1 kayıt (commit)
  21. 21 Şub, 2014 1 kayıt (commit)
  22. 20 Şub, 2014 1 kayıt (commit)
  23. 09 Ock, 2014 1 kayıt (commit)
  24. 05 Agu, 2013 1 kayıt (commit)
  25. 13 Haz, 2013 1 kayıt (commit)
  26. 05 Haz, 2013 1 kayıt (commit)
  27. 31 May, 2013 2 kayıt (commit)
  28. 30 Mar, 2013 1 kayıt (commit)
  29. 28 Mar, 2013 1 kayıt (commit)
  30. 19 Mar, 2013 1 kayıt (commit)
  31. 07 Şub, 2013 2 kayıt (commit)
  32. 02 Şub, 2013 3 kayıt (commit)