Re: compiler plugin

[Stephan Bergmann]

On 01/20/2017 05:17 PM, Norbert Thiebaud wrote:

On Fri, Jan 20, 2017 at 3:16 AM, Stephan Bergmann  wrote:

What appears to be missing is a "normal" (not Gerrit-triggered) bot running
that setup on master, so that a broken master wrt that setup can be spotted
(and acted upon) more quickly.

Today, a broken master is only spotted when somebody tracks down a broken
Gerrit build to be due to a broken master


so, if I understand it, a direct push to master that broke it, surprise!


Yes, that would typically be the most plausible explanation for such 
breakage.  Whatever's surprising there...

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: compiler plugin

[Norbert Thiebaud]

On Fri, Jan 20, 2017 at 3:16 AM, Stephan Bergmann  wrote:
> On 07/12/2016 09:32 AM, Norbert Thiebaud wrote:
>>
>> I've enabled an additional build for gerrit doing clang + plugins on linux
>> we will see how that perform in average.
>> preliminary observation is that there is way to much churn in the
>> plugins for this to be viable at this time
>
>
> What appears to be missing is a "normal" (not Gerrit-triggered) bot running
> that setup on master, so that a broken master wrt that setup can be spotted
> (and acted upon) more quickly.
>
> Today, a broken master is only spotted when somebody tracks down a broken
> Gerrit build to be due to a broken master

so, if I understand it, a direct push to master that broke it, surprise!

Norbert
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: compiler plugin

[Stephan Bergmann]

On 01/20/2017 11:29 AM, Jan Iversen wrote:

Today, a broken master is only spotted when somebody tracks down a
broken Gerrit build to be due to a broken master (or when somebody
doing their own local build with a sufficiently similar setup spots
it).  That can delay fixing unnecessarily, causing many developers
to meanwhile base their Gerrit changes on a broken master.


Such a bot should trigger on commits in git, I do that on my own vms.


Yes, of course.


However I think we would need 3 bot (windows, linux, osx) as many of
the build breakers are platform dependent.


The other three Gerrit/Jenkins bot setups (Linux GCC, macOS, Windows) 
are already covered well enough by existing Jenkins_* bots (see 
), I think.



When a build breaker is seen, it is normally acted upon very fast
(THANKS a lot) so having such bots, would likely reduce the time
where master cannot build to a few hours. This measure would
eliminate the need to trace the last commit where master builds (a
suggested idea to help especially new people).


We already have all that, in general?  (My mail was specifically about 
Gerrit/Jenkins' Clang+plugins setup, where the only "regular" bot with a 
similar setup is my Linux-F19-x86_64_14-with-check, but which is so slow 
that it is practically useless in what I'm asking for above.)

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: compiler plugin

[Jan Iversen]

> Today, a broken master is only spotted when somebody tracks down a broken 
> Gerrit build to be due to a broken master (or when somebody doing their own 
> local build with a sufficiently similar setup spots it).  That can delay 
> fixing unnecessarily, causing many developers to meanwhile base their Gerrit 
> changes on a broken master.

Such a bot should trigger on commits in git, I do that on my own vms. However I 
think we would need 3 bot (windows, linux, osx) as many of the build breakers 
are platform dependent.

When a build breaker is seen, it is normally acted upon very fast (THANKS a 
lot) so having such bots, would likely reduce the time where master cannot 
build to a few hours. This measure would eliminate the need to trace the last 
commit where master builds (a suggested idea to help especially new people).

How can we make this happen ?

have a nice weekend.
rgds
jan I.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: compiler plugin

[Stephan Bergmann]

On 07/12/2016 09:32 AM, Norbert Thiebaud wrote:

I've enabled an additional build for gerrit doing clang + plugins on linux
we will see how that perform in average.
preliminary observation is that there is way to much churn in the
plugins for this to be viable at this time


What appears to be missing is a "normal" (not Gerrit-triggered) bot 
running that setup on master, so that a broken master wrt that setup can 
be spotted (and acted upon) more quickly.


Today, a broken master is only spotted when somebody tracks down a 
broken Gerrit build to be due to a broken master (or when somebody doing 
their own local build with a sufficiently similar setup spots it).  That 
can delay fixing unnecessarily, causing many developers to meanwhile 
base their Gerrit changes on a broken master.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: compiler plugin

[Stephan Bergmann]

On 07/13/2016 11:18 AM, Stephan Bergmann wrote:

So my proposal would be as follows:  First, check whether enabling
compiler_check=content or the compiler_check=string:X setup (and
increasing the ccache size if necessary and possible) gives good-enough
performance.  If not, restrict commits to compilerplugins/ to be less
frequent, and see whether that increases the ccache hit rate and results
in good-enough performance.


For the record, we go with compiler_check=none since 
 
"disable compiler check for ccache and clang plugin compile".  Lets see 
how that works out in practice.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: compiler plugin

[Stephan Bergmann]

On 07/12/2016 09:32 AM, Norbert Thiebaud wrote:

I've enabled an additional build for gerrit doing clang + plugins on linux
we will see how that perform in average.
preliminary observation is that there is way to much churn in the
plugins for this to be viable at this time


The newly set up 
 
misses some configuration though to build with Clang and plugins enabled 
(so it happens to build with GCC and, consequently, no plugins).


At a minimum it would need CC=.../CXX=... (and CLANGDIR=...) 
configuration switches to use Clang, and it would probably make sense to 
also add an explicit --enable-compiler-plugins switch, so it doesn't 
silently fall back to building with plugins disabled.


Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: compiler plugin

[Lineikosen]

The Compiler Plugin is used to compile the sources of your project. Since
3.0, the default compiler is javax.tools.JavaCompiler (if you are using java
1.6) and is used to compile Java sources. If you want to force the plugin
using javac, you must configure the plugin option forceJavacCompilerUse.



-
http://www.3d-architectural-rendering.com/3D-Exterior-Rendering.html
--
View this message in context: 
http://nabble.documentfoundation.org/compiler-plugin-tp4188379p4188564.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: compiler plugin

[Stephan Bergmann]

On 07/13/2016 06:07 PM, Norbert Thiebaud wrote:

On Wed, Jul 13, 2016 at 7:00 AM, Stephan Bergmann  wrote:

Not necessarily.  Consider a change being discussed between an author and a
reviewer, leading to the author generating multiple revisions of the change.
To track the differences between the revisions, it is best if there's no
rebases in between.


this is not quite true anymore
see https://gerrit.libreoffice.org/#/c/27120/
which was based on a 3 weeks old commit at the time
it was rebased...
if you do a diff against version 1 in gerrit the diff presented does
not have all the changes due to the rebase.
That used to be the case, but they fixed that in gerrit.


Ah, didn't know that.  (And whatever it will present in the case of 
conflicting modifications.)


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: compiler plugin

[Norbert Thiebaud]

On Wed, Jul 13, 2016 at 7:00 AM, Stephan Bergmann  wrote:
> Not necessarily.  Consider a change being discussed between an author and a
> reviewer, leading to the author generating multiple revisions of the change.
> To track the differences between the revisions, it is best if there's no
> rebases in between.

this is not quite true anymore
see https://gerrit.libreoffice.org/#/c/27120/
which was based on a 3 weeks old commit at the time
it was rebased...
if you do a diff against version 1 in gerrit the diff presented does
not have all the changes due to the rebase.
That used to be the case, but they fixed that in gerrit.

Norbert
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: compiler plugin

[Stephan Bergmann]

On 07/13/2016 11:53 AM, Norbert Thiebaud wrote:

On Wed, Jul 13, 2016 at 4:18 AM, Stephan Bergmann <sberg...@redhat.com> wrote:

The idea behind the second choice is to periodically update and rebuild the
bot's compilerplugins repo, so that sequences of LO builds on the bot are
guaranteed to all use the same plugin.so and be able to reuse cached objects
across those builds.  However, that would mean that Gerrit changes based on
a relatively old code base could be built against a newer version of the
compilerpluigns repo, running into warnings/errors from new plugins, the
fixes for which across the LO code base not yet being included in the code
base revision the change is based on.  So I think this approach isn't
feasible.



Actually that is very feasible. since
1/ the solution for these old-based change is 'rebase'


Not necessarily.  Consider a change being discussed between an author 
and a reviewer, leading to the author generating multiple revisions of 
the change.  To track the differences between the revisions, it is best 
if there's no rebases in between.



(Another problem would be that e.g. the name of a class from the
LO code base can be whitelisted in one of the plugins, to suppress
warnings/errors from that class.  If the name of the class changes in the LO
code base, the compilerplugins repo must be changed in sync.)


That sound like the whole contraption is quite fragile and random.. if
you have to 'whitelist' random 'class'
directly in the pluging... I'd suggest there is something
fondamentally wrong in the process.
whitelisting, or more eactly a way to say to the plugin: 'shut-up, I know'
should be done by annotating the source code not by patching the plugin.


Even ignoring the negative connotation of "contraption", that's how the 
existing plugin code works, and apparently works reasonably well and 
successfully.



So my proposal would be as follows:  First, check whether enabling
compiler_check=content or the compiler_check=string:X setup (and increasing
the ccache size if necessary and possible)


the cache size is 100GB dedicated to clang... that is quite a chunk of
disk already.


The question would be whether it turns out to be enough in practice, 
and---if it is not---whether TDF could do something about it.



gives good-enough performance.
If not, restrict commits to compilerplugins/ to be less frequent, and see
whether that increases the ccache hit rate and results in good-enough
performance.


I do not favor compiler_check=content... as this means calculating a
hash of the compiler _and the plugin every time.
the plugin.so alone is 150MB (which is quite insane btw considering
that clang itself is ~50MB)


(Not sure where you get those ~50MB for clang.  For example, 
/usr/bin/clang-3.8 on my F24 box is merely 92K, but isn't linked 
statically, which is atypical for Clang builds; on the other hand, my 
local CMAKE_BUILD_TYPE=RelWithDebInfo trunk build, statically linked, is 
even 1.5G.)



I really do not need to waste too much time experimenting to know that
hashing 15,000 X 200MB = 3TB per build is going to be a waste.


It should merely be a matter of setting one environment variable and 
watching the effect on 
<http://ci.libreoffice.org/job/lo_gerrit/Config=linux_clang_dbgutil_64> 
throughput.



compiler_check=string  is no better since that would actually run
these as external process for each ccache invocation
bearing in mind that a build is north of 15K of theses...


Would run what as external process for each ccache invocation?  Do you 
confuse "compiler_check=string:value" with "compiler_check=a command 
string"?



What I suggest is:

