19 Warning Messages

19.1 Introduction

During compilation, SWIG may generate a variety of warning messages. For example: 

example.i:16: Warning 501: Overloaded declaration ignored.  bar(double)
example.i:15: Warning 501: Previous declaration is bar(int)

Typically, warning messages indicate non-fatal problems with the input where the generated wrapper code will probably compile, but it may not work like you expect.

19.2 Warning message suppression

All warning messages have a numeric code that is shown in the warning message itself. To suppress the printing of a warning message, a number of techniques can be used. First, you can run SWIG with the -w command line option. For example: 

% swig -python -w501 example.i
% swig -python -w501,505,401 example.i

Alternatively, warnings can be suppressed by inserting a special preprocessor pragma into the input file: 

%module example
#pragma SWIG nowarn=501
#pragma SWIG nowarn=501,505,401

Finally, code-generation warnings can be disabled on a declaration by declaration basis using the %warnfilter directive. For example: 

%module example
%warnfilter(501) foo;
...
int foo(int);
int foo(double);              // Silently ignored.

The %warnfilter directive has the same semantics as other declaration modifiers like %rename, %ignore and %feature, see the %feature directive section. For example, if you wanted to suppress a warning for a method in a class hierarchy, you could do this: 

%warnfilter(501) Object::foo;
class Object {
public:
  int foo(int);
  int foo(double);      // Silently ignored
  ...
};

class Derived : public Object {
public:
  int foo(int);
  int foo(double);      // Silently ignored
  ...
};

Warnings can be suppressed for an entire class by supplying a class name. For example: 

%warnfilter(501) Object;

class Object {
public:
  ...                      // All 501 warnings ignored in class
};

There is no option to suppress all SWIG warning messages. The warning messages are there for a reason---to tell you that something may be broken in your interface. Ignore the warning messages at your own peril.

19.3 Enabling extra warnings

Some warning messages are disabled by default and are generated only to provide additional diagnostics. These warnings can be turned on using the -Wextra option. For example: 

% swig -Wextra -python example.i

Preprocessor warning 202 ("Could not evaluate expression expr.") was formally off by default and enabled by -Wextra, but since SWIG 4.1.0 this warning is on by default because suppressing it tends to hide genuine problems. If you really don't want to see it, you can suppress it with -w202 or using %warnfilter as described below. Both will work with older versions of SWIG too.

To selectively turn on extra warning messages, you can use the directives and options in the previous section--simply add a "+" to all warning numbers. For example: 

% swig -w+309,+452 example.i

or in your interface file use either 

#pragma SWIG nowarn=+309,+452

or 

%warnfilter(+309,+452) foo;

Note: selective enabling of warnings with %warnfilter overrides any global settings you might have made using -w or #pragma.

You can of course also enable all warnings and suppress a select few, for example: 

% swig -Wextra -w309,452 example.i

The warnings on the right take precedence over the warnings on the left, so in the above example -Wextra adds numerous warnings including 452, but then -w309,452 overrides this and so 452 is suppressed.

If you would like all warnings to appear, regardless of the warning filters used, then use the -Wall option. The -Wall option also turns on the extra warnings that -Wextra adds, however, it is subtely different. When -Wall is used, it also disables all other warning filters, that is, any warnings suppressed or added in %warnfilter, #pragma SWIG nowarn or the -w option.

19.4 Issuing a warning message

Warning messages can be issued from an interface file using a number of directives. The %warn directive is the most simple: 

%warn "900:This is your last warning!"

All warning messages are optionally prefixed by the warning number to use. If you are generating your own warnings, make sure you don't use numbers defined in the table at the end of this section.

The %ignorewarn directive is the same as %ignore except that it issues a warning message whenever a matching declaration is found. For example: 

%ignorewarn("362:operator= ignored") operator=;

Warning messages can be associated with typemaps using the warning attribute of a typemap declaration. For example: 

%typemap(in, warning="901:You are really going to regret this usage of $1_type $1_name") blah * {
  ...
}

In this case, the warning message will be printed whenever the typemap is actually used and the special variables will be expanded as appropriate, for example: 

example.i:23: Warning 901: You are really going to regret this usage of blah * self
example.i:24: Warning 901: You are really going to regret this usage of blah * stuff

19.5 Symbolic symbols

The swigwarn.swg file that is installed with SWIG contains symbol constants that could also be used in %warnfilter and #pragma SWIG nowarn. For example this file contains the following line: 

%define SWIGWARN_TYPE_UNDEFINED_CLASS 401 %enddef

so SWIGWARN_TYPE_UNDEFINED_CLASS could be used instead of 401, for example: 

#pragma SWIG nowarn=SWIGWARN_TYPE_UNDEFINED_CLASS

or 

%warnfilter(SWIGWARN_TYPE_UNDEFINED_CLASS) Foo;

19.6 Commentary

The ability to suppress warning messages is really only provided for advanced users and is not recommended in normal use. You are advised to modify your interface to fix the problems highlighted by the warnings wherever possible instead of suppressing warnings.

Certain types of SWIG problems are errors. These usually arise due to parsing errors (bad syntax) or semantic problems for which there is no obvious recovery. There is no mechanism for suppressing error messages.

19.7 Warnings as errors

Warnings can be handled as errors by using the -Werror command line option. This will cause SWIG to exit with a non successful exit code if a warning is encountered.

19.8 Message output format

The output format for both warnings and errors can be selected for integration with your favourite IDE/editor. Editors and IDEs can usually parse error messages and if in the appropriate format will easily take you directly to the source of the error. The standard format is used by default except on Windows where the Microsoft format is used by default. These can be overridden using command line options, for example: 

$ swig -python -Fstandard example.i
example.i:4: Syntax error in input(1).
$ swig -python -Fmicrosoft example.i
example.i(4) : Syntax error in input(1).

19.9 Warning number reference

19.9.1 Deprecated features (100-199)

None currently.

19.9.2 Preprocessor (200-299)

19.9.3 C/C++ Parser (300-399)

19.9.4 Types and typemaps (400-499)

19.9.5 Code generation (500-559)

19.9.6 Doxygen comments (560-599)

19.9.7 Language module specific (700-899)

19.9.8 User defined (900-999)

These numbers can be used by your own application.

19.10 History

The ability to control warning messages was first added to SWIG-1.3.12.