[llvm-commits] [llvm] r164389 - /llvm/trunk/docs/CodingStandards.rst

[Matt Beaumont-Gay]

On Fri, Sep 21, 2012 at 10:47 AM, David Blaikie <dblaikie at gmail.com> wrote:
> Author: dblaikie
> Date: Fri Sep 21 12:47:36 2012
> New Revision: 164389
>
> URL: http://llvm.org/viewvc/llvm-project?rev=164389&view=rev
> Log:
> Document "do not use defaults in covered switch-over-enum" coding standard.
>
> Modified:
>     llvm/trunk/docs/CodingStandards.rst
>
> Modified: llvm/trunk/docs/CodingStandards.rst
> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/CodingStandards.rst?rev=164389&r1=164388&r2=164389&view=diff
> ==============================================================================
> --- llvm/trunk/docs/CodingStandards.rst (original)
> +++ llvm/trunk/docs/CodingStandards.rst Fri Sep 21 12:47:36 2012
> @@ -818,6 +818,24 @@
>  will copy the vtable and RTTI into every ``.o`` file that ``#include``\s the
>  header, bloating ``.o`` file sizes and increasing link times.
>
> +Don't use default labels in fully covered switches over enumerations
> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +``-Wswitch`` warns if a switch, without a default label, over an enumeration
> +does not cover every enumeration value. If you write a default label on a fully
> +covered switch over an enumeration then the ``-Wswitch`` warning won't fire
> +when new elements are added to that enumeration. To help avoid adding these
> +kinds of defaults, Clang has the warning ``-Wcovered-switch-default`` which is
> +off by default but turned on when building LLVM with a version of Clang that
> +supports the warning.
> +
> +A knock-on effect of this stylistic requirement is that when building LLVM with
> +GCC you may get warnings related "control may reach end of non-void function"

Or "variable may be used uninitialized", if the switch is doing
initialization, IIRC, but it may not be worth calling out separately.
Also, missing "to" after "related".

> +if you return from each case of a covered switch-over-enum because GCC assumes
> +that the enum expression may take any representable value, not just those in
> +the enumeration.

This might be phrased a little more clearly as "... not just those of
individual enumerators."