1/ allow the plugins to be built standalone and delivered (ideally,
spin it in a sub-module). Allow configure.ac to use a 'external
version of the compiler plugin.
2/ work on the plugin in a branch.. (or ideally in a sub-module), push
core.git needed fixes in advance of merging the pluging changes
3/ every so often merge the plugin changes... (if it is a submodule it
is just a matter of moving the submodule ref in core.git) (if 2/ was
followed that does not break master and master had been compatible
with if for some time
4/ at that point a jenkins job will use 1/ to deploy a new version of
the plugin... everything will be build with that from that point on
(again if it is a submodule.. that can be cloned and built
stand-alone.. which would be less wastefull thatn maintaining a full
core.git workspace for that purpose on each concerned slaves)
5/ too old gerrit patch could fails.. but that is fine, they need to
be rebased anyway.. and hopefully that will give an incentive to
people not to keep patches on old base...


See above for why "aggressive rebasing" might not always be desirable. 
(Plus, it shifts one more burden to---newbie---contributors how to react 
to "random" breakage of the changes the submit to Gerrit.)


I'm of course open to a more restricted approac

Re: compiler plugin

[Norbert Thiebaud]

On Wed, Jul 13, 2016 at 4:18 AM, Stephan Bergmann <sberg...@redhat.com> wrote:
>
> The idea behind the second choice is to periodically update and rebuild the
> bot's compilerplugins repo, so that sequences of LO builds on the bot are
> guaranteed to all use the same plugin.so and be able to reuse cached objects
> across those builds.  However, that would mean that Gerrit changes based on
> a relatively old code base could be built against a newer version of the
> compilerpluigns repo, running into warnings/errors from new plugins, the
> fixes for which across the LO code base not yet being included in the code
> base revision the change is based on.  So I think this approach isn't
> feasible.


Actually that is very feasible. since
1/ the solution for these old-based change is 'rebase'

2/ that has to be done anyway before the said patch is the be
integrated into master.


> (Another problem would be that e.g. the name of a class from the
> LO code base can be whitelisted in one of the plugins, to suppress
> warnings/errors from that class.  If the name of the class changes in the LO
> code base, the compilerplugins repo must be changed in sync.)

That sound like the whole contraption is quite fragile and random.. if
you have to 'whitelist' random 'class'
directly in the pluging... I'd suggest there is something
fondamentally wrong in the process.
whitelisting, or more eactly a way to say to the plugin: 'shut-up, I know'
should be done by annotating the source code not by patching the plugin.

>
>
> So my proposal would be as follows:  First, check whether enabling
> compiler_check=content or the compiler_check=string:X setup (and increasing
> the ccache size if necessary and possible)

the cache size is 100GB dedicated to clang... that is quite a chunk of
disk already.


> gives good-enough performance.
> If not, restrict commits to compilerplugins/ to be less frequent, and see
> whether that increases the ccache hit rate and results in good-enough
> performance.

I do not favor compiler_check=content... as this means calculating a
hash of the compiler _and the plugin every time.
the plugin.so alone is 150MB (which is quite insane btw considering
that clang itself is ~50MB)
I really do not need to waste too much time experimenting to know that
hashing 15,000 X 200MB = 3TB per build is going to be a waste.

compiler_check=string  is no better since that would actually run
these as external process for each ccache invocation
bearing in mind that a build is north of 15K of theses...

What I suggest is:

1/ allow the plugins to be built standalone and delivered (ideally,
spin it in a sub-module). Allow configure.ac to use a 'external
version of the compiler plugin.
2/ work on the plugin in a branch.. (or ideally in a sub-module), push
core.git needed fixes in advance of merging the pluging changes
3/ every so often merge the plugin changes... (if it is a submodule it
is just a matter of moving the submodule ref in core.git) (if 2/ was
followed that does not break master and master had been compatible
with if for some time
4/ at that point a jenkins job will use 1/ to deploy a new version of
the plugin... everything will be build with that from that point on
(again if it is a submodule.. that can be cloned and built
stand-alone.. which would be less wastefull thatn maintaining a full
core.git workspace for that purpose on each concerned slaves)
5/ too old gerrit patch could fails.. but that is fine, they need to
be rebased anyway.. and hopefully that will give an incentive to
people not to keep patches on old base...


Norbert
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: compiler plugin

[Stephan Bergmann]

On 07/12/2016 09:32 AM, Norbert Thiebaud wrote:

so I ran some number... after upgrading ccache

clang+pluging+dbgutil  (time result in minutes.. elapsed/user/system)

cold: 33/840/50
hot: 9/79/14
no-op: 4/46/1

clang+dbgutil (no plugins)

cold: 26/605/46
hot: 9/79/14
no-op: 4/46/1

gcc-dbgutil

cold: 28/621/97
hot: 9/79/14
no-op: 4/45/1

note: none of these comprise make check

so the cost of the plugins on a full build is 7 minutes elapsed, ~240
minutes cpu.

ccache works fine... on the other hand any change in any of the
plugins invalidate the cache...


Looking at the ccache documentation at 
 and the 
source code at :


ccache detects that clang is called in a way so that it uses our 
compilerplugins/obj/plugin.so, and then includes information about both 
the clang executable itself and the plugin.so in its hash (which 
determines whether a cached object has been built with the same 
toolchain as a newly requested object).


ccache knows different ways of what kind of information about a 
toolchain entity (the clang executable itself and the plugin.so) to 
include in the hash:  The default is compiler_check=mtime, which 
includes the entity's mtime and size.


Now imagine the Gerrit/Jenkins bot does three builds A, B, C in 
sequence, where A and C are based on the same revision of 
compilerplugins/, while B is based on a different revision.  That means 
that compilerplugins/obj/plugin.so will be built anew for each of A, B, 
C, and will have different mtime for A and C.  That in turn means that 
/any/ objects cached during build A will not be taken into account 
during build C, even if they would still be in the cache after build B.


Another ccache configuration option is compiler_check=content, which 
uses a hash of the entity's content instead of its mtime/size.  If the 
bot's underlying toolchain produces sufficiently reproducible builds, so 
that compilerplugins/obj/plugin.so from builds A and C have identical 
content, then build C should be able to reuse the objects from build A 
that are still in the cache (given a large enough cache).


compiler_check=content computes the hash of both the clang executable 
itself and the plugin.so for each ccache request.  Should that turn out 
to slow things down too much compared to compiler_check=mtime, a third 
option would be comiler_check=string:X, which simply includes the 
information "X" for each entity (without looking at the entity's real 
characteristics at all).  For each build done by the bot, that X could 
e.g. be determined as the SHA1 of the latest git commit that modified 
compilerplugins/ (and passed from the build to ccache via the 
CCACHE_COMPILERCHECK environment variable corresponding to the 
compiler_check configuration setting).  (That would use the same "X" 
when determining the characteristics of both the clang executable itself 
and the plugin.so, which would be fine assuming that the clang 
executable itself never changes anyway, at least not in a way that 
necessarily requires rebuilds.  Worst, the ccache would need to be 
cleaned by the bot's admin when installing a new version of Clang.) 
This option would also work if the compiler_check=content option should 
not work because the bot's builds of compilerplugins/obj/plugin.so turn 
out to not produce exactly the same content.



I've enabled an additional build for gerrit doing clang + plugins on linux
we will see how that perform in average.
preliminary observation is that there is way to much churn in the
plugins for this to be viable at this time


There are generally two ways to address bot performance issues caused by 
changes to comilerplugins/:  One, make the builds faster.  Two, make 
changes to compilerplugins/ less frequent.


For one, one option should be to make ccache more effective by using 
compiler_check=content or compiler_check=string:X as described above 
(and potentially also increasing the ccache size if necessary and 
possible).  Another option might be to just throw more computing power 
at the problem.


For two, two options have been discussed so far:  Either restrict 
commits to compilerplugins/ to certain points in time (when they come in 
in batches).  Or break compilerplugins/ out into its own git repo.


The main problem I see with the first choice is that new plugins, or 
substantial changes to existing ones, typically also require changes to 
very many files across the "real" LO code base.  Doing such changes on a 
branch (so that it can be merged later, at the next point when commits 
to compilerplugins/ are allowed), would thus likely result in 
large-scale merge conflicts.  The solution might be to commit the 
resulting changes to "real" LO code base directly, and only hold off the 
compilerplugins/ changes themselves on a branch.


The idea behind the second choice is to periodically update and rebuild 
the bot's 

compiler plugin

[David Ostrovsky]

On Tue, Jul 12, 2016 at 02:58:35PM +0200, Stephan Bergmann  wrote:
> where the first link, 
is the
> one to the results of the new Clang+plugins bot.  However, it is
unclear to
> me how to navigate from that page to the relevant information about
the
> failure, .

This is well known issue of non-obvious way to find out where actually
the logs of Jenkins matrix job are. And if you think you were happy to
find the logs for the right patch set and platform combination, you
start the game from the beginning to find out where the logs for
another patch set/platform combinations are. There are *four* different
kind of meta data involved in the process:

1. Gerrit: find out the right comment in the comment table from the
Jenkins Matrix job (watch for the patch set it was commented on)
2. Jenkins: find out the matrix job that corresponds to the comment in
1
3. Jenkins: find out the right platform job from the matrix job in 2
4. Jenkins: find out single job build outcome for the platform job in 3

Too many steps? Confusing? Something that could be improved?

Khai from the Openstack project and myself wrote verify-status gerrit
plugin: [1], that maintains secondary verify notification channel (the
fist one is reviewers notification channel; the comment table on change
screen should only include human comments and no spam with build
start/end notifications), persists the data in its own database (one
table) and loads and visualizes the data per patch set on the change
screen. With this plugin deployed, all 4 steps above are gone. Either
drop down control is used with links to the build log per per job that
corresponds to the patch set currently loaded on the change screen. Or,
alternatively, dedicated verify-status panel from the plugin is
rendered directly on the change screen.

Announcement: [2]. Screenshot: [3].

ATM Jenkins trigger plugin must be extended to support this verify
channel, e.g. plugin ssh command must be invoked to add build events to
the plugin data: [4].

Needless to say, that ones this works, the notification fire hose that
spams comment table with build notifications should be shut down.
Moreover the data gathered in the plugin can be easily accessed and
evaluated either directly with database own SQL tools, or even remotely
per plugin own ssh command: [5].

* [1] https://gerrit.googlesource.com/plugins/verify-status/+/master/sr
c/main/resources/Documentation
* [2] http://lists.openstack.org/pipermail/openstack-infra/2016-March/0
04098.html
* [3] https://imgur.com/KDquXfy
* [4] https://gerrit.googlesource.com/plugins/verify-status/+/master/sr
c/main/resources/Documentation/cmd-save.md
* [5] https://gerrit.googlesource.com/plugins/verify-status/+/master/sr
c/main/java/com/googlesource/gerrit/plugins/verifystatus/commands/Verif
yStatusAdminQueryShell.java


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: compiler plugin

[Miklos Vajna]

Hi,

On Tue, Jul 12, 2016 at 02:58:35PM +0200, Stephan Bergmann 
 wrote:
> where the first link,  is the
> one to the results of the new Clang+plugins bot.  However, it is unclear to
> me how to navigate from that page to the relevant information about the
> failure, 
> .

At , hover your mouse over
"default", click on the appearing arrow, then choose "console output".

It's quite similar how you could view previous build results already.

Regards,

Miklos


signature.asc
Description: Digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: compiler plugin

[Stephan Bergmann]

On 07/12/2016 09:32 AM, Norbert Thiebaud wrote:

I've enabled an additional build for gerrit doing clang + plugins on linux


So Jenkins comments on Gerrit changes now contain two links, one to the 
results of the three old bots (Linux, OS X, Windows) and one to the 
results of the new Clang+plugins bot.  For example, the seventh comment 
to  reads



Jenkins
13:27

Patch Set 1:

Build Failed

http://ci.libreoffice.org/job/lo_gerrit/25/ : FAILURE

http://ci.libreoffice.org/job/lo_gerrit_master/18776/ : SUCCESS


where the first link,  is 
the one to the results of the new Clang+plugins bot.  However, it is 
unclear to me how to navigate from that page to the relevant information 
about the failure, 
.


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

compiler plugin

[Norbert Thiebaud]

so I ran some number... after upgrading ccache

clang+pluging+dbgutil  (time result in minutes.. elapsed/user/system)

cold: 33/840/50
hot: 9/79/14
no-op: 4/46/1

clang+dbgutil (no plugins)

cold: 26/605/46
hot: 9/79/14
no-op: 4/46/1

gcc-dbgutil

cold: 28/621/97
hot: 9/79/14
no-op: 4/45/1

note: none of these comprise make check

so the cost of the plugins on a full build is 7 minutes elapsed, ~240
minutes cpu.

ccache works fine... on the other hand any change in any of the
plugins invalidate the cache...

I've enabled an additional build for gerrit doing clang + plugins on linux
we will see how that perform in average.
preliminary observation is that there is way to much churn in the
plugins for this to be viable at this time

Norbert
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice-bugs] [Bug 60148] Clean up warnings from the Clang compiler plugin

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=60148

Lubos Lunak l.lu...@suse.cz changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Lubos Lunak l.lu...@suse.cz ---
I cannot see any warnings remaining in current master build, so assuming done,
closing.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 60148] Clean up warnings from the Clang compiler plugin

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=60148

Lubos Lunak l.lu...@suse.cz changed:

   What|Removed |Added

   Assignee|sa...@seznam.cz |libreoffice-b...@lists.free
   ||desktop.org

--- Comment #5 from Lubos Lunak l.lu...@suse.cz ---
As long as there are any warnings left, this bugreport is still valid by
definition. If there are false warnings, those should get fixed.

But by the time I wrote comment #3 I did
9a4fb0643e51cb89649000493e8c5dac5a306bc4, which was a valid warning, so I
expect there still are more valid warnings.

As for warnings left for debug or other purposes, those should be handled
somehow too - we do not leave native compiler warnings in the code either.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 60148] Clean up warnings from the Clang compiler plugin

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=60148

