On 11/09/16 14:02, Mark Wielaard wrote:
-Wshadow-local which warns if a local variable shadows another local
variable or parameter,
-Wshadow-compatible-local which warns if a local variable shadows
another local variable or parameter whose type is compatible with that
of the shadowing variable.
I honestly don't see the need for the second flag. Why not make Wshadow, or at
least Wshadow-local, work in this way by default? Warning for shadowed
variables that will nevertheless trigger errors/warnings if used wrongly seems
not very useful anyway.
+ /* If '-Wshadow-compatible-local' is specified without other
+ -Wshadow flags, we will warn only when the types of the
+ shadowing variable (i.e. new_decl) and the shadowed variable
+ (old_decl) are compatible. */
+ if (comptypes (TREE_TYPE (old_decl), TREE_TYPE (new_decl)))
+ warning_code = OPT_Wshadow_compatible_local;
+ else
+ warning_code = OPT_Wshadow_local;
+ warned = warning (warning_code,
+ "declaration of %q+D shadows a parameter",
+ new_decl);
Please don't use +D. Use warning_at with DECL_SOURCE_LOCATION(new_decl).
See: https://gcc.gnu.org/wiki/DiagnosticsGuidelines#Locations
+ /* If '-Wshadow-compatible-local' is specified without other
+ -Wshadow flags, we will warn only when the type of the
+ shadowing variable (i.e. x) can be converted to that of
+ the shadowed parameter (oldlocal). The reason why we only
+ check if x's type can be converted to oldlocal's type
+ (but not the other way around) is because when users
+ accidentally shadow a parameter, more than often they
+ would use the variable thinking (mistakenly) it's still
+ the parameter. It would be rare that users would use the
+ variable in the place that expects the parameter but
+ thinking it's a new decl. */
As said above, IMHO, this behavior should be the default of -Wshadow, or at
least, of -Wshadow-local. The current behavior only leads to people not using
-Wshadow (and us not including it in -Wall -Wextra). There is a Linus rant from
some years ago that explains vehemently why Wshadow is useless in its current form.
+@item -Wshadow-compatible-local
+@opindex Wshadow-compatible-local
+@opindex Wno-shadow-compatible-local
+Warn when a local variable shadows another local variable or parameter
+whose type is compatible with that of the shadowing variable. In C++,
+type compatibility here means the type of the shadowing variable can be
+converted to that of the shadowed variable. The creation of this flag
+(in addition to @option{-Wshadow-local}) is based on the idea that when
+a local variable shadows another one of incompatible type, it is most
+likely intentional, not a bug or typo, as shown in the following example:
-Wshadow-compatible-local seems safe enough to be enabled by -Wall (or
-Wextra). Options not enabled by either are rarely used (and, hence, rarely
tested).
Cheers,
Manuel.