Skip to content
Snippets Groups Projects
Select Git revision
  • master default protected
1 result
Search by author
  • Any Author
  • Dr. Jorrit Fahlke Dr. Jorrit Fahlke jfahl_01
  • Jan Hönig hoenig
  • Marcel Dominique Koch marckoch
  • Martin Bauer bauermar
  • Michael Haidl m_haid02
  • Prof. Dr. Christian Engwer Prof. Dr. Christian Engwer cengw_01
  • René Heß hessr
  • Vladyslav Kucher kucher
8 authors
  1. Jan 14, 2017
  3. Jan 06, 2017
  5. Jan 05, 2017
  7. Oct 10, 2016
  9. 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
  11. 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
  13. Jul 27, 2016
  15. Jul 08, 2016
  17. Jun 09, 2016
  19. Apr 04, 2016
  21. Mar 15, 2016
  23. Feb 11, 2016
  25. Feb 09, 2016
  27. Jan 26, 2016
  29. Sep 17, 2015
  31. Jun 23, 2015
  33. Jun 22, 2015
  35. May 17, 2015
    • Nico Weber's avatar
      Don't leak TemplateIds when a plugin parses late-parsed templates at TU end. · acb8cdf0
      Nico Weber authored 
      In -fdelayed-template-parsing mode, templates that aren't used are not parsed
at all.  For some diagnostic plugins, this is a problem since they want to
analyse the contents of the template function body.  What has been suggested
on cfe-dev [1] is to explicitly parse interesting templates in
HandleTranslationUnit(); IWYU does this for example [2].

This is workable, but since the delayed parsing doesn't run below a call to
ParseTopLevelDecl(), no DestroyTemplateIdAnnotationsRAIIObj object is on the
stack to clean up TemplateIds that are created during parsing.  To fix this,
let ~Parser() clean them up in delayed template parsing mode instead of
leaking (or asserting in +Assert builds).

(r219810, relanded in r220400, fixed the same problem in incremental processing
mode; the review thread of r219810 has a good discussion of the problem.)

To test this, give the PrintFunctionNames plugin a flag to force parsing
of a template and add a test that uses it in -fdelayed-template-parsing mode.
Without the Parser.cpp change, that test asserts.

1: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2014-August/038415.html
2: https://code.google.com/p/include-what-you-use/source/detail?r=566 


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@237531 91177308-0d34-0410-b5e6-96231b3b80d8
      acb8cdf0
  37. Apr 11, 2015
  39. Jan 23, 2015
  41. Oct 03, 2014
  43. Sep 04, 2014
  45. Sep 03, 2014
  47. Aug 19, 2014
  49. Aug 10, 2014
  51. Aug 08, 2014
  53. Aug 07, 2014
  55. Jul 24, 2014
  57. Jul 18, 2014
  59. Jul 17, 2014