Cao Cuong Ngo cao.cuong@gmail.com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 60148] Clean up warnings from the Clang compiler plugin

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=60148

Lubos Lunak l.lu...@suse.cz changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #3 from Lubos Lunak l.lu...@suse.cz ---
This is not fixed yet, I can still see a number of warnings.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 60148] Clean up warnings from the Clang compiler plugin

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=60148

--- Comment #4 from Cao Cuong Ngo cao.cuong@gmail.com ---

As you can see from inline comments from https://gerrit.libreoffice.org/2544,
we intentionally left some unused variable warnings: all the mutex warnings and
some other unused variables are left untouched for debug purpose. Beside,
there's one or two false positive from the plugin.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 60148] Clean up warnings from the Clang compiler plugin

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=60148

podkotelnik sa...@seznam.cz changed:

   What|Removed |Added

   Assignee|libreoffice-b...@lists.free |sa...@seznam.cz
   |desktop.org |

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[PUSHED] fdo#60148 Clean up warnings from the Clang compiler plugin

[Eike Rathke (via Code Review)]

Hi,

Thank you for your patch!  It has been merged to LibreOffice.

If you are interested in details, please visit

https://gerrit.libreoffice.org/2544

Approvals:
  Eike Rathke: Verified; Looks good to me, approved


-- 
To view, visit https://gerrit.libreoffice.org/2544
To unsubscribe, visit https://gerrit.libreoffice.org/settings

Gerrit-MessageType: merged
Gerrit-Change-Id: I08d755677c46c476710ecbd067ed9f7e2f54a671
Gerrit-PatchSet: 8
Gerrit-Project: core
Gerrit-Branch: master
Gerrit-Owner: Cao Cuong Ngo cao.cuong@gmail.com
Gerrit-Reviewer: Eike Rathke er...@redhat.com
Gerrit-Reviewer: Thomas Arnhold tho...@arnhold.org

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice-bugs] [Bug 60148] Clean up warnings from the Clang compiler plugin

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=60148

Commit Notification libreoffice-comm...@lists.freedesktop.org changed:

   What|Removed |Added

 Whiteboard|EasyHack,   |EasyHack,
   |DifficultyBeginner, |DifficultyBeginner,
   |SkillCpp, TopicCleanup  |SkillCpp, TopicCleanup
   ||target:4.1.0

--- Comment #2 from Commit Notification 
libreoffice-comm...@lists.freedesktop.org ---
nccuong committed a patch related to this issue.
It has been pushed to master:

http://cgit.freedesktop.org/libreoffice/core/commit/?id=a6b91730053fc61416716ae176081b91de52532b

