14 Warning Messages

14.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.

14.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. 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.

14.3 Enabling additional warnings

Some warning messages are disabled by default and are generated only to provide additional diagnostics. All warning messages can be enabled using the -Wall option. For example: 

% swig -Wall -python example.i

When -Wall is used, all other warning filters are disabled.

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 

#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.

14.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 "750: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="751:You are really going to regret this") blah * {
   ...
}

In this case, the warning message will be printed whenever the typemap is actually used.

14.5 Commentary

The ability to suppress warning messages is really only provided for advanced users and is not recommended in normal use. There are no plans to provide symbolic names or options that identify specific types or groups of warning messages---the numbers must be used explicitly.

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.

14.6 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.

14.7 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.
$ swig -python -Fmicrosoft example.i
example.i(4): Syntax error in input.

14.8 Warning number reference

14.8.1 Deprecated features (100-199)

14.8.2 Preprocessor (200-299)

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

14.8.4 Types and typemaps (400-499)

14.8.5 Code generation (500-599)

14.8.6 Language module specific (800-899)

14.8.7 User defined (900-999)

These numbers can be used by your own application.

14.9 History

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