[cfe-dev] clang plugins (How to control C++0x adoption in a large codebase?)

[Ahmed Charles]

This reminds me, are there docs on how to write plugins? Or an example
plugin? The idea of having a shared warning/style plugin was something
I talked about with a friend and it'd be interesting to investigate.
From: Douglas Gregor
Sent: 10/13/2011 5:35 PM
To: Jeffrey Yasskin
Cc: cfe-dev at cs.uiuc.edu Developers
Subject: Re: [cfe-dev] How to control C++0x adoption in a large
codebase?

On Oct 5, 2011, at 3:35 PM, Jeffrey Yasskin wrote:

> Hi clang folks,
>
> I'm working on migrating a certain large codebase to C++0x, and we're
> looking for a way to turn on C++0x mode but make sure people don't use
> C++0x features before we're ready for them.
>
> * We need to turn on -std=gnu++0x for the whole codebase at once
> because C++98 and C++0x have different ABIs.

Summarizing side discussion: libstdc++ has a different ABI in C++98
vs. in C++11, libc++ does not.

> * Some of our code needs to be portable to a bunch of compilers we
> don't control, so it needs to be as C++98-compatible as we can make
> it.

And you can't tell libstdc++ to use the C++0x ABI even in C++98 mode?

> * Other parts of the codebase can adopt C++0x features as we make sure
> they work with our compilers and don't have hidden pitfalls.
>
>
> I've attached a patch as one possible way to do this, but I'm
> certainly not wedded to this particular strategy. The patch adds a
> -Wc++98-compat flag, and demonstrates a plan to add individual
> -Wc++98-compat-some-feature flags for each discrete C++0x feature or
> change.
>
> There are pros and cons to this strategy:
> * This makes it easy to control the use of C++0x at a per-file
> granularity. Files that need to be completely C++98-compatible can
> pass -Wc++98-compat, while files that just need to use tested features
> can turn individual ones back on with
> -Wno-c++98-compat-initializer-lists.
> * If every single mention of LangOpts.CPlusPlus0x in the codebase
> triggers a need for an additional warning, that's about 200 extra
> warnings (`git grep CPlusPlus0x|wc`). It'll probably be somewhat less
> given that the attached patch covers 3 uses of CPlusPlus0x with one
> new warning, but there are still features to implement that may
> increase the number.
> * For features that are also extensions to C++98, it's either a
> duplicate warning, or with some extra work, maybe comes along for the
> ride.

> Clearly we'll never be able to do this perfectly, but if we can get
> close, that'd dramatically reduce the build breaks that someone has to
> track down and fix.

> Thoughts? Suggestions? Alternatives?


This seems more like you're enforcing a coding style ("use only the
C++11 features that we like") rather than providing a generally useful
feature. I don't think we should be using the warning mechanism to
enforce a coding style, for a number of reasons:

	- There are many coding styles in the world. Which ones do we pick?
Just those that we as a community like (how do we decide that?), or
all of those for which people submit patches? Is either of these
sustainable in the long term?

	- Experience has shown that warnings that don't default to "on" tend
to be broken over time. Yes, of these warnings are particularly are
easy to implement, but that doesn't mean that they won't get broken or
missed.

Style checking belongs in a plug-in. That way, different organizations
can provide their own style checkers that run along with their builds
without forcing the union of all styles into the mainline Clang
front-end. Better yet, maybe someone will build a configurable style
checker as a plugin, to save the effort of everyone having to
implement their own plugin separately.

I'd like to hear more opinions on whether others consider the proposed
warnings to be coding style enforcement, or whether they are generally
useful. It's clearly not as obvious as if we were proposing
-Wbraces-on-new-line or -Wmethods-names-start-with-a-verb.

	- Doug
_______________________________________________
cfe-dev mailing list
cfe-dev at cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev