This reverts commit 4101fa1841.
Just configure --without-parallelism and always use an explicit make -jN, and be
done with it. I just can't stand that "make[1]: Entering/Leaving directory"
noise around each "[build CXX] compilerplugins/clang/*.cxx" line any more.
A ridiculously fast way of doing this is:
for i in $(pcregrep -l -M -r --include='.*[hc]xx$' \
--exclude-dir=workdir --exclude-dir=instdir '^
{3,}' .)
do
perl -0777 -i -pe 's/^
{3,}/
/gm' $i
done
Change-Id: Iebb93eccbee9e4fc5c4380474ba595858a27ac2c
Reviewed-on: https://gerrit.libreoffice.org/22224
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
...so that isZeroConstant doesn't trigger an assert inside Clang's
isCXX11ConstantExpr when expr is sizeof(x) with x being dependent on a template
argument.
Change-Id: I6bab46e64cc085d597db25994d8bfdc66417fe83
Offline discussion about tdf#96067 "Crash on undo row inserts" brought up the
idea to warn about cases where uses of dynamic_cast are statically knwon to
always fail. Clang's clang::AST::CXXDynamicCastExpr::isAlwaysNull already
implements such a check, reporting true if the casted-from class is final, but
has two issues:
For one, it does not work for template code, when one of the involved types is a
template parameter type (so e.g., DestType->castAs<PointerType>() can crash).
For another, it misses the opportunity to report true if the casted-to type is
final and only derives from the casted-from type non-publicly. My hope was that
this, after the "final" decorations in 548c43238d
"Mark some classes as final," might turn up the culprit of tdf#96067 (with a
scenario similar to the failed dynamic_cast on private derivation in
63b67ab5ca "Use public derivation, and remove
then-unnecessary downcasts")---but not so.
Change-Id: I962ee19820758f9c601f4a292da7f37fa9dff5ce
...to flag places that implicitly derive a class privately instead of publicly,
where accidental private derivation can cause unexpected failure of
dynamic_cast, cf. 63b67ab5ca "Use public
derivation, and remove then-unnecessary downcasts."
Change-Id: I4bcd5c79c7e27380c820e2dd072fa4c4e8980078
I had it locally enabled for like a month now, and it did not produce any more
noise than any of the other plugins.
Change-Id: I94dab702c537969cf32922f6e88b4f5b503cd3f5
I had it locally enabled for like a month now, and it did not produce any more
noise than any of the other plugins, but quite some amount of malformed area
designators had been introduced over time.
Change-Id: I642591496bb9338246ba43a3d988481930c087fb
My clang 3.7 built against libstdc++ 5.2.1 doesn't seem to have it. We
can get away with a non-regex replace all here, though.
Change-Id: Iea36311d89acb434c4e4f7c1f9ce876a6ee84f42
...they don't cause any change in behavior, likely they predated Noel's figuring
out the template part of containsWindowSubclass
Change-Id: I0d5b6bd7f228acef9a0ce1c85fe98fbab89bd7a8
...as a member of ImplCommandButtonData (vcl/source/control/button.cxx), no need
to falsly warn "OutputDevice subclass 'rtl::Reference<VclStatusListener<Button>>'
declared as a pointer member, should be wrapped in VclPtr [loplugin:vclwidgets]"
Probably loplugin:vclwidgets should enable shouldVisitTemplateInstantiations()
and not try to second-guess whether an OutputDevice can be a template argument.
Change-Id: Ia8feb1b1d7504941c35dfbf0aa02dc6a7dd818a0