fdo#60148 Clean up warnings from the Clang compiler plugin



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

Re: [PATCH] fdo#60148 Clean up warnings from the Clang compiler plugin

[Ngo Cao Cuong]

All of my past  future contributions to LibreOffice may be licensed
under the MPL/LGPLv3+ dual license.

On 03/04/2013 06:20 PM, Cao Cuong Ngo (via Code Review) wrote:
 Hi,

 I have submitted a patch for review:

 https://gerrit.libreoffice.org/2544

 To pull it, you can do:

 git pull ssh://gerrit.libreoffice.org:29418/core refs/changes/44/2544/1

 fdo#60148 Clean up warnings from the Clang compiler plugin

 Cleaned all the warnings from loplugin. Some warnings come from the untar 
 downloaded sources couldn't be fixed.

 Change-Id: I08d755677c46c476710ecbd067ed9f7e2f54a671
 ---
 M UnoControls/source/base/registercontrols.cxx
 M accessibility/source/extended/accessibleeditbrowseboxcell.cxx
 M autodoc/source/parser_i/idoc/cx_dsapi.cxx
 M basegfx/source/polygon/b2dpolygontools.cxx
 M basegfx/source/polygon/b3dpolypolygontools.cxx
 M basic/source/runtime/iosys.cxx
 M basic/source/sbx/sbxobj.cxx
 M basic/source/sbx/sbxvalue.cxx
 M chart2/source/controller/dialogs/tp_DataSource.cxx
 M chart2/source/controller/main/ChartDropTargetHelper.cxx
 M chart2/source/controller/main/ChartFrameloader.cxx
 M chart2/source/model/template/BarChartTypeTemplate.cxx
 M chart2/source/model/template/ChartTypeTemplate.cxx
 M connectivity/source/commontools/dbtools2.cxx
 M connectivity/source/drivers/file/FTable.cxx
 M connectivity/source/drivers/mork/MResultSetMetaData.cxx
 M connectivity/source/drivers/postgresql/pq_xindexcolumns.cxx
 M connectivity/source/drivers/postgresql/pq_xtable.cxx
 M connectivity/source/drivers/postgresql/pq_xtables.cxx
 M connectivity/source/drivers/postgresql/pq_xuser.cxx
 M connectivity/source/parse/sqlnode.cxx
 M cppcanvas/source/mtfrenderer/emfplus.cxx
 M cui/source/dialogs/cuigaldlg.cxx
 M cui/source/tabpages/tpbitmap.cxx
 M cui/source/tabpages/tpgradnt.cxx
 M cui/source/tabpages/tphatch.cxx
 M cui/source/tabpages/tplnedef.cxx
 M desktop/source/app/lockfile2.cxx
 M drawinglayer/source/geometry/viewinformation2d.cxx
 M drawinglayer/source/geometry/viewinformation3d.cxx
 M drawinglayer/source/primitive3d/polygontubeprimitive3d.cxx
 M drawinglayer/source/primitive3d/sdrextrudeprimitive3d.cxx
 M drawinglayer/source/primitive3d/sdrlatheprimitive3d.cxx
 M editeng/source/misc/hangulhanja.cxx
 M filter/source/config/cache/filterfactory.cxx
 M filter/source/graphicfilter/icgm/class2.cxx
 M filter/source/placeware/exporter.cxx
 M filter/source/xsltdialog/xmlfiltertabpagexslt.cxx
 M forms/source/xforms/datatypes.cxx
 M formula/source/ui/dlg/funcpage.cxx
 M framework/source/services/autorecovery.cxx
 M helpcompiler/source/HelpCompiler.cxx
 M hwpfilter/source/hwpreader.cxx
 M i18npool/source/defaultnumberingprovider/defaultnumberingprovider.cxx
 M idl/source/prj/command.cxx
 M jvmfwk/source/elements.cxx
 M l10ntools/source/xrmmerge.cxx
 M lotuswordpro/source/filter/lwpoleobject.cxx
 M padmin/source/adddlg.cxx
 M reportdesign/source/filter/xml/xmlImportDocumentHandler.cxx
 M rsc/source/rscpp/cpp5.c
 M sal/inc/sal/log-areas.dox
 M sc/qa/unit/helper/qahelper.hxx
 M sc/qa/unit/subsequent_export-test.cxx
 M sc/qa/unit/subsequent_filters-test.cxx
 M sc/source/core/tool/compiler.cxx
 M sc/source/filter/oox/extlstcontext.cxx
 M sc/source/ui/drawfunc/drawsh.cxx
 M sc/source/ui/pagedlg/scuitphfedit.cxx
 M sc/source/ui/vba/vbafont.cxx
 M sd/source/filter/eppt/pptx-epptooxml.cxx
 M sfx2/source/appl/appuno.cxx
 M sfx2/source/appl/linksrc.cxx
 M sfx2/source/control/bindings.cxx
 M sfx2/source/control/dispatch.cxx
 M sfx2/source/control/shell.cxx
 M sfx2/source/dialog/dinfdlg.cxx
 M sfx2/source/dialog/filedlghelper.cxx
 M sfx2/source/doc/sfxbasemodel.cxx
 M sfx2/source/menu/mnuitem.cxx
 M sfx2/source/view/sfxbasecontroller.cxx
 M slideshow/source/engine/OGLTrans/generic/OGLTrans_TransitionerImpl.cxx
 M slideshow/source/engine/transitions/fanwipe.cxx
 M svtools/source/contnr/DocumentInfoPreview.cxx
 M svx/source/dialog/srchdlg.cxx
 M svx/source/fmcomp/gridcell.cxx
 M svx/source/form/navigatortree.cxx
 M svx/source/gallery2/galobj.cxx
 M svx/source/sdr/primitive2d/sdrprimitivetools.cxx
 M unotools/source/config/configitem.cxx
 M vcl/source/filter/wmf/enhwmf.cxx
 M vcl/source/gdi/pdfwriter_impl.cxx
 M vcl/source/window/window.cxx
 M vcl/unx/generic/printer/printerinfomanager.cxx
 M vcl/unx/gtk/fpicker/SalGtkFolderPicker.cxx
 M writerperfect/source/draw/WPGImportFilter.cxx
 86 files changed, 1,510 insertions(+), 1,624 deletions(-)





___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[PATCH] fdo#60148 Clean up warnings from the Clang compiler plugin

[Cao Cuong Ngo (via Code Review)]

Hi,

I have submitted a patch for review:

https://gerrit.libreoffice.org/2544

To pull it, you can do:

git pull ssh://gerrit.libreoffice.org:29418/core refs/changes/44/2544/1

fdo#60148 Clean up warnings from the Clang compiler plugin

Cleaned all the warnings from loplugin. Some warnings come from the untar 
downloaded sources couldn't be fixed.

