Armin Le Grand (collabora)
fde80f0497
Up to now with lots of effort ModelData was held at the svx::diagram::Point to keep a stripped version of Text and TextAttributes and also a selective (not complete!) key/value list of attributes for each shape itself (fill/line/text/...). These had to be moved to/rescued from oox::Shape that is used as helper at import to that model after import, set again at the oox::Shapes when XShapes had to be re-created, you name it - very complicated and error-prone, and never complete by definition. Nonetheless data in OOXML MSO format, so pretty easy to re- export if necessary /that's what I was looking at last changes). That also meant that all changes done to an XShape/SdrObject *had* to be somehow transfered to that diagram model data, too. We have no converters for that at all, target would be data representation as in OOXML files. What we *have* is import to our model using oox::Shapes and ccreating XShapes/SdrObjects, and export XShapes snippets 'direct' to MSO ooxml formats. Thus I thought about to use what we have, for the cost to split the model: the DiagramModel *has* to be kept to be able to re-create the Diagram on structural changes, that is needed. But the attribute & text data can stay at the associated XShapes that need to exist and get created anyways. That needs reliable identification of the XShapes belonging to the model. It requires to load that Diagram initially, using the oox::Shapes which have the complete attribute model data to create the XShapes. Remember that there is a 2nd import, from the ReplacementGraphic which (may) be contained in the MSO file. From that moment on changes on those XShapes will be diagram model changes if attributes get changed. But they will not need to forward changes to the DiagramModel in another format. When re-layouting it means to copy that data from old XShape to new XShape, before these get deleted. There may be new XShapes that need to be initialized, too. For export this means that part of that export will have to use the XShapes as model data as needed. This also means that the quality of im/export of Diagrams will in the future rely on the quality of our existing im/export snippets for XShape/oox::Shape/oox. These are developed and in use for a while now and should have reached a good quality. If we have to improve these that will always improve im/export and Diagram stuff then, too. This change does that big change and looks promising, doing what it is intended to do. I still have to experiment, so in master it is still deactivated due to being too dangerous yet, see last SmartArt change and mention of ACTIVATE_RECREATE_DIAGRAM_DATADOMS and it's description. Change-Id: Ife1591b0d3c8974d90a1004d94f3e6799be85a56 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198221 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Compiler plugins
Overview
This directory contains code for compiler plugins. These are used to perform additional actions during compilation (such as additional warnings) and also to perform mass code refactoring.
Currently only the Clang compiler is supported http://wiki.documentfoundation.org/Development/Clang.
Usage
Compiler plugins are enabled automatically by --enable-dbgutil if Clang headers
are found or explicitly using --enable-compiler-plugins.
Functionality
There are two kinds of plugin actions:
- compile checks - these are run during normal compilation
- rewriters - these must be run manually and modify source files
Each source has a comment saying whether it's compile check or a rewriter and description of functionality.
Compile Checks
Used during normal compilation to perform additional checks. All warnings and errors are marked '[loplugin]' in the message.
Rewriters
Rewriters analyse and possibly modify given source files.
Usage: make COMPILER_PLUGIN_TOOL=<rewriter_name>
Additional optional make arguments:
-
it is possible to also pass
FORCE_COMPILE=allto make to trigger rebuild of all source files, even those that are up to date. FORCE_COMPILE takes a list of gbuild targets specifying where to run the rewriter ('all' means everything, '-' prepended means to not enable, '/' appended means everything in the directory; there is no ordering, more specific overrides more general, and disabling takes precedence). Example: FORCE_COMPILE="all -sw/ -Library_sc" -
UPDATE_FILES=<scope>- limits which modified files will be actually written back with the changesmainfile- only the main.cxxfile will be modified (default)all- all source files involved will be modified (possibly even header files from other LO modules), 3rd party header files are however never modified<module>- only files in the given LO module (toplevel directory) will be modified (including headers)
Modifications will be written directly to the source files.
Some rewriter plugins are dual-mode and can also be used in a non-rewriting mode
in which they emit warnings for problematic code that they would otherwise
automatically rewrite. When any rewriter is enabled explicitly via make COMPILER_PLUGIN_TOOL=<rewriter_name> it works in rewriting mode (and all other
plugins are disabled), but when no rewriter is explicitly enabled (i.e., just
make), all dual-mode rewriters are enabled in non-rewriting mode (along with
all non-rewriter plugins; and all non--dual-mode plugins are disabled). The
typical process to use such a dual-mode rewriter X in rewriting mode is
make COMPILER_PLUGIN_WARNINGS_ONLY=X \
&& make COMPILER_PLUGIN_TOOL=X FORCE_COMPILE=all UPDATE_FILES=all
which first generates a full build without failing due to warnings from plugin
X in non-rewriting mode (in case of --enable-werror) and then repeats the build
in rewriting mode (during which no object files are generate).