-
Stephan Bergmann yazdı
...mostly of C-style casts among arithmetic types, and automatically rewrite those into either static_cast or a functional cast (which should have identical semantics, but where the latter probably looks better for simple cases like casting a literal to a specific type, as in "sal_Int32(0)" vs. "static_cast<sal_Int32>(0)"). The main benefit of reducing the amount of C-style casts across the code base further is so that other plugins (that have not been taught about the complex semantics of C-style cast) can pick those up (cf. the various recent "loplugin:redundantcast" commits, which address those findings after this improved loplugin:cstylecast has been run). Also, I found some places where a C-style cast has probably been applied only to the first part of a larger expression in error (because it's easy to forget parentheses in cases like "(sal_uInt16)VOPT_CLIPMARKS+1"); I'll follow up on those individually. The improved loplugin:cstylecast is careful to output either "(performs: static_cast)" or "(performs: functional cast)", so that compilerplugins/clang/test/cstylecast.cxx can check that the plugin would automatically rewrite to one or the other form. To allow fully-automatic rewriting, this also required loplugin:unnecessaryparen to become a rewriting plugin, at least for the parens-around-cast case (where "((foo)bar)" first gets rewritten to "(static_cast<foo>(bar))", then to "static_cast<foo>(bar)". Rewriting could probably be added to other cases of loplugin:unnecessaryparen in the future, too. (The final version of this patch would even have been able to cope with 361dd257 "Replace some C-style casts in ugly macros with static_cast", so that manual change would not have been necessary after all.) Change-Id: Icd7e319cc38eb58262fcbf7643d177ac9ea0220a Reviewed-on: https://gerrit.libreoffice.org/47798Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
cab0427c