Change-Id: I08d755677c46c476710ecbd067ed9f7e2f54a671
---
M UnoControls/source/base/registercontrols.cxx
M accessibility/source/extended/accessibleeditbrowseboxcell.cxx
M autodoc/source/parser_i/idoc/cx_dsapi.cxx
M basegfx/source/polygon/b2dpolygontools.cxx
M basegfx/source/polygon/b3dpolypolygontools.cxx
M basic/source/runtime/iosys.cxx
M basic/source/sbx/sbxobj.cxx
M basic/source/sbx/sbxvalue.cxx
M chart2/source/controller/dialogs/tp_DataSource.cxx
M chart2/source/controller/main/ChartDropTargetHelper.cxx
M chart2/source/controller/main/ChartFrameloader.cxx
M chart2/source/model/template/BarChartTypeTemplate.cxx
M chart2/source/model/template/ChartTypeTemplate.cxx
M connectivity/source/commontools/dbtools2.cxx
M connectivity/source/drivers/file/FTable.cxx
M connectivity/source/drivers/mork/MResultSetMetaData.cxx
M connectivity/source/drivers/postgresql/pq_xindexcolumns.cxx
M connectivity/source/drivers/postgresql/pq_xtable.cxx
M connectivity/source/drivers/postgresql/pq_xtables.cxx
M connectivity/source/drivers/postgresql/pq_xuser.cxx
M connectivity/source/parse/sqlnode.cxx
M cppcanvas/source/mtfrenderer/emfplus.cxx
M cui/source/dialogs/cuigaldlg.cxx
M cui/source/tabpages/tpbitmap.cxx
M cui/source/tabpages/tpgradnt.cxx
M cui/source/tabpages/tphatch.cxx
M cui/source/tabpages/tplnedef.cxx
M desktop/source/app/lockfile2.cxx
M drawinglayer/source/geometry/viewinformation2d.cxx
M drawinglayer/source/geometry/viewinformation3d.cxx
M drawinglayer/source/primitive3d/polygontubeprimitive3d.cxx
M drawinglayer/source/primitive3d/sdrextrudeprimitive3d.cxx
M drawinglayer/source/primitive3d/sdrlatheprimitive3d.cxx
M editeng/source/misc/hangulhanja.cxx
M filter/source/config/cache/filterfactory.cxx
M filter/source/graphicfilter/icgm/class2.cxx
M filter/source/placeware/exporter.cxx
M filter/source/xsltdialog/xmlfiltertabpagexslt.cxx
M forms/source/xforms/datatypes.cxx
M formula/source/ui/dlg/funcpage.cxx
M framework/source/services/autorecovery.cxx
M helpcompiler/source/HelpCompiler.cxx
M hwpfilter/source/hwpreader.cxx
M i18npool/source/defaultnumberingprovider/defaultnumberingprovider.cxx
M idl/source/prj/command.cxx
M jvmfwk/source/elements.cxx
M l10ntools/source/xrmmerge.cxx
M lotuswordpro/source/filter/lwpoleobject.cxx
M padmin/source/adddlg.cxx
M reportdesign/source/filter/xml/xmlImportDocumentHandler.cxx
M rsc/source/rscpp/cpp5.c
M sal/inc/sal/log-areas.dox
M sc/qa/unit/helper/qahelper.hxx
M sc/qa/unit/subsequent_export-test.cxx
M sc/qa/unit/subsequent_filters-test.cxx
M sc/source/core/tool/compiler.cxx
M sc/source/filter/oox/extlstcontext.cxx
M sc/source/ui/drawfunc/drawsh.cxx
M sc/source/ui/pagedlg/scuitphfedit.cxx
M sc/source/ui/vba/vbafont.cxx
M sd/source/filter/eppt/pptx-epptooxml.cxx
M sfx2/source/appl/appuno.cxx
M sfx2/source/appl/linksrc.cxx
M sfx2/source/control/bindings.cxx
M sfx2/source/control/dispatch.cxx
M sfx2/source/control/shell.cxx
M sfx2/source/dialog/dinfdlg.cxx
M sfx2/source/dialog/filedlghelper.cxx
M sfx2/source/doc/sfxbasemodel.cxx
M sfx2/source/menu/mnuitem.cxx
M sfx2/source/view/sfxbasecontroller.cxx
M slideshow/source/engine/OGLTrans/generic/OGLTrans_TransitionerImpl.cxx
M slideshow/source/engine/transitions/fanwipe.cxx
M svtools/source/contnr/DocumentInfoPreview.cxx
M svx/source/dialog/srchdlg.cxx
M svx/source/fmcomp/gridcell.cxx
M svx/source/form/navigatortree.cxx
M svx/source/gallery2/galobj.cxx
M svx/source/sdr/primitive2d/sdrprimitivetools.cxx
M unotools/source/config/configitem.cxx
M vcl/source/filter/wmf/enhwmf.cxx
M vcl/source/gdi/pdfwriter_impl.cxx
M vcl/source/window/window.cxx
M vcl/unx/generic/printer/printerinfomanager.cxx
M vcl/unx/gtk/fpicker/SalGtkFolderPicker.cxx
M writerperfect/source/draw/WPGImportFilter.cxx
86 files changed, 1,510 insertions(+), 1,624 deletions(-)




-- 
To view, visit https://gerrit.libreoffice.org/2544
To unsubscribe, visit https://gerrit.libreoffice.org/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: I08d755677c46c476710ecbd067ed9f7e2f54a671
Gerrit-PatchSet: 1
Gerrit-Project: core
Gerrit-Branch: master
Gerrit-Owner: Cao Cuong Ngo cao.cuong@gmail.com

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice-bugs] [Bug 60148] Clean up warnings from the Clang compiler plugin

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=60148

--- Comment #1 from Cao Cuong Ngo cao.cuong@gmail.com ---
Hi, 

I've made a patch for this bug, you can find it here:

https://gerrit.libreoffice.org/2544

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 60148] Clean up warnings from the Clang compiler plugin

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=60148

Lubos Lunak l.lu...@suse.cz changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|sa...@seznam.cz |libreoffice-b...@lists.free
   ||desktop.org

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 60148] Clean up warnings from the Clang compiler plugin

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=60148

podkotelnik sa...@seznam.cz changed:

   What|Removed |Added

   Assignee|libreoffice-b...@lists.free |sa...@seznam.cz
   |desktop.org |

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 60148] New: Clean up warnings from the Clang compiler plugin

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=60148

  Priority: medium
Bug ID: 60148
  Assignee: libreoffice-bugs@lists.freedesktop.org
   Summary: Clean up warnings from the Clang compiler plugin
  Severity: enhancement
Classification: Unclassified
OS: All
  Reporter: l.lu...@suse.cz
  Hardware: Other
Status: UNCONFIRMED
   Version: unspecified
 Component: Libreoffice
   Product: LibreOffice

