Project:Toolchain/Compiler warnings

Compiler warnings can roughly be divided into two categories:

Issues which can't be ignored where the compiler cannot parse the code (doesn't need a new ebuild revision)
Issues where the compiler points out a likely runtime problem (needs a new ebuild revision)

The hard part to understand is sometimes the difference between the two. Some examples to illustrate:

-Wformat: unless using -Werror=format or similar, this is likely to be just a warning. But it is pointing out an error in the code. Fixing it requires a rebuild for the fix to actually propagate to users in the binary they run. Hence, new revision.
-Wimplicit-function-declaration: this becomes fatal in newer (yet-unreleased) compilers (Modern C porting) but appears as a warning in current compilers. But the compiler is warning that it doesn't have any data for the return type of the function, nor does it have any information on the types of its arguments. It can and will generate code which is completely invalid for the function in reality. Hence, fixes need a new revision.
-Wincompatible-function-pointer-types: this is an interesting one. Depending on the case, fixing this may not make any difference to the code generated, and the compiler is simply pointing out an ambiguity/mistake. Care is needed in determining the correct types. Do not simply copy the "other side" of the warning. Check what all callers of the function expect and what the function itself does with the input.
-Wint-conversion: an example of a warning which is likely to point out a mistake. Depending on the fix, if simply changing to reflect the original version (but not triggering the warning), no new revision is required. If fixing an actual mistake exposed by the warning, obviously a new revision will be needed.
-Wpointer-to-int-cast, -Wint-to-pointer-cast, changing e.g. uint64_t* to uint64_t or vice-versa: all genuine changes which affect the semantics of the code. New revision.

Other situations of note:

Fixing packages with new versions of Boost. This depends! If the issue is simply a missing #include, it's a build-time only fix. If the patch requires changing from Boost-provided functions to newly-standardised versions in the STL, a new revision is required: there is no guarantee that the Boost and standard versions have the same semantics!
Missing includes in C or C++ where it led to an incomplete/missing type definition are build-time-only fixes.
Missing includes in C++ should always be safe as a build-time-only fix, unless you include a header with identifiers of the same name but different semantics (super unlikely), because C++ never had implicit function declarations.
-D_GNU_SOURCE and other feature test macros (see feature_test_macros(7)) do require new revisions as they can affect behavior of some functions (e.g. basename()).

If in doubt, a new revision is recommended. It's less risky, less confusing for users, and it also makes it more likely any errors will be discovered and found faster.

The issues here are similar to the issue of whether a build failure due to a missing header or library is a build-time-only failure. A build-time only failure for one user may be a runtime error (e.g. automagic dependency) for others.

External links

Ebuild Revisions

Project:Toolchain/Compiler warnings

See also

External links