Skip to content
Snippets Groups Projects
  1. Aug 05, 2016
    • John Brawn's avatar
      Reapply r276973 "Adjust Registry interface to not require plugins to export a registry" · 0cfb8c87
      John Brawn authored
      This differs from the previous version by being more careful about template
      instantiation/specialization in order to prevent errors when building with
      clang -Werror. Specifically:
       * begin is not defined in the template and is instead instantiated when Head
         is. I think the warning when we don't do that is wrong (PR28815) but for now
         at least do it this way to avoid the warning.
       * Instead of performing template specializations in LLVM_INSTANTIATE_REGISTRY
         instead provide a template definition then do explicit instantiation. No
         compiler I've tried has problems with doing it the other way, but strictly
         speaking it's not permitted by the C++ standard so better safe than sorry.
      
      Original commit message:
      
      Currently the Registry class contains the vestiges of a previous attempt to
      allow plugins to be used on Windows without using BUILD_SHARED_LIBS, where a
      plugin would have its own copy of a registry and export it to be imported by
      the tool that's loading the plugin. This only works if the plugin is entirely
      self-contained with the only interface between the plugin and tool being the
      registry, and in particular this conflicts with how IR pass plugins work.
      
      This patch changes things so that instead the add_node function of the registry
      is exported by the tool and then imported by the plugin, which solves this
      problem and also means that instead of every plugin having to export every
      registry they use instead LLVM only has to export the add_node functions. This
      allows plugins that use a registry to work on Windows if
      LLVM_EXPORT_SYMBOLS_FOR_PLUGINS is used.
      
      
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@277806 91177308-0d34-0410-b5e6-96231b3b80d8
      0cfb8c87
  2. Jul 28, 2016
    • John Brawn's avatar
      Revert r276973 "Adjust Registry interface to not require plugins to export a registry" · 40e6fbb0
      John Brawn authored
      Buildbot failures when building with clang -Werror. Reverting while I try to
      figure this out.
      
      
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@277008 91177308-0d34-0410-b5e6-96231b3b80d8
      40e6fbb0
    • John Brawn's avatar
      Reapply r276856 "Adjust Registry interface to not require plugins to export a registry" · b0e340c7
      John Brawn authored
      This version has two fixes compared to the original:
       * In Registry.h the template static members are instantiated before they are
         used, as clang gives an error if you do it the other way around.
       * The use of the Registry template in clang-tidy is updated in the same way as
         has been done everywhere else.
      
      Original commit message:
      
      Currently the Registry class contains the vestiges of a previous attempt to
      allow plugins to be used on Windows without using BUILD_SHARED_LIBS, where a
      plugin would have its own copy of a registry and export it to be imported by
      the tool that's loading the plugin. This only works if the plugin is entirely
      self-contained with the only interface between the plugin and tool being the
      registry, and in particular this conflicts with how IR pass plugins work.
      
      This patch changes things so that instead the add_node function of the registry
      is exported by the tool and then imported by the plugin, which solves this
      problem and also means that instead of every plugin having to export every
      registry they use instead LLVM only has to export the add_node functions. This
      allows plugins that use a registry to work on Windows if
      LLVM_EXPORT_SYMBOLS_FOR_PLUGINS is used.
      
      
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@276973 91177308-0d34-0410-b5e6-96231b3b80d8
      b0e340c7
  3. Jul 27, 2016
  4. Jun 09, 2016
  5. Apr 04, 2016
  6. Mar 15, 2016
Loading