When LibreOffice is built using the Clang compiler, it can use also a compiler
plugin to provide additional LO-specific warnings. Currently there are a number
of warnings generated by this plugin and they should be all fixed.

See https://wiki.documentfoundation.org/Development/Clang for information on
how to build LO with Clang.

See compilerplugins/README in the sources for information about the additional
warnings. Currently these are:

- unused variable warnings - These are very similar to warnings about basic
types the compilers provide on their own. It should be checked whether it's not
a mistake that the variable is not used, and the code should be either fixed or
the variable removed.

- incorrect block indentation - if several statements are in the body of
if/while/for statements, they need to be inside {}. The warning points out code
the possibly lacks these, although in many cases it is code that is technically
correct but just poorly formatted (very common case is writing else if on two
lines instead of just one). Such code should be either fixed or formatted
properly.

- log areas - macros such as SAL_INFO and SAL_WARN have a log area as their
first argument, which is a string, and this allows selective
enabling/disabling. As a protection against mistyping and also to ensure some
consistency, a warning is produced for areas that are not listed in
sal/inc/sal/log-areas.dox . Code with unknown areas should have either them
fixed or added to the list. Note that because of the selective
enabling/disabling, there should be one areas for logical area of code, and it
should not be overly generic (e.g. 'sw' for the whole of Writer is too broad).

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 60148] Clean up warnings from the Clang compiler plugin

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=60148

Lubos Lunak l.lu...@suse.cz changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Whiteboard||EasyHack,
   ||DifficultyBeginner,
   ||SkillCpp, TopicCleanup
 Ever confirmed|0   |1

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

Re: [PATCH] Introducing compiler plugin support

[Lubos Lunak]

On Tuesday 09 of October 2012, Lubos Lunak wrote:
 On Friday 05 of October 2012, Lubos Lunak wrote:
   Hello,
 
   attached is my implementation of basic build support for using Clang
  compiler plugin during building LO. I'm posting it here first in case our
  build system people have different ideas to how I have integrated it in
  the build system, if there are no comments, I will push it.

  Pushed. There is a README included, but some highlights:

 One thing I forgot:

 If you use this together with ccache, you need ccache git checkout 
(specifically [1], not even 3.1.8 is new enough), otherwise ccache will 
misinterpret '-Xclang loplugin' as a second source file to compile and will 
not cache anything. For those using packages from home:llunak:ccache in OBS, 
you need to update too.

[1] 
http://gitweb.samba.org/?p=ccache.git;a=blobdiff;f=compopt.c;h=77b57f592b13f0c3cf8216ad2760ade421d0cb44;hp=35d51ad43d5e5a94ccf0d8a6c4e9ddaedccab631;hb=8e005b067d8c2423e24ee14ffdee8343f650f1e8;hpb=806b511643ec830f50d6d6975b2ecfd1876a6f17

-- 
 Lubos Lunak
 l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [PATCH] Introducing compiler plugin support

[Lubos Lunak]

On Friday 05 of October 2012, Lubos Lunak wrote:
  Hello,

  attached is my implementation of basic build support for using Clang
 compiler plugin during building LO. I'm posting it here first in case our
 build system people have different ideas to how I have integrated it in the
 build system, if there are no comments, I will push it.

 Pushed. There is a README included, but some highlights:

- is enabled automatically by --enable-dbgutil if Clang headers are found or 
manually using --enable-compiler-plugins
- I'll enable it for the Clang tinderbox soon
- for the time being, -Werror does not affect these warnings, just in case 
somebody builds with --enable-dbgutil --enable-werror, for obvious reasons 
below
- there is a warning about unused variables of types marked SAL_WARN_UNUSED 
plus some C++ std classes ; quite a number of hits. Feel free to tag all 
those Point, Rectangle, etc. classes with it too, as long as it's certain for 
the class that a mere presence of a variable of that type does nothing in 
practice.
- there is a warning about

if( a != 0 )
b = 2;
c = 3;

 which triggers a lot of warnings, many of them about code like

if( a == 1 )
foo();
else
if( a == 2 )
bar();
whatever();

 This is a valid warning, because it may appear that the whatever() call is 
part of the else block. I consider this to be poorly formatted code and find 
moving the second if up to the else line a much better solution than trying 
to detect this case in the compiler check.

 There may be possibly some problems that I haven't noticed, so feel free to 
point out whatever you thing the plugin detects wrong. I'll eventually 
make -Werror have an effect on these too for the --enable-werror crowd.

On Monday 08 of October 2012, Michael Stahl wrote:
 On 05/10/12 18:22, Lubos Lunak wrote:
  +$(CLANGOUTDIR)/compileplugin.so: $(2)
  +$(CLANGOUTDIR)/compileplugin.so: CLANGOBJS += $(2)
  +
  +$(CLANGOUTDIR)/compileplugin.so: $(CLANGOBJS)

 there's a bit of redundancy there.

 That actually seems to be needed for whatever reason.

-- 
 Lubos Lunak
 l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [PATCH] Introducing compiler plugin support

[Michael Stahl]

 On Monday 08 of October 2012, Michael Stahl wrote:
 On 05/10/12 18:22, Lubos Lunak wrote:
 +$(CLANGOUTDIR)/compileplugin.so: $(2)
 +$(CLANGOUTDIR)/compileplugin.so: CLANGOBJS += $(2)
 +
 +$(CLANGOUTDIR)/compileplugin.so: $(CLANGOBJS)

 there's a bit of redundancy there.
 
  That actually seems to be needed for whatever reason.

d'oh, now i remember: target local variables only work in a rule or in a
target local variable definition; specifically that
$(CLANGOUTDIR)/compileplugin.so: $(CLANGOBJS) dependency evaluates
global $(CLANGOBJS) and it will be empty.

sorry for not noticing this common pitfall earlier.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [PATCH] Introducing compiler plugin support

[Caolán McNamara]

On Tue, 2012-10-09 at 17:26 +0200, Lubos Lunak wrote:
 - there is a warning about unused variables of types marked SAL_WARN_UNUSED 
 plus some C++ std classes ; quite a number of hits. Feel free to tag all 
 those Point, Rectangle, etc. classes with it too, as long as it's certain for 
 the class that a mere presence of a variable of that type does nothing in 
 practice.

That's cool, very cool.

C.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [PATCH] Introducing compiler plugin support

[Michael Stahl]

On 05/10/12 18:22, Lubos Lunak wrote:
 
  Hello,
 
  attached is my implementation of basic build support for using Clang 
 compiler 
 plugin during building LO. I'm posting it here first in case our build system 
 people have different ideas to how I have integrated it in the build system, 
 if there are no comments, I will push it.

hmm... so that effectively needs to be built as a bootstrap step and
the build system basically assumes that it's been done already.  which
seems appropriate since probably ~everything would need to have a
dependency on it otherwise.

the stuff used for bootstrap seems to live in the top-level directory
and solenv/ (and dmake/) currently... but i don't really have an opinion
on how that should look...

only problem is that this seems to generate files below the new
compilerplugins/ dir, in the source tree...  which doesn't make it any
worse than other parts of the bootstrapping.

 +$(CLANGOUTDIR)/compileplugin.so: $(2)
 +$(CLANGOUTDIR)/compileplugin.so: CLANGOBJS += $(2)
 +
 +$(CLANGOUTDIR)/compileplugin.so: $(CLANGOBJS)

there's a bit of redundancy there.
hmm actually the .so only has .o dependecies so could just use $^ in the
command.

 +$(CLANGOUTDIR):
 + mkdir -p $(CLANGOUTDIR)

i vaguely remember problems with directories in make 3.81 but that was
probably with pattern rules... ah right in a trivial test this seems to
work with 3.81.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[PATCH] Introducing compiler plugin support

[Lubos Lunak]

 Hello,

 attached is my implementation of basic build support for using Clang compiler 
plugin during building LO. I'm posting it here first in case our build system 
people have different ideas to how I have integrated it in the build system, 
if there are no comments, I will push it.

-- 
 Lubos Lunak
 l.lu...@suse.cz
From 6c63f9809ecaa63e2db6fb606b573ab12f09752f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lubo=C5=A1=20Lu=C5=88=C3=A1k?= l.lu...@suse.cz
Date: Fri, 5 Oct 2012 18:17:13 +0200
Subject: [PATCH] initial support for clang compiler plugins

The plugin is intentionally built using a custom Makefile,
because it's used by gbuild, so I don't want to build the plugin
using gbuild too. It is also intentionally not placed under workdir/,
as that is cleaned by 'make clean', the plugin is cleaned only
by 'make distclean', so that cleaning it doesn't cause ccache misses.
Right now there's a relatively trivial plugin that just checks
for unused rtl::OUString variables.

Change-Id: Ic05eba8d6260eec123c9e699eb5385abfe1b832f
---
 Makefile.top  |6 ++-
 compilerplugins/.gitignore|1 +
 compilerplugins/Makefile  |   23 +
 compilerplugins/Makefile-clang.mk |   47 +
 compilerplugins/Makefile.mk   |   29 +++
 compilerplugins/clang/compileplugin.cxx   |   66 
 compilerplugins/clang/compileplugin.hxx   |   14 ++
 compilerplugins/clang/unusedvariablecheck.cxx |   67 +
 compilerplugins/clang/unusedvariablecheck.hxx |   36 +
 config_host.mk.in |1 +
 configure.in  |   39 ++
 solenv/gbuild/platform/com_GCC_class.mk   |2 +
 solenv/gbuild/platform/com_GCC_defs.mk|6 +++
 13 files changed, 335 insertions(+), 2 deletions(-)
 create mode 100644 compilerplugins/.gitignore
 create mode 100644 compilerplugins/Makefile
 create mode 100644 compilerplugins/Makefile-clang.mk
 create mode 100644 compilerplugins/Makefile.mk
 create mode 100644 compilerplugins/clang/compileplugin.cxx
 create mode 100644 compilerplugins/clang/compileplugin.hxx
 create mode 100644 compilerplugins/clang/unusedvariablecheck.cxx
 create mode 100644 compilerplugins/clang/unusedvariablecheck.hxx

diff --git a/Makefile.top b/Makefile.top
index bb632a2..bd85703 100644
--- a/Makefile.top
+++ b/Makefile.top
@@ -350,10 +350,12 @@ ifeq ($(CROSS_COMPILING),YES)
 	rm -rf $(SRCDIR)/*/$(INPATH_FOR_BUILD)
 endif
 
+include $(SRCDIR)/compilerplugins/Makefile.mk
+
 #
 # Distclean
 #
-distclean : clean
+distclean : clean compilerplugins-clean
 ifeq ($(BUILD_DMAKE),YES)
 	(if [ -f dmake/Makefile ] ; then $(GNUMAKE) -j $(GMAKE_PARALLELISM) -C dmake distclean; fi)  \
 	rm -f solenv/*/bin/dmake*
@@ -391,7 +393,7 @@ endif
 #
 bootstrap: $(WORKDIR)/bootstrap
 
-$(WORKDIR)/bootstrap: solenv/bin/concat-deps.c
+$(WORKDIR)/bootstrap: solenv/bin/concat-deps.c compilerplugins
 	@cd $(SRCDIR)  ./bootstrap
 	@mkdir -p $(dir $@)  touch $@
 
diff --git a/compilerplugins/.gitignore b/compilerplugins/.gitignore
new file mode 100644
index 000..b672fde
--- /dev/null
+++ b/compilerplugins/.gitignore
@@ -0,0 +1 @@
+obj
diff --git a/compilerplugins/Makefile b/compilerplugins/Makefile
new file mode 100644
index 000..4281c12
--- /dev/null
+++ b/compilerplugins/Makefile
@@ -0,0 +1,23 @@
+# -*- Mode: makefile-gmake; tab-width: 4; indent-tabs-mode: t -*-
+#
+# This file is part of the LibreOffice project.
+#
+# This Source Code Form is subject to the terms of the Mozilla Public
+# License, v. 2.0. If a copy of the MPL was not distributed with this
+# file, You can obtain one at http://mozilla.org/MPL/2.0/.
+#
+
+ifeq ($(SOLARENV),)
+ifeq ($(gb_Side),)
+gb_Side:=host
+endif
+include $(dir $(realpath $(lastword $(MAKEFILE_LIST../config_$(gb_Side).mk
+endif
+
+include $(SRCDIR)/compilerplugins/Makefile.mk
+
+all: build
+build: compilerplugins
+clean: compilerplugins-clean
+
+# vim: set noet sw=4 ts=4:
diff --git a/compilerplugins/Makefile-clang.mk b/compilerplugins/Makefile-clang.mk
new file mode 100644
index 000..9c93931
--- /dev/null
+++ b/compilerplugins/Makefile-clang.mk
@@ -0,0 +1,47 @@
+#
+# This file is part of the LibreOffice project.
+#
+# This Source Code Form is subject to the terms of the Mozilla Public
+# License, v. 2.0. If a copy of the MPL was not distributed with this
+# file, You can obtain one at http://mozilla.org/MPL/2.0/.
+#
+
+# Make sure variables in this Makefile do not conflict with other variables (e.g. from gbuild).
+
+CLANGSRC=compileplugin.cxx unusedvariablecheck.cxx
+
+CLANGDIR=/usr
+CLANGBUILD=/usr
+CLANGDEFS=-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -fno-rtti
+CLANGINCLUDES=-I$(CLANGDIR)/include -I$(CLANGDIR)/tools/clang/include -I$(CLANGBUILD)/include -I$(CLANGBUILD)/tools/clang/include 
+CLANGCXXFLAGS=-O2 -Wall -g
+
+CLANGINDIR