Documentation section numbering update

[skip ci]
author: William S Fulton <wsf@fultondesigns.co.uk> 2019-02-11 19:02:03 +0000
committer: William S Fulton <wsf@fultondesigns.co.uk> 2019-02-11 19:02:03 +0000
commit: d16d145787c45954c533c2208b9a0ae721df9002 (patch)
tree: 79eaa80d068fdb7859552b6c72488e064d67acb4 /Doc
parent: a5b301ba83810f55da9947765dd249a78ec99855 (diff)
download: swig-d16d145787c45954c533c2208b9a0ae721df9002.tar.gz
24 files changed, 688 insertions, 672 deletions
diff --git a/Doc/Manual/Android.html b/Doc/Manual/Android.html
index cc11ec26e..894724188 100644
--- a/Doc/Manual/Android.html
+++ b/Doc/Manual/Android.html
@@ -6,7 +6,7 @@
 <meta http-equiv="content-type" content="text/html; charset=UTF-8">
 </head>
 <body bgcolor="#FFFFFF">
-<H1><a name="Android">20 SWIG and Android</a></H1>
+<H1><a name="Android">21 SWIG and Android</a></H1>
 <!-- INDEX -->
 <div class="sectiontoc">
 <ul>
@@ -31,7 +31,7 @@ This chapter describes SWIG's support of Android.
 
 
 
-<H2><a name="Android_overview">20.1 Overview</a></H2>
+<H2><a name="Android_overview">21.1 Overview</a></H2>
 
 
 <p>
@@ -41,10 +41,10 @@ Everything in the <a href="Java.html#Java">Java chapter</a> applies to generatin
 This chapter contains a few Android specific notes and examples.
 </p>
 
-<H2><a name="Android_examples">20.2 Android examples</a></H2>
+<H2><a name="Android_examples">21.2 Android examples</a></H2>
 
 
-<H3><a name="Android_examples_intro">20.2.1 Examples introduction</a></H3>
+<H3><a name="Android_examples_intro">21.2.1 Examples introduction</a></H3>
 
 
 <p>
@@ -77,7 +77,7 @@ $ android list targets
 The following examples are shipped with SWIG under the Examples/android directory and include a Makefile to build and install each example.
 </p>
 
-<H3><a name="Android_example_simple">20.2.2 Simple C example</a></H3>
+<H3><a name="Android_example_simple">21.2.2 Simple C example</a></H3>
 
 
 <p>
@@ -399,7 +399,7 @@ Run the app again and this time you will see the output pictured below, showing
 <center><img src="android-simple.png" alt="Android screenshot of SwigSimple example"></center>
 
 
-<H3><a name="Android_example_class">20.2.3 C++ class example</a></H3>
+<H3><a name="Android_example_class">21.2.3 C++ class example</a></H3>
 
 
 <p>
@@ -747,7 +747,7 @@ Run the app to see the result of calling the C++ code from Java:
 
 <center><img src="android-class.png" alt="Android screenshot of SwigClass example"></center>
 
-<H3><a name="Android_examples_other">20.2.4 Other examples</a></H3>
+<H3><a name="Android_examples_other">21.2.4 Other examples</a></H3>
 
 
 <p>
@@ -759,7 +759,7 @@ Note that the 'extend' example is demonstrates the directors feature.
 Normally C++ exception handling and the STL is not available by default in the version of g++ shipped with Android, but this example turns these features on as described in the next section.
 </p>
 
-<H2><a name="Android_stl">20.3 C++ STL</a></H2>
+<H2><a name="Android_stl">21.3 C++ STL</a></H2>
 
 
 <p>
diff --git a/Doc/Manual/Arguments.html b/Doc/Manual/Arguments.html
index fbdce7f27..2828bf4df 100644
--- a/Doc/Manual/Arguments.html
+++ b/Doc/Manual/Arguments.html
@@ -7,7 +7,7 @@
 </head>
 
 <body bgcolor="#ffffff">
-<H1><a name="Arguments">11 Argument Handling</a></H1>
+<H1><a name="Arguments">12 Argument Handling</a></H1>
 <!-- INDEX -->
 <div class="sectiontoc">
 <ul>
@@ -43,7 +43,7 @@ return multiple values through the arguments of a function.  This chapter
 describes some of the techniques for doing this.
 </p>
 
-<H2><a name="Arguments_nn2">11.1 The typemaps.i library</a></H2>
+<H2><a name="Arguments_nn2">12.1 The typemaps.i library</a></H2>
 
 
 <p>
@@ -51,7 +51,7 @@ This section describes the <tt>typemaps.i</tt> library file--commonly used to
 change certain properties of argument conversion.
 </p>
 
-<H3><a name="Arguments_nn3">11.1.1 Introduction</a></H3>
+<H3><a name="Arguments_nn3">12.1.1 Introduction</a></H3>
 
 
 <p>
@@ -195,7 +195,7 @@ else.   To clear a typemap, the <tt>%clear</tt> directive should be used.  For e
 </pre>
 </div>
 
-<H3><a name="Arguments_nn4">11.1.2 Input parameters</a></H3>
+<H3><a name="Arguments_nn4">12.1.2 Input parameters</a></H3>
 
 
 <p>
@@ -248,7 +248,7 @@ When the function is used in the scripting language interpreter, it will work li
 result = add(3, 4)
 </pre></div>
 
-<H3><a name="Arguments_nn5">11.1.3 Output parameters</a></H3>
+<H3><a name="Arguments_nn5">12.1.3 Output parameters</a></H3>
 
 
 <p>
@@ -315,7 +315,7 @@ iresult, dresult = foo(3.5, 2)
 </pre>
 </div>
 
-<H3><a name="Arguments_nn6">11.1.4 Input/Output parameters</a></H3>
+<H3><a name="Arguments_nn6">12.1.4 Input/Output parameters</a></H3>
 
 
 <p>
@@ -380,7 +380,7 @@ rather than directly overwriting the value of the original input object.
 SWIG.  Backwards compatibility is preserved, but deprecated.
 </p>
 
-<H3><a name="Arguments_nn7">11.1.5 Using different names</a></H3>
+<H3><a name="Arguments_nn7">12.1.5 Using different names</a></H3>
 
 
 <p>
@@ -414,7 +414,7 @@ Typemap declarations are lexically scoped so a typemap takes effect from the poi
 file or a matching <tt>%clear</tt> declaration.
 </p>
 
-<H2><a name="Arguments_nn8">11.2 Applying constraints to input values</a></H2>
+<H2><a name="Arguments_nn8">12.2 Applying constraints to input values</a></H2>
 
 
 <p>
@@ -424,7 +424,7 @@ insure that a value is positive, or that a pointer is non-NULL. This
 can be accomplished including the <tt>constraints.i</tt> library file.
 </p>
 
-<H3><a name="Arguments_nn9">11.2.1 Simple constraint example</a></H3>
+<H3><a name="Arguments_nn9">12.2.1 Simple constraint example</a></H3>
 
 
 <p>
@@ -450,7 +450,7 @@ the arguments violate the constraint condition, a scripting language
 exception will be raised. As a result, it is possible to catch bad
 values, prevent mysterious program crashes and so on.</p>
 
-<H3><a name="Arguments_nn10">11.2.2 Constraint methods</a></H3>
+<H3><a name="Arguments_nn10">12.2.2 Constraint methods</a></H3>
 
 
 <p>
@@ -466,7 +466,7 @@ NONNULL                      Non-NULL pointer (pointers only).
 
 </pre></div>
 
-<H3><a name="Arguments_nn11">11.2.3 Applying constraints to new datatypes</a></H3>
+<H3><a name="Arguments_nn11">12.2.3 Applying constraints to new datatypes</a></H3>
 
 
 <p>
diff --git a/Doc/Manual/CCache.html b/Doc/Manual/CCache.html
index 6923b2e95..3a7db5c7b 100644
--- a/Doc/Manual/CCache.html
+++ b/Doc/Manual/CCache.html
@@ -7,7 +7,7 @@
 </head>
 
 <body bgcolor="#ffffff">
-<H1><a name="CCache">19 Using SWIG with ccache - ccache-swig(1) manpage</a></H1>
+<H1><a name="CCache">20 Using SWIG with ccache - ccache-swig(1) manpage</a></H1>
 <!-- INDEX -->
 <div class="sectiontoc">
 <ul>
@@ -35,7 +35,7 @@
 
 
 <p>
-<H2><a name="CCache_nn2">19.1 NAME</a></H2>
+<H2><a name="CCache_nn2">20.1 NAME</a></H2>
 
 
 <p>
@@ -43,7 +43,7 @@
 ccache-swig - a fast compiler cache
 
 <p>
-<H2><a name="CCache_nn3">19.2 SYNOPSIS</a></H2>
+<H2><a name="CCache_nn3">20.2 SYNOPSIS</a></H2>
 
 
 <p>
@@ -53,7 +53,7 @@ ccache-swig &lt;compiler&gt; [COMPILER OPTIONS]
 <p>
 &lt;compiler&gt; [COMPILER OPTIONS]
 <p>
-<H2><a name="CCache_nn4">19.3 DESCRIPTION</a></H2>
+<H2><a name="CCache_nn4">20.3 DESCRIPTION</a></H2>
 
 
 <p>
@@ -62,7 +62,7 @@ by caching previous compiles and detecting when the same compile is
 being done again. ccache-swig is ccache plus support for SWIG. ccache
 and ccache-swig are used interchangeably in this document.
 <p>
-<H2><a name="CCache_nn5">19.4 OPTIONS SUMMARY</a></H2>
+<H2><a name="CCache_nn5">20.4 OPTIONS SUMMARY</a></H2>
 
 
 <p>
@@ -82,7 +82,7 @@ Here is a summary of the options to ccache-swig.
 </pre>
 
 <p>
-<H2><a name="CCache_nn6">19.5 OPTIONS</a></H2>
+<H2><a name="CCache_nn6">20.5 OPTIONS</a></H2>
 
 
 <p>
@@ -124,7 +124,7 @@ rounded down to the nearest multiple of 16 kilobytes.
 <p>
 </dl>
 <p>
-<H2><a name="CCache_nn7">19.6 INSTALLATION</a></H2>
+<H2><a name="CCache_nn7">20.6 INSTALLATION</a></H2>
 
 
 <p>
@@ -156,7 +156,7 @@ This will work as long as /usr/local/bin comes before the path to gcc
 Note! Do not use a hard link, use a symbolic link. A hardlink will
 cause "interesting" problems.
 <p>
-<H2><a name="CCache_nn8">19.7 EXTRA OPTIONS</a></H2>
+<H2><a name="CCache_nn8">20.7 EXTRA OPTIONS</a></H2>
 
 
 <p>
@@ -176,7 +176,7 @@ file). By using --ccache-skip you can force an option to not be
 treated as an input file name and instead be passed along to the
 compiler as a command line option.
 <p>
-<H2><a name="CCache_nn9">19.8 ENVIRONMENT VARIABLES</a></H2>
+<H2><a name="CCache_nn9">20.8 ENVIRONMENT VARIABLES</a></H2>
 
 
 <p>
@@ -315,7 +315,7 @@ the use of '#pragma SWIG'.
 <p>
 </dl>
 <p>
-<H2><a name="CCache_nn10">19.9 CACHE SIZE MANAGEMENT</a></H2>
+<H2><a name="CCache_nn10">20.9 CACHE SIZE MANAGEMENT</a></H2>
 
 
 <p>
@@ -328,7 +328,7 @@ When these limits are reached ccache will reduce the cache to 20%
 below the numbers you specified in order to avoid doing the cache
 clean operation too often.
 <p>
-<H2><a name="CCache_nn11">19.10 CACHE COMPRESSION</a></H2>
+<H2><a name="CCache_nn11">20.10 CACHE COMPRESSION</a></H2>
 
 
 <p>
@@ -339,7 +339,7 @@ performance slowdown, it significantly increases the number of files
 that fit in the cache. You can turn off compression setting the
 CCACHE_NOCOMPRESS environment variable.
 <p>
-<H2><a name="CCache_nn12">19.11 HOW IT WORKS</a></H2>
+<H2><a name="CCache_nn12">20.11 HOW IT WORKS</a></H2>
 
 
 <p>
@@ -364,7 +364,7 @@ compiler output that you would get without the cache. If you ever
 discover a case where ccache changes the output of your compiler then
 please let me know.
 <p>
-<H2><a name="CCache_nn13">19.12 USING CCACHE WITH DISTCC</a></H2>
+<H2><a name="CCache_nn13">20.12 USING CCACHE WITH DISTCC</a></H2>
 
 
 <p>
@@ -378,7 +378,7 @@ option. You just need to set the environment variable CCACHE_PREFIX to
 'distcc' and ccache will prefix the command line used with the
 compiler with the command 'distcc'.
 <p>
-<H2><a name="CCache_nn14">19.13 SHARING A CACHE</a></H2>
+<H2><a name="CCache_nn14">20.13 SHARING A CACHE</a></H2>
 
 
 <p>
@@ -407,7 +407,7 @@ following conditions need to be met:
   versions of ccache that do not support compression.
 </ul>
 <p>
-<H2><a name="CCache_nn15">19.14 HISTORY</a></H2>
+<H2><a name="CCache_nn15">20.14 HISTORY</a></H2>
 
 
 <p>
@@ -423,7 +423,7 @@ I wrote ccache because I wanted to get a bit more speed out of a
 compiler cache and I wanted to remove some of the limitations of the
 shell-script version.
 <p>
-<H2><a name="CCache_nn16">19.15 DIFFERENCES FROM COMPILERCACHE</a></H2>
+<H2><a name="CCache_nn16">20.15 DIFFERENCES FROM COMPILERCACHE</a></H2>
 
 
 <p>
@@ -441,7 +441,7 @@ are:
 <li> ccache avoids a double call to cpp on a cache miss
 </ul>
 <p>
-<H2><a name="CCache_nn17">19.16 CREDITS</a></H2>
+<H2><a name="CCache_nn17">20.16 CREDITS</a></H2>
 
 
 <p>
@@ -453,7 +453,7 @@ Thanks to the following people for their contributions to ccache
  <li> Paul Russell for many suggestions and the debian packaging
 </ul>
 <p>
-<H2><a name="CCache_nn18">19.17 AUTHOR</a></H2>
+<H2><a name="CCache_nn18">20.17 AUTHOR</a></H2>
 
 
 <p>
diff --git a/Doc/Manual/CPlusPlus14.html b/Doc/Manual/CPlusPlus14.html
index 32798f302..b162c7818 100644
--- a/Doc/Manual/CPlusPlus14.html
+++ b/Doc/Manual/CPlusPlus14.html
@@ -14,6 +14,7 @@
 <li><a href="#CPlusPlus14_introduction">Introduction</a>
 <li><a href="#CPlusPlus14_core_language_changes">Core language changes</a>
 <ul>
+<li><a href="#CPlusPlus14_binary_literals">Binary integer literals</a>
 </ul>
 <li><a href="#CPlusPlus14_standard_library_changes">Standard library changes</a>
 </ul>
@@ -38,7 +39,7 @@ C++14 support.
 <H2><a name="CPlusPlus14_core_language_changes">8.2 Core language changes</a></H2>
 
 
-<H3><a name="CPlusPlus14_binary_literals">Binary integer literals</a></H3>
+<H3><a name="CPlusPlus14_binary_literals">8.2.1 Binary integer literals</a></H3>
 
 
 <p>
diff --git a/Doc/Manual/CPlusPlus17.html b/Doc/Manual/CPlusPlus17.html
index ea42bd6a2..ae3ca5c77 100644
--- a/Doc/Manual/CPlusPlus17.html
+++ b/Doc/Manual/CPlusPlus17.html
@@ -7,7 +7,7 @@
 </head>
 
 <body bgcolor="#ffffff">
-<H1><a name="CPlusPlus17">8 SWIG and C++17</a></H1>
+<H1><a name="CPlusPlus17">9 SWIG and C++17</a></H1>
 <!-- INDEX -->
 <div class="sectiontoc">
 <ul>
@@ -24,7 +24,7 @@
 
 
 
-<H2><a name="CPlusPlus17_introduction">8.1 Introduction</a></H2>
+<H2><a name="CPlusPlus17_introduction">9.1 Introduction</a></H2>
 
 
 <p>This chapter gives you a brief overview about the SWIG
@@ -37,10 +37,10 @@ C++17 support.
 <b>Compatibility note:</b> SWIG-4.0.0 is the first version to support any C++17 features.
 </p>
 
-<H2><a name="CPlusPlus17_core_language_changes">8.2 Core language changes</a></H2>
+<H2><a name="CPlusPlus17_core_language_changes">9.2 Core language changes</a></H2>
 
 
-<H3><a name="CPlusPlus17_nested_namespaces">8.2.1 Nested namespace definitions</a></H3>
+<H3><a name="CPlusPlus17_nested_namespaces">9.2.1 Nested namespace definitions</a></H3>
 
 
 <p>
@@ -72,7 +72,7 @@ namespace A {
 </pre>
 </div>
 
-<H3><a name="CPlusPlus17_u8_char_literals">8.2.2 UTF-8 character literals</a></H3>
+<H3><a name="CPlusPlus17_u8_char_literals">9.2.2 UTF-8 character literals</a></H3>
 
 
 <p>
@@ -87,7 +87,7 @@ char a = u8'a';
 </pre>
 </div>
 
-<H2><a name="CPlusPlus17_standard_library_changes">8.3 Standard library changes</a></H2>
+<H2><a name="CPlusPlus17_standard_library_changes">9.3 Standard library changes</a></H2>
 
 
 </body>
diff --git a/Doc/Manual/CSharp.html b/Doc/Manual/CSharp.html
index 7a1326b54..a4e0be799 100644
--- a/Doc/Manual/CSharp.html
+++ b/Doc/Manual/CSharp.html
@@ -6,7 +6,7 @@
 <meta http-equiv="content-type" content="text/html; charset=UTF-8">
 </head>
 <body bgcolor="#FFFFFF">
-<H1><a name="CSharp">21 SWIG and C#</a></H1>
+<H1><a name="CSharp">22 SWIG and C#</a></H1>
 <!-- INDEX -->
 <div class="sectiontoc">
 <ul>
@@ -55,7 +55,7 @@
 
 
 
-<H2><a name="CSharp_introduction">21.1 Introduction</a></H2>
+<H2><a name="CSharp_introduction">22.1 Introduction</a></H2>
 
 
 <p>
@@ -75,7 +75,7 @@ The <a href="http://msdn.microsoft.com">Microsoft Developer Network (MSDN)</a> h
 Monodoc, available from the Mono project, has a very useful section titled <a href="http://www.mono-project.com/docs/advanced/pinvoke/">Interop with native libraries</a>.
 </p>
 
-<H3><a name="CSharp_introduction_swig2_compatibility">21.1.1 SWIG 2 Compatibility</a></H3>
+<H3><a name="CSharp_introduction_swig2_compatibility">22.1.1 SWIG 2 Compatibility</a></H3>
 
 
 <p>
@@ -83,7 +83,7 @@ In order to minimize name collisions between names generated based on input to S
 </p>
 
 
-<H3><a name="CSharp_commandline">21.1.2 Additional command line options</a></H3>
+<H3><a name="CSharp_commandline">22.1.2 Additional command line options</a></H3>
 
 
 <p>
@@ -135,7 +135,7 @@ Note that the file extension (.cs) will not be automatically added and needs to
 Due to possible compiler limits it is not advisable to use <tt>-outfile</tt> for large projects.
 </p>
 
-<H2><a name="CSharp_differences_java">21.2 Differences to the Java module</a></H2>
+<H2><a name="CSharp_differences_java">22.2 Differences to the Java module</a></H2>
 
 
 <p>
@@ -556,7 +556,7 @@ Windows users can also get the examples working using a
 <a href="http://www.cygwin.com">Cygwin</a> or <a href="http://www.mingw.org">MinGW</a> environment for automatic configuration of the example makefiles.
 Any one of the C# compilers (Mono or Microsoft) can be detected from within a Cygwin or Mingw environment if installed in your path. 
 
-<H2><a name="CSharp_void_pointers">21.3 Void pointers</a></H2>
+<H2><a name="CSharp_void_pointers">22.3 Void pointers</a></H2>
 
 
 <p>
@@ -574,7 +574,7 @@ void * f(void *v);
 </pre>
 </div>
 
-<H2><a name="CSharp_arrays">21.4 C# Arrays</a></H2>
+<H2><a name="CSharp_arrays">22.4 C# Arrays</a></H2>
 
 
 <p>
@@ -586,7 +586,7 @@ with one of the following three approaches; namely the SWIG C arrays library, P/
 pinned arrays.
 </p>
 
-<H3><a name="CSharp_arrays_swig_library">21.4.1 The SWIG C arrays library</a></H3>
+<H3><a name="CSharp_arrays_swig_library">22.4.1 The SWIG C arrays library</a></H3>
 
 
 <p>
@@ -623,7 +623,7 @@ example.print_array(c.cast());          // Pass to C
 </div>
 
 
-<H3><a name="CSharp_arrays_pinvoke_default_array_marshalling">21.4.2 Managed arrays using P/Invoke default array marshalling</a></H3>
+<H3><a name="CSharp_arrays_pinvoke_default_array_marshalling">22.4.2 Managed arrays using P/Invoke default array marshalling</a></H3>
 
 
 <p>
@@ -750,7 +750,7 @@ and intermediary class method
 </div>
 
 
-<H3><a name="CSharp_arrays_pinning">21.4.3 Managed arrays using pinning</a></H3>
+<H3><a name="CSharp_arrays_pinning">22.4.3 Managed arrays using pinning</a></H3>
 
 
 <p>
@@ -845,7 +845,7 @@ public static extern void myArrayCopy(global::System.IntPtr jarg1, global::Syste
 
 
 
-<H2><a name="CSharp_exceptions">21.5 C# Exceptions</a></H2>
+<H2><a name="CSharp_exceptions">22.5 C# Exceptions</a></H2>
 
 
 <p>
@@ -942,7 +942,7 @@ set so should only be used when a C# exception is not created.
 </p>
 
 
-<H3><a name="CSharp_exception_example_check_typemap">21.5.1 C# exception example using "check" typemap</a></H3>
+<H3><a name="CSharp_exception_example_check_typemap">22.5.1 C# exception example using "check" typemap</a></H3>
 
 
 <p>
@@ -1124,7 +1124,7 @@ method and C# code does not handle pending exceptions via the canthrow attribute
 Actually it will issue this warning for any function beginning with <tt>SWIG_CSharpSetPendingException</tt>.
 </P>
 
-<H3><a name="CSharp_exception_example_percent_exception">21.5.2 C# exception example using %exception</a></H3>
+<H3><a name="CSharp_exception_example_percent_exception">22.5.2 C# exception example using %exception</a></H3>
 
 
 <p>
@@ -1189,7 +1189,7 @@ The managed code generated does check for the pending exception as mentioned ear
 </pre>
 </div>
 
-<H3><a name="CSharp_exception_example_exception_specifications">21.5.3 C# exception example using exception specifications</a></H3>
+<H3><a name="CSharp_exception_example_exception_specifications">22.5.3 C# exception example using exception specifications</a></H3>
 
 
 <p>
@@ -1245,7 +1245,7 @@ SWIGEXPORT void SWIGSTDCALL CSharp_evensonly(int jarg1) {
 Multiple catch handlers are generated should there be more than one exception specifications declared.
 </p>
 
-<H3><a name="CSharp_custom_application_exception">21.5.4 Custom C# ApplicationException example</a></H3>
+<H3><a name="CSharp_custom_application_exception">22.5.4 Custom C# ApplicationException example</a></H3>
 
 
 <p>
@@ -1379,7 +1379,7 @@ try {
 </pre>
 </div>
 
-<H2><a name="CSharp_directors">21.6 C# Directors</a></H2>
+<H2><a name="CSharp_directors">22.6 C# Directors</a></H2>
 
 
 <p>
@@ -1392,7 +1392,7 @@ The following sections provide information on the C# director implementation and
 However, the <a href="Java.html#Java_directors">Java directors</a> section should also be read in order to gain more insight into directors.
 </p>
 
-<H3><a name="CSharp_directors_example">21.6.1 Directors example</a></H3>
+<H3><a name="CSharp_directors_example">22.6.1 Directors example</a></H3>
 
 
 <p>
@@ -1513,7 +1513,7 @@ CSharpDerived - UIntMethod(123)
 </pre>
 </div>
 
-<H3><a name="CSharp_directors_implementation">21.6.2 Directors implementation</a></H3>
+<H3><a name="CSharp_directors_implementation">22.6.2 Directors implementation</a></H3>
 
 
 <p>
@@ -1721,7 +1721,7 @@ before SWIG parses the Base class will change all the delegates to <tt>internal<
 </pre>
 </div>
 
-<H3><a name="CSharp_director_caveats">21.6.3 Director caveats</a></H3>
+<H3><a name="CSharp_director_caveats">22.6.3 Director caveats</a></H3>
 
 
 <p>
@@ -1769,7 +1769,7 @@ However, a call from C# to <tt>CSharpDefaults.DefaultMethod()</tt> will of cours
 should pass the call on to <tt>CSharpDefaults.DefaultMethod(int)</tt>using the C++ default value, as shown above.
 </p>
 
-<H2><a name="CSharp_multiple_modules">21.7 Multiple modules</a></H2>
+<H2><a name="CSharp_multiple_modules">22.7 Multiple modules</a></H2>
 
 
 <p>
@@ -1804,7 +1804,7 @@ the <tt>[System.ComponentModel.EditorBrowsable(System.ComponentModel.EditorBrows
 if you don't want users to easily stumble upon these so called 'internal workings' of the wrappers.
 </p>
 
-<H2><a name="CSharp_typemap_examples">21.8 C# Typemap examples</a></H2>
+<H2><a name="CSharp_typemap_examples">22.8 C# Typemap examples</a></H2>
 
 
 This section includes a few examples of typemaps.  For more examples, you
@@ -1812,7 +1812,7 @@ might look at the files "<tt>csharp.swg</tt>" and "<tt>typemaps.i</tt>" in
 the SWIG library.
 
 
-<H3><a name="CSharp_memory_management_member_variables">21.8.1 Memory management when returning references to member variables</a></H3>
+<H3><a name="CSharp_memory_management_member_variables">22.8.1 Memory management when returning references to member variables</a></H3>
 
 
 <p>
@@ -1936,7 +1936,7 @@ public class Bike : global::System.IDisposable {
 Note the <tt>addReference</tt> call.
 </p>
 
-<H3><a name="CSharp_memory_management_objects">21.8.2 Memory management for objects passed to the C++ layer</a></H3>
+<H3><a name="CSharp_memory_management_objects">22.8.2 Memory management for objects passed to the C++ layer</a></H3>
 
 
 <p>
@@ -2068,7 +2068,7 @@ as mentioned earlier, <tt>setElement</tt> is actually:
 </div>
 
 
-<H3><a name="CSharp_date_marshalling">21.8.3 Date marshalling using the csin typemap and associated attributes</a></H3>
+<H3><a name="CSharp_date_marshalling">22.8.3 Date marshalling using the csin typemap and associated attributes</a></H3>
 
 
 <p>
@@ -2354,7 +2354,7 @@ public class example {
 </pre>
 </div>
 
-<H3><a name="CSharp_date_properties">21.8.4 A date example demonstrating marshalling of C# properties</a></H3>
+<H3><a name="CSharp_date_properties">22.8.4 A date example demonstrating marshalling of C# properties</a></H3>
 
 
 <p>
@@ -2454,7 +2454,7 @@ Some points to note:
   <li>The 'csin' typemap has 'pre', 'post' and 'cshin' attributes, and these are all ignored in the property set. The code in these attributes must instead be replicated within the 'csvarin' typemap. The line creating the <tt>temp$csinput</tt> variable is such an example; it is identical to what is in the 'pre' attribute.
 </ul>
 
-<H3><a name="CSharp_date_pre_post_directors">21.8.5 Date example demonstrating the 'pre' and 'post' typemap attributes for directors</a></H3>
+<H3><a name="CSharp_date_pre_post_directors">22.8.5 Date example demonstrating the 'pre' and 'post' typemap attributes for directors</a></H3>
 
 
 <p>
@@ -2516,7 +2516,7 @@ Pay special attention to the memory management issues, using these attributes.
 </p>
 
 
-<H3><a name="CSharp_partial_classes">21.8.6 Turning proxy classes into partial classes</a></H3>
+<H3><a name="CSharp_partial_classes">22.8.6 Turning proxy classes into partial classes</a></H3>
 
 
 <p>
@@ -2616,7 +2616,7 @@ demonstrating that the class contains methods calling both unmanaged code - <tt>
 The following example is an alternative approach to adding managed code to the generated proxy class.
 </p>
 
-<H3><a name="CSharp_sealed_proxy_class">21.8.7 Turning proxy classes into sealed classes</a></H3>
+<H3><a name="CSharp_sealed_proxy_class">22.8.7 Turning proxy classes into sealed classes</a></H3>
 
 
 <p>
@@ -2706,7 +2706,7 @@ Either suppress the warning or modify the generated code by copying and tweaking
 'csbody' typemap code in csharp.swg by modifying swigCMemOwn to not be protected.
 </p>
 
-<H3><a name="CSharp_extending_proxy_class">21.8.8 Extending proxy classes with additional C# code</a></H3>
+<H3><a name="CSharp_extending_proxy_class">22.8.8 Extending proxy classes with additional C# code</a></H3>
 
 
 <p>
@@ -2745,7 +2745,7 @@ public class ExtendMe : global::System.IDisposable {
 </pre>
 </div>
 
-<H3><a name="CSharp_enum_underlying_type">21.8.9 Underlying type for enums</a></H3>
+<H3><a name="CSharp_enum_underlying_type">22.8.9 Underlying type for enums</a></H3>
 
 
 <P>
diff --git a/Doc/Manual/Contents.html b/Doc/Manual/Contents.html
index 5218cc0d9..fbfc7d751 100644
--- a/Doc/Manual/Contents.html
+++ b/Doc/Manual/Contents.html
@@ -340,7 +340,22 @@
 </div>
 <!-- INDEX -->
 
-<h3><a href="CPlusPlus17.html#CPlusPlus17">8 SWIG and C++17</a></h3>
+<h3><a href="CPlusPlus14.html#CPlusPlus14">8 SWIG and C++14</a></h3>
+
+<!-- INDEX -->
+<div class="sectiontoc">
+<ul>
+<li><a href="CPlusPlus14.html#CPlusPlus14_introduction">Introduction</a>
+<li><a href="CPlusPlus14.html#CPlusPlus14_core_language_changes">Core language changes</a>
+<ul>
+<li><a href="CPlusPlus14.html#CPlusPlus14_binary_literals">Binary integer literals</a>
+</ul>
+<li><a href="CPlusPlus14.html#CPlusPlus14_standard_library_changes">Standard library changes</a>
+</ul>
+</div>
+<!-- INDEX -->
+
+<h3><a href="CPlusPlus17.html#CPlusPlus17">9 SWIG and C++17</a></h3>
 
 <!-- INDEX -->
 <div class="sectiontoc">
@@ -356,7 +371,7 @@
 </div>
 <!-- INDEX -->
 
-<h3><a href="Preprocessor.html#Preprocessor">9 Preprocessing</a></h3>
+<h3><a href="Preprocessor.html#Preprocessor">10 Preprocessing</a></h3>
 
 <!-- INDEX -->
 <div class="sectiontoc">
@@ -379,7 +394,7 @@
 </div>
 <!-- INDEX -->
 
-<h3><a href="Library.html#Library">10 SWIG library</a></h3>
+<h3><a href="Library.html#Library">11 SWIG library</a></h3>
 
 <!-- INDEX -->
 <div class="sectiontoc">
@@ -422,7 +437,7 @@
 </div>
 <!-- INDEX -->
 
-<h3><a href="Arguments.html#Arguments">11 Argument Handling</a></h3>
+<h3><a href="Arguments.html#Arguments">12 Argument Handling</a></h3>
 
 <!-- INDEX -->
 <div class="sectiontoc">
@@ -445,7 +460,7 @@
 </div>
 <!-- INDEX -->
 
-<h3><a href="Typemaps.html#Typemaps">12 Typemaps</a></h3>
+<h3><a href="Typemaps.html#Typemaps">13 Typemaps</a></h3>
 
 <!-- INDEX -->
 <div class="sectiontoc">
@@ -539,7 +554,7 @@
 </div>
 <!-- INDEX -->
 
-<h3><a href="Customization.html#Customization">13 Customization Features</a></h3>
+<h3><a href="Customization.html#Customization">14 Customization Features</a></h3>
 
 <!-- INDEX -->
 <div class="sectiontoc">
@@ -567,7 +582,7 @@
 </div>
 <!-- INDEX -->
 
-<h3><a href="Contract.html#Contract">14 Contracts</a></h3>
+<h3><a href="Contract.html#Contract">15 Contracts</a></h3>
 
 <!-- INDEX -->
 <div class="sectiontoc">
@@ -580,7 +595,7 @@
 </div>
 <!-- INDEX -->
 
-<h3><a href="Varargs.html#Varargs">15 Variable Length Arguments</a></h3>
+<h3><a href="Varargs.html#Varargs">16 Variable Length Arguments</a></h3>
 
 <!-- INDEX -->
 <div class="sectiontoc">
@@ -598,7 +613,7 @@
 </div>
 <!-- INDEX -->
 
-<h3><a href="Doxygen.html#Doxygen">16 SWIG and Doxygen Translation</a></h3>
+<h3><a href="Doxygen.html#Doxygen">17 SWIG and Doxygen Translation</a></h3>
 
 <!-- INDEX -->
 <div class="sectiontoc">
@@ -642,7 +657,7 @@
 </div>
 <!-- INDEX -->
 
-<h3><a href="Warnings.html#Warnings">17 Warning Messages</a></h3>
+<h3><a href="Warnings.html#Warnings">18 Warning Messages</a></h3>
 
 <!-- INDEX -->
 <div class="sectiontoc">
@@ -671,7 +686,7 @@
 </div>
 <!-- INDEX -->
 
-<h3><a href="Modules.html#Modules">18 Working with Modules</a></h3>
+<h3><a href="Modules.html#Modules">19 Working with Modules</a></h3>
 
 <!-- INDEX -->
 <div class="sectiontoc">
@@ -687,7 +702,7 @@
 </div>
 <!-- INDEX -->
 
-<h3><a href="CCache.html#CCache">19 Using SWIG with ccache - ccache-swig(1) manpage</a></h3>
+<h3><a href="CCache.html#CCache">20 Using SWIG with ccache - ccache-swig(1) manpage</a></h3>
 
 <!-- INDEX -->
 <div class="sectiontoc">
@@ -713,7 +728,7 @@
 </div>
 <!-- INDEX -->
 
-<h3><a href="Android.html#Android">20 SWIG and Android</a></h3>
+<h3><a href="Android.html#Android">21 SWIG and Android</a></h3>
 
 <!-- INDEX -->
 <div class="sectiontoc">
@@ -731,7 +746,7 @@
 </div>
 <!-- INDEX -->
 
-<h3><a href="CSharp.html#CSharp">21 SWIG and C#</a></h3>
+<h3><a href="CSharp.html#CSharp">22 SWIG and C#</a></h3>
 
 <!-- INDEX -->
 <div class="sectiontoc">
@@ -779,7 +794,7 @@
 </div>
 <!-- INDEX -->
 
-<h3><a href="D.html#D">22 SWIG and D</a></h3>
+<h3><a href="D.html#D">23 SWIG and D</a></h3>
 
 <!-- INDEX -->
 <div class="sectiontoc">
@@ -813,7 +828,7 @@
 </div>
 <!-- INDEX -->
 
-<h3><a href="Go.html#Go">23 SWIG and Go</a></h3>
+<h3><a href="Go.html#Go">24 SWIG and Go</a></h3>
 
 <!-- INDEX -->
 <div class="sectiontoc">
@@ -857,7 +872,7 @@
 </div>
 <!-- INDEX -->
 
-<h3><a href="Guile.html#Guile">24 SWIG and Guile</a></h3>
+<h3><a href="Guile.html#Guile">25 SWIG and Guile</a></h3>
 
 <!-- INDEX -->
 <div class="sectiontoc">
@@ -893,7 +908,7 @@
 </div>
 <!-- INDEX -->
 
-<h3><a href="Java.html#Java">25 SWIG and Java</a></h3>
+<h3><a href="Java.html#Java">26 SWIG and Java</a></h3>
 
 <!-- INDEX -->
 <div class="sectiontoc">
@@ -1047,7 +1062,7 @@
 </div>
 <!-- INDEX -->
 
-<h3><a href="Javascript.html#Javascript">26 SWIG and Javascript</a></h3>
+<h3><a href="Javascript.html#Javascript">27 SWIG and Javascript</a></h3>
 
 <!-- INDEX -->
 <div class="sectiontoc">
@@ -1089,7 +1104,7 @@
 </div>
 <!-- INDEX -->
 
-<h3><a href="Lua.html#Lua">27 SWIG and Lua</a></h3>
+<h3><a href="Lua.html#Lua">28 SWIG and Lua</a></h3>
 
 <!-- INDEX -->
 <div class="sectiontoc">
@@ -1157,61 +1172,6 @@
 </div>
 <!-- INDEX -->
 
-<h3><a href="Ocaml.html#Ocaml">28 SWIG and Ocaml</a></h3>
-
-<!-- INDEX -->
-<div class="sectiontoc">
-<ul>
-<li><a href="Ocaml.html#Ocaml_nn2">Preliminaries</a>
-<ul>
-<li><a href="Ocaml.html#Ocaml_nn3">Running SWIG</a>
-<li><a href="Ocaml.html#Ocaml_nn4">Compiling the code</a>
-<li><a href="Ocaml.html#Ocaml_nn5">The camlp4 module</a>
-<li><a href="Ocaml.html#Ocaml_nn6">Using your module</a>
-<li><a href="Ocaml.html#Ocaml_nn7">Compilation problems and compiling with C++</a>
-</ul>
-<li><a href="Ocaml.html#Ocaml_nn8">The low-level Ocaml/C interface</a>
-<ul>
-<li><a href="Ocaml.html#Ocaml_nn9">The generated module</a>
-<li><a href="Ocaml.html#Ocaml_nn10">Enums</a>
-<ul>
-<li><a href="Ocaml.html#Ocaml_nn11">Enum typing in Ocaml</a>
-</ul>
-<li><a href="Ocaml.html#Ocaml_nn12">Arrays</a>
-<ul>
-<li><a href="Ocaml.html#Ocaml_nn13">Simple types of bounded arrays</a>
-<li><a href="Ocaml.html#Ocaml_nn14">Complex and unbounded arrays</a>
-<li><a href="Ocaml.html#Ocaml_nn15">Using an object</a>
-<li><a href="Ocaml.html#Ocaml_nn16">Example typemap for a function taking float * and int</a>
-</ul>
-<li><a href="Ocaml.html#Ocaml_nn17">C++ Classes</a>
-<ul>
-<li><a href="Ocaml.html#Ocaml_nn18">STL vector and string Example</a>
-<li><a href="Ocaml.html#Ocaml_nn19">C++ Class Example</a>
-<li><a href="Ocaml.html#Ocaml_nn20">Compiling the example</a>
-<li><a href="Ocaml.html#Ocaml_nn21">Sample Session</a>
-</ul>
-<li><a href="Ocaml.html#Ocaml_nn22">Director Classes</a>
-<ul>
-<li><a href="Ocaml.html#Ocaml_nn23">Director Introduction</a>
-<li><a href="Ocaml.html#Ocaml_nn24">Overriding Methods in Ocaml</a>
-<li><a href="Ocaml.html#Ocaml_nn25">Director Usage Example</a>
-<li><a href="Ocaml.html#Ocaml_nn26">Creating director objects</a>
-<li><a href="Ocaml.html#Ocaml_nn27">Typemaps for directors, directorin, directorout, directorargout</a>
-<li><a href="Ocaml.html#Ocaml_nn28">typemap</a>
-<li><a href="Ocaml.html#Ocaml_nn29">directorout typemap</a>
-<li><a href="Ocaml.html#Ocaml_nn30">directorargout typemap</a>
-</ul>
-<li><a href="Ocaml.html#Ocaml_nn31">Exceptions</a>
-</ul>
-<li><a href="Ocaml.html#Ocaml_nn32">Documentation Features</a>
-<ul>
-<li><a href="Ocaml.html#Ocaml_nn33">Module docstring</a>
-</ul>
-</ul>
-</div>
-<!-- INDEX -->
-
 <h3><a href="Octave.html#Octave">29 SWIG and Octave</a></h3>
 
 <!-- INDEX -->
@@ -1812,7 +1772,62 @@
 </div>
 <!-- INDEX -->
 
-<h3><a href="Extending.html#Extending">38 Extending SWIG to support new languages</a></h3>
+<h3><a href="Ocaml.html#Ocaml">38 SWIG and OCaml</a></h3>
+
+<!-- INDEX -->
+<div class="sectiontoc">
+<ul>
+<li><a href="Ocaml.html#Ocaml_nn2">Preliminaries</a>
+<ul>
+<li><a href="Ocaml.html#Ocaml_nn3">Running SWIG</a>
+<li><a href="Ocaml.html#Ocaml_nn4">Compiling the code</a>
+<li><a href="Ocaml.html#Ocaml_nn5">The camlp4 module</a>
+<li><a href="Ocaml.html#Ocaml_nn6">Using your module</a>
+<li><a href="Ocaml.html#Ocaml_nn7">Compilation problems and compiling with C++</a>
+</ul>
+<li><a href="Ocaml.html#Ocaml_nn8">The low-level Ocaml/C interface</a>
+<ul>
+<li><a href="Ocaml.html#Ocaml_nn9">The generated module</a>
+<li><a href="Ocaml.html#Ocaml_nn10">Enums</a>
+<ul>
+<li><a href="Ocaml.html#Ocaml_nn11">Enum typing in Ocaml</a>
+</ul>
+<li><a href="Ocaml.html#Ocaml_nn12">Arrays</a>
+<ul>
+<li><a href="Ocaml.html#Ocaml_nn13">Simple types of bounded arrays</a>
+<li><a href="Ocaml.html#Ocaml_nn14">Complex and unbounded arrays</a>
+<li><a href="Ocaml.html#Ocaml_nn15">Using an object</a>
+<li><a href="Ocaml.html#Ocaml_nn16">Example typemap for a function taking float * and int</a>
+</ul>
+<li><a href="Ocaml.html#Ocaml_nn17">C++ Classes</a>
+<ul>
+<li><a href="Ocaml.html#Ocaml_nn18">STL vector and string Example</a>
+<li><a href="Ocaml.html#Ocaml_nn19">C++ Class Example</a>
+<li><a href="Ocaml.html#Ocaml_nn20">Compiling the example</a>
+<li><a href="Ocaml.html#Ocaml_nn21">Sample Session</a>
+</ul>
+<li><a href="Ocaml.html#Ocaml_nn22">Director Classes</a>
+<ul>
+<li><a href="Ocaml.html#Ocaml_nn23">Director Introduction</a>
+<li><a href="Ocaml.html#Ocaml_nn24">Overriding Methods in Ocaml</a>
+<li><a href="Ocaml.html#Ocaml_nn25">Director Usage Example</a>
+<li><a href="Ocaml.html#Ocaml_nn26">Creating director objects</a>
+<li><a href="Ocaml.html#Ocaml_nn27">Typemaps for directors, directorin, directorout, directorargout</a>
+<li><a href="Ocaml.html#Ocaml_nn28">typemap</a>
+<li><a href="Ocaml.html#Ocaml_nn29">directorout typemap</a>
+<li><a href="Ocaml.html#Ocaml_nn30">directorargout typemap</a>
+</ul>
+<li><a href="Ocaml.html#Ocaml_nn31">Exceptions</a>
+</ul>
+<li><a href="Ocaml.html#Ocaml_nn32">Documentation Features</a>
+<ul>
+<li><a href="Ocaml.html#Ocaml_nn33">Module docstring</a>
+</ul>
+</ul>
+</div>
+<!-- INDEX -->
+
+<h3><a href="Extending.html#Extending">39 Extending SWIG to support new languages</a></h3>
 
 <!-- INDEX -->
 <div class="sectiontoc">
diff --git a/Doc/Manual/Contract.html b/Doc/Manual/Contract.html
index 2394db25e..93fb8c003 100644
--- a/Doc/Manual/Contract.html
+++ b/Doc/Manual/Contract.html
@@ -7,7 +7,7 @@
 </head>
 
 <body bgcolor="#ffffff">
-<H1><a name="Contract">14 Contracts</a></H1>
+<H1><a name="Contract">15 Contracts</a></H1>
 <!-- INDEX -->
 <div class="sectiontoc">
 <ul>
@@ -39,7 +39,7 @@ When one of the rules is violated by a script, a runtime exception is
 generated rather than having the program continue to execute.
 </p>
 
-<H2><a name="Contract_nn2">14.1 The %contract directive</a></H2>
+<H2><a name="Contract_nn2">15.1 The %contract directive</a></H2>
 
 
 <p>
@@ -95,7 +95,7 @@ RuntimeError: Contract violation: require: (arg1&gt;=0)
 </pre>
 </div>
 
-<H2><a name="Contract_nn3">14.2 %contract and classes</a></H2>
+<H2><a name="Contract_nn3">15.2 %contract and classes</a></H2>
 
 
 <p>
@@ -174,7 +174,7 @@ specified for the derived class all must hold.  In the above example,
 this means that both the arguments to <tt>Spam::bar</tt> must be positive.
 </p>
 
-<H2><a name="Contract_nn4">14.3 Constant aggregation and %aggregate_check</a></H2>
+<H2><a name="Contract_nn4">15.3 Constant aggregation and %aggregate_check</a></H2>
 
 
 <p>
@@ -263,7 +263,7 @@ Regrettably, there is no automatic way to perform similar checks with enums valu
 release.
 </p>
 
-<H2><a name="Contract_nn5">14.4 Notes</a></H2>
+<H2><a name="Contract_nn5">15.4 Notes</a></H2>
 
 
 <p>
diff --git a/Doc/Manual/Customization.html b/Doc/Manual/Customization.html
index 27a291d0c..328bc2391 100644
--- a/Doc/Manual/Customization.html
+++ b/Doc/Manual/Customization.html
@@ -7,7 +7,7 @@
 </head>
 
 <body bgcolor="#ffffff">
-<H1><a name="Customization">13 Customization Features</a></H1>
+<H1><a name="Customization">14 Customization Features</a></H1>
 <!-- INDEX -->
 <div class="sectiontoc">
 <ul>
@@ -46,7 +46,7 @@ of exception handling is presented.  Then, a more general-purpose
 customization mechanism known as "features" is described.
 </p>
 
-<H2><a name="Customization_exception">13.1 Exception handling with %exception</a></H2>
+<H2><a name="Customization_exception">14.1 Exception handling with %exception</a></H2>
 
 
 <p>
@@ -101,7 +101,7 @@ for exception handling.   That directive is deprecated--<tt>%exception</tt>
 provides the same functionality, but is substantially more flexible.
 </p>
 
-<H3><a name="Customization_nn3">13.1.1 Handling exceptions in C code</a></H3>
+<H3><a name="Customization_nn3">14.1.1 Handling exceptions in C code</a></H3>
 
 
 <p>
@@ -169,7 +169,7 @@ Each target language has its own approach to creating a runtime error/exception
 and for Perl it is the <tt>croak</tt> method shown above.
 </p>
 
-<H3><a name="Customization_nn4">13.1.2 Exception handling with longjmp()</a></H3>
+<H3><a name="Customization_nn4">14.1.2 Exception handling with longjmp()</a></H3>
 
 
 <p>
@@ -245,7 +245,7 @@ Note: This implementation is only intended to illustrate the general idea.  To m
 modify it to handle nested <tt>try</tt> declarations.
 </p>
 
-<H3><a name="Customization_nn5">13.1.3 Handling C++ exceptions</a></H3>
+<H3><a name="Customization_nn5">14.1.3 Handling C++ exceptions</a></H3>
 
 
 <p>
@@ -280,7 +280,7 @@ class OutOfMemory {};
 </pre>
 </div>
 
-<H3><a name="Customization_allowexcept">13.1.4 Exception handlers for variables</a></H3>
+<H3><a name="Customization_allowexcept">14.1.4 Exception handlers for variables</a></H3>
 
 
 <p>
@@ -305,7 +305,7 @@ The <tt>%allowexception</tt> feature works like any other feature and so can be
 </pre>
 </div>
 
-<H3><a name="Customization_nn6">13.1.5 Defining different exception handlers</a></H3>
+<H3><a name="Customization_nn6">14.1.5 Defining different exception handlers</a></H3>
 
 
 <p>
@@ -442,7 +442,7 @@ declarations.  However, it never really worked that well and the new
 %exception directive is much better.
 </p>
 
-<H3><a name="Customization_exception_special_variables">13.1.6 Special variables for %exception</a></H3>
+<H3><a name="Customization_exception_special_variables">14.1.6 Special variables for %exception</a></H3>
 
 
 <p>
@@ -545,7 +545,7 @@ Below shows the expansions for the 1st of the overloaded <tt>something</tt> wrap
 </pre></div>
 
 
-<H3><a name="Customization_nn7">13.1.7 Using The SWIG exception library</a></H3>
+<H3><a name="Customization_nn7">14.1.7 Using The SWIG exception library</a></H3>
 
 
 <p>
@@ -600,7 +600,7 @@ SWIG_NullReferenceError
 The <tt>SWIG_exception()</tt> function can also be used in typemaps.
 </p>
 
-<H2><a name="Customization_ownership">13.2 Object ownership and %newobject</a></H2>
+<H2><a name="Customization_ownership">14.2 Object ownership and %newobject</a></H2>
 
 
 <p>
@@ -757,7 +757,7 @@ char *strdup(const char *s);
 The results might not be what you expect.
 </p>
 
-<H2><a name="Customization_features">13.3 Features and the %feature directive</a></H2>
+<H2><a name="Customization_features">14.3 Features and the %feature directive</a></H2>
 
 
 <p>
@@ -839,7 +839,7 @@ The following are all equivalent:
 The syntax in the first variation will generate the <tt>{ }</tt> delimiters used whereas the other variations will not.
 </p>
 
-<H3><a name="Customization_feature_attributes">13.3.1 Feature attributes</a></H3>
+<H3><a name="Customization_feature_attributes">14.3.1 Feature attributes</a></H3>
 
 
 <p>
@@ -880,7 +880,7 @@ In the following example, <tt>MyExceptionClass</tt> is the name of the Java clas
 Further details can be obtained from the <a href="Java.html#Java_exception_handling">Java exception handling</a> section.
 </p>
 
-<H3><a name="Customization_feature_flags">13.3.2 Feature flags</a></H3>
+<H3><a name="Customization_feature_flags">14.3.2 Feature flags</a></H3>
 
 
 <p>
@@ -978,7 +978,7 @@ in the <tt>swig.swg</tt> Library file. The following shows the alternative synta
 The concept of clearing features is discussed next.
 </p>
 
-<H3><a name="Customization_clearing_features">13.3.3 Clearing features</a></H3>
+<H3><a name="Customization_clearing_features">14.3.3 Clearing features</a></H3>
 
 
 <p>
@@ -1071,7 +1071,7 @@ The three macros below show this for the "except" feature:
 </pre>
 </div>
 
-<H3><a name="Customization_features_default_args">13.3.4 Features and default arguments</a></H3>
+<H3><a name="Customization_features_default_args">14.3.4 Features and default arguments</a></H3>
 
 
 <p>
@@ -1146,7 +1146,7 @@ specifying or not specifying default arguments in a feature is not applicable as
 in SWIG-1.3.23 when the approach to wrapping methods with default arguments was changed.
 </p>
 
-<H3><a name="Customization_features_example">13.3.5 Feature example</a></H3>
+<H3><a name="Customization_features_example">14.3.5 Feature example</a></H3>
 
 
 <p>
diff --git a/Doc/Manual/D.html b/Doc/Manual/D.html
index 1a317a005..a252650ff 100644
--- a/Doc/Manual/D.html
+++ b/Doc/Manual/D.html
@@ -6,7 +6,7 @@
 <meta http-equiv="content-type" content="text/html; charset=UTF-8">
 </head>
 <body bgcolor="#FFFFFF">
-<H1><a name="D">22 SWIG and D</a></H1>
+<H1><a name="D">23 SWIG and D</a></H1>
 <!-- INDEX -->
 <div class="sectiontoc">
 <ul>
@@ -41,7 +41,7 @@
 
 
 
-<H2><a name="D_introduction">22.1 Introduction</a></H2>
+<H2><a name="D_introduction">23.1 Introduction</a></H2>
 
 
 <p>From the <a href="http://www.digitalmars.com/d/">D Programming Language</a> web site: <em>D is a systems programming language. Its focus is on combining the power and high performance of C and C++ with the programmer productivity of modern languages like Ruby and Python. [...] The D language is statically typed and compiles directly to machine code.</em> As such, it is not very surprising that D is able to directly <a href="http://www.digitalmars.com/d/1.0/interfaceToC.html">interface with C libraries</a>. Why would a SWIG module for D be needed then in the first place?</p>
@@ -53,7 +53,7 @@
 <p>To help addressing these issues, the SWIG C# module has been forked to support D. Is has evolved quite a lot since then, but there are still many similarities, so if you do not find what you are looking for on this page, it might be worth having a look at the chapter on <a href="CSharp.html#CSharp">C#</a> (and also on <a href="Java.html#Java">Java</a>, since the C# module was in turn forked from it).</p>
 
 
-<H2><a name="D_command_line_invocation">22.2 Command line invocation</a></H2>
+<H2><a name="D_command_line_invocation">23.2 Command line invocation</a></H2>
 
 
 <p>To activate the D module, pass the <tt>-d</tt> option to SWIG at the command line. The same standard command line switches as with any other language module are available, plus the following D specific ones:</p>
@@ -83,10 +83,10 @@
 </dl>
 
 
-<H2><a name="D_typemaps">22.3 Typemaps</a></H2>
+<H2><a name="D_typemaps">23.3 Typemaps</a></H2>
 
 
-<H3><a name="D_typemap_name_comparison">22.3.1 C# &lt;-&gt; D name comparison</a></H3>
+<H3><a name="D_typemap_name_comparison">23.3.1 C# &lt;-&gt; D name comparison</a></H3>
 
 
 <p>If you already know the SWIG C# module, you might find the following name comparison table useful:</p>
@@ -112,7 +112,7 @@
 </pre></div>
 
 
-<H3><a name="D_ctype_imtype_dtype">22.3.2 ctype, imtype, dtype</a></H3>
+<H3><a name="D_ctype_imtype_dtype">23.3.2 ctype, imtype, dtype</a></H3>
 
 
 <p>Mapping of types between the C/C++ library, the C/C++ library wrapper exposing the C functions, the D wrapper module importing these functions and the D proxy code.</p>
@@ -120,7 +120,7 @@
 <p>The <tt>ctype</tt> typemap is used to determine the types to use in the C wrapper functions. The types from the <tt>imtype</tt> typemap are used in the extern(C) declarations of these functions in the intermediary D module. The <tt>dtype</tt> typemap contains the D types used in the D proxy module/class.</p>
 
 
-<H3><a name="D_in_out_directorin_direcetorout">22.3.3 in, out, directorin, directorout</a></H3>
+<H3><a name="D_in_out_directorin_direcetorout">23.3.3 in, out, directorin, directorout</a></H3>
 
 
 <p>Used for converting between the types for C/C++ and D when generating the code for the wrapper functions (on the C++ side).</p>
@@ -130,7 +130,7 @@
 <p>The <tt>directorin</tt> typemap is used to convert parameters to the type used in the D director callback function, its return value is processed by <tt>directorout</tt> (see below).</p>
 
 
-<H3><a name="D_din_dout_ddirectorin_ddirectorout">22.3.4 din, dout, ddirectorin, ddirectorout</a></H3>
+<H3><a name="D_din_dout_ddirectorin_ddirectorout">23.3.4 din, dout, ddirectorin, ddirectorout</a></H3>
 
 
 <p>Typemaps for code generation in D proxy and type wrapper classes.</p>
@@ -157,13 +157,13 @@
       dtype             DClass.method(dtype a)</pre></div>
 
 
-<H3><a name="D_typecheck_typemaps">22.3.5 typecheck typemaps</a></H3>
+<H3><a name="D_typecheck_typemaps">23.3.5 typecheck typemaps</a></H3>
 
 
 <p>Because, unlike many scripting languages supported by SWIG, D does not need any dynamic dispatch helper to access an overloaded function, the purpose of these is merely to issue a warning for overloaded C++ functions that cannot be overloaded in D (as more than one C++ type maps to a single D type).</p>
 
 
-<H3><a name="D_code_injection_typemaps">22.3.6 Code injection typemaps</a></H3>
+<H3><a name="D_code_injection_typemaps">23.3.6 Code injection typemaps</a></H3>
 
 
 <p>These typemaps are used for generating the skeleton of proxy classes for C++ types.</p>
@@ -178,7 +178,7 @@
 Code can also be injected into the D proxy class using <tt>%proxycode</tt>.
 </p>
 
-<H3><a name="D_special_variables">22.3.7 Special variable macros</a></H3>
+<H3><a name="D_special_variables">23.3.7 Special variable macros</a></H3>
 
 
 <p>The standard SWIG special variables are available for use within typemaps as described in the <a href="Typemaps.html#Typemaps">Typemaps documentation</a>, for example <tt>$1</tt>, <tt>$input</tt>, <tt>$result</tt> etc.</p>
@@ -299,7 +299,7 @@ $importtype(AnotherInterface)
 </dl>
 
 
-<H2><a name="D_features">22.4 D and %feature</a></H2>
+<H2><a name="D_features">23.4 D and %feature</a></H2>
 
 
 <p>The D module defines a number of directives which modify the <a href="Customization.html#Customization_features">SWIG features</a> set globally or for a specific declaration:</p>
@@ -329,7 +329,7 @@ struct A {
 </dl>
 
 
-<H2><a name="D_pragmas">22.5 Pragmas</a></H2>
+<H2><a name="D_pragmas">23.5 Pragmas</a></H2>
 
 
 <p>There are a few SWIG pragmas specific to the D module, which you can use to influence the D code SWIG generates:</p>
@@ -368,7 +368,7 @@ struct A {
 </dl>
 
 
-<H2><a name="D_exceptions">22.6 D Exceptions</a></H2>
+<H2><a name="D_exceptions">23.6 D Exceptions</a></H2>
 
 
 <p>Out of the box, C++ exceptions are fundamentally incompatible to their equivalent in the D world and cannot simply be propagated to a calling D method. There is, however, an easy way to solve this problem: Just catch the exception in the C/C++ wrapper layer, pass the contents to D, and make the wrapper code rethrow the exception in the D world.</p>
@@ -378,7 +378,7 @@ struct A {
 <p>As this feature is implemented in exactly the same way it is for C#, please see the <a href="CSharp.html#CSharp_exceptions">C# documentation</a> for a more detailed explanation.</p>
 
 
-<H2><a name="D_directors">22.7 D Directors</a></H2>
+<H2><a name="D_directors">23.7 D Directors</a></H2>
 
 
 <p>When the directors feature is activated, SWIG generates extra code on both the C++ and the D side to enable cross-language polymorphism. Essentially, this means that if you subclass a proxy class in D, C++ code can access any overridden virtual methods just as if you created a derived class in C++.</p>
@@ -387,16 +387,16 @@ struct A {
 </p>
 
 
-<H2><a name="D_other_features">22.8 Other features</a></H2>
+<H2><a name="D_other_features">23.8 Other features</a></H2>
 
 
-<H3><a name="D_nspace">22.8.1 Extended namespace support (nspace)</a></H3>
+<H3><a name="D_nspace">23.8.1 Extended namespace support (nspace)</a></H3>
 
 
 <p>By default, SWIG flattens all C++ namespaces into a single target language namespace, but as for Java and C#, the <a href="SWIGPlus.html#SWIGPlus_nspace"><tt>nspace</tt></a> feature is supported for D. If it is active, C++ namespaces are mapped to D packages/modules. Note, however, that like for the other languages, <em>free</em> variables and functions are not supported yet; currently, they are all allows written to the main proxy D module.</p>
 
 
-<H3><a name="D_native_pointer_support">22.8.2 Native pointer support</a></H3>
+<H3><a name="D_native_pointer_support">23.8.2 Native pointer support</a></H3>
 
 
 <p>Contrary to many of the scripting languages supported by SWIG, D fully supports C-style pointers. The D module thus includes a custom mechanism to wrap C pointers directly as D pointers where applicable, that is, if the type that is pointed to is represented the same in C and D (on the bit-level), dubbed a <em>primitive type</em> below.</p>
@@ -408,7 +408,7 @@ struct A {
 <p>To determine if a type should be considered primitive, the <tt>cprimitive</tt> attribute on its <tt>dtype</tt> attribute is used. For example, the <tt>dtype</tt> typemap for <tt>float</tt> has <tt>cprimitive="1"</tt>, so the code from the <tt>nativepointer</tt> attribute is taken into account e.g. for <tt>float **</tt> or the function pointer <tt>float (*)(float *)</tt>.</p>
 
 
-<H3><a name="D_operator_overloading">22.8.3 Operator overloading</a></H3>
+<H3><a name="D_operator_overloading">23.8.3 Operator overloading</a></H3>
 
 
 <p>The D module comes with basic operator overloading support for both D1 and D2. There are, however, a few limitations arising from conceptual differences between C++ and D:</p>
@@ -420,7 +420,7 @@ struct A {
 <p>There are also some cases where the operators can be translated to D, but the differences in the implementation details are big enough that a rather involved scheme would be required for automatic wrapping them, which has not been implemented yet. This affects, for example, the array subscript operator, <tt>[]</tt>, in combination with assignments - while <tt>operator []</tt> in C++ simply returns a reference which is then written to, D resorts to a separate <tt>opIndexAssign</tt> method -, or implicit casting (which was introduced in D2 via <tt>alias this</tt>). Despite the lack of automatic support, manually handling these cases should be perfectly possible.</p>
 
 
-<H3><a name="D_test_suite">22.8.4 Running the test-suite</a></H3>
+<H3><a name="D_test_suite">23.8.4 Running the test-suite</a></H3>
 
 
 <p>As with any other language, the SWIG test-suite can be built for D using the <tt>*-d-test-suite</tt> targets of the top-level Makefile. By default, D1 is targeted, to build it with D2, use the optional <tt>D_VERSION</tt> variable, e.g. <tt>make check-d-test-suite D_VERSION=2</tt>.</p>
@@ -428,14 +428,14 @@ struct A {
 <p>Note: If you want to use GDC on Linux or another platform which requires you to link <tt>libdl</tt> for dynamically loading the shared library, you might have to add <tt>-ldl</tt> manually to the <tt>d_compile</tt> target in <tt>Examples/Makefile</tt>, because GDC does not currently honor the <tt>pragma(lib, ...)</tt> statement.</p>
 
 
-<H2><a name="D_typemap_examples">22.9 D Typemap examples</a></H2>
+<H2><a name="D_typemap_examples">23.9 D Typemap examples</a></H2>
 
 
 <p>There are no D-specific typemap examples yet. However, with the above <a href="D.html#D_typemap_name_comparison">name comparison table</a>, you should be able to get an idea what can be done by looking at the <a href="CSharp.html#CSharp_typemap_examples">corresponding C# section</a>.</p>
 
 
 
-<H2><a name="D_planned_features">22.10 Work in progress and planned features</a></H2>
+<H2><a name="D_planned_features">23.10 Work in progress and planned features</a></H2>
 
 
 <p>There are a couple of features which are not implemented yet, but would be very useful and might be added in the near future:</p>
diff --git a/Doc/Manual/Doxygen.html b/Doc/Manual/Doxygen.html
index 1e9bbb977..b14b05ba3 100644
--- a/Doc/Manual/Doxygen.html
+++ b/Doc/Manual/Doxygen.html
@@ -5,7 +5,7 @@
 <link rel="stylesheet" type="text/css" href="style.css">
 </head>
 <body bgcolor="#FFFFFF">
-<H1><a name="Doxygen">16 SWIG and Doxygen Translation</a></H1>
+<H1><a name="Doxygen">17 SWIG and Doxygen Translation</a></H1>
 <!-- INDEX -->
 <div class="sectiontoc">
 <ul>
@@ -57,7 +57,7 @@ documentation language.  Currently only Javadoc and Pydoc is
 supported.
 </p>
 
-<H2><a name="Doxygen_translation_overview">16.1 Doxygen translation overview</a></H2>
+<H2><a name="Doxygen_translation_overview">17.1 Doxygen translation overview</a></H2>
 
 
 <p>
@@ -73,7 +73,7 @@ a <a href="http://code.google.com/soc/2008/">Google Summer of
 Code</a> proposal from Summer 2008.  
 </p>
 
-<H2><a name="Doxygen_file_preparation">16.2 Preparations</a></H2>
+<H2><a name="Doxygen_file_preparation">17.2 Preparations</a></H2>
 
 
 <p>
@@ -189,7 +189,7 @@ where the comments for a code item are not put directly before or after the code
 These structural commands are stripped out by SWIG and are not assigned to anything.
 </p>
 
-<H3><a name="Doxygen_running_swig">16.2.1 Enabling Doxygen translation</a></H3>
+<H3><a name="Doxygen_running_swig">17.2.1 Enabling Doxygen translation</a></H3>
 
 
 <p>
@@ -198,7 +198,7 @@ enabled using the command line <tt>-doxygen</tt> switch for the languages that
 do support it (currently Java and Python).
 </p>
 
-<H3><a name="Doxygen_features">16.2.2 Doxygen-specific %feature directives</a></H3>
+<H3><a name="Doxygen_features">17.2.2 Doxygen-specific %feature directives</a></H3>
 
 
 <p>
@@ -206,7 +206,7 @@ Translation of Doxygen comments is influenced by the following <a
 href="Customization.html#Customization_features">%feature directives</a>:
 </p>
 
-<H4><a name="Doxygen_notranslate">16.2.2.1 doxygen:notranslate</a></H4>
+<H4><a name="Doxygen_notranslate">17.2.2.1 doxygen:notranslate</a></H4>
 
 
 <p>
@@ -218,7 +218,7 @@ instead of the corresponding language tool (<tt>javadoc</tt>, <tt>sphinx</tt>,
 </p>
 
 
-<H4><a name="Doxygen_alias">16.2.2.2 doxygen:alias:&lt;command-name&gt;</a></H4>
+<H4><a name="Doxygen_alias">17.2.2.2 doxygen:alias:&lt;command-name&gt;</a></H4>
 
 
 <p>
@@ -265,7 +265,7 @@ wrappers of the C++ API.
 </p>
 
 
-<H4><a name="Doxygen_ignore">16.2.2.3 doxygen:ignore:&lt;command-name&gt;</a></H4>
+<H4><a name="Doxygen_ignore">17.2.2.3 doxygen:ignore:&lt;command-name&gt;</a></H4>
 
 
 <p>
@@ -416,7 +416,7 @@ def func():
 </pre></div>
 
 
-<H4><a name="Doxygen_nolinktranslate">16.2.2.4 doxygen:nolinktranslate</a></H4>
+<H4><a name="Doxygen_nolinktranslate">17.2.2.4 doxygen:nolinktranslate</a></H4>
 
 
 <p>
@@ -425,7 +425,7 @@ This is only applicable to Java at the moment.
 </p>
 
 
-<H4><a name="Doxygen_nostripparams">16.2.2.5 doxygen:nostripparams</a></H4>
+<H4><a name="Doxygen_nostripparams">17.2.2.5 doxygen:nostripparams</a></H4>
 
 
 <p>
@@ -435,14 +435,14 @@ This is only applicable to Java at the moment.
 </p>
 
 
-<H3><a name="Doxygen_additional_options">16.2.3 Additional command line options</a></H3>
+<H3><a name="Doxygen_additional_options">17.2.3 Additional command line options</a></H3>
 
 
 <p>
 ALSO TO BE ADDED (Javadoc auto brief?)
 </p>
 
-<H2><a name="Doxygen_to_javadoc">16.3 Doxygen to Javadoc</a></H2>
+<H2><a name="Doxygen_to_javadoc">17.3 Doxygen to Javadoc</a></H2>
 
 
 <p>
@@ -451,7 +451,7 @@ automatically placed in the correct locations in the resulting module
 and proxy files.
 </p>
 
-<H3><a name="Doxygen_basic_example">16.3.1 Basic example</a></H3>
+<H3><a name="Doxygen_basic_example">17.3.1 Basic example</a></H3>
 
 
 <p>
@@ -558,7 +558,7 @@ Javadoc translator features summary
 directives</a>):
 </p>
 
-<H3><a name="Doxygen_javadoc_tags">16.3.2 Javadoc tags</a></H3>
+<H3><a name="Doxygen_javadoc_tags">17.3.2 Javadoc tags</a></H3>
 
 
 <p>
@@ -812,7 +812,7 @@ Here is the list of all Doxygen tags and the description of how they are transla
 </table>
 </div>
 
-<H3><a name="Doxygen_unsupported_tags">16.3.3 Unsupported tags</a></H3>
+<H3><a name="Doxygen_unsupported_tags">17.3.3 Unsupported tags</a></H3>
 
 
 <p>
@@ -1048,14 +1048,14 @@ comment, the whole comment block is ignored:
 
 
 
-<H3><a name="Doxygen_further_details">16.3.4 Further details</a></H3>
+<H3><a name="Doxygen_further_details">17.3.4 Further details</a></H3>
 
 
 <p>
 TO BE ADDED.
 </p>
 
-<H2><a name="Doxygen_to_pydoc">16.4 Doxygen to Pydoc</a></H2>
+<H2><a name="Doxygen_to_pydoc">17.4 Doxygen to Pydoc</a></H2>
 
 
 <p>
@@ -1066,7 +1066,7 @@ Doxygen or Javadoc, so most of Doxygen commands are translated by merely
 copying the appropriate command text.
 </p>
 
-<H3><a name="Doxygen_python_basic_example">16.4.1 Basic example</a></H3>
+<H3><a name="Doxygen_python_basic_example">17.4.1 Basic example</a></H3>
 
 
 <p>
@@ -1229,7 +1229,7 @@ docs</a>), you may want to use some tool like doxypy
 to do the work.
 </p>
 
-<H3><a name="Doxygen_pydoc_tags">16.4.2 Pydoc translator</a></H3>
+<H3><a name="Doxygen_pydoc_tags">17.4.2 Pydoc translator</a></H3>
 
 
 <p>
@@ -1443,7 +1443,7 @@ Here is the list of all Doxygen tags and the description of how they are transla
 </table>
 </div>
 
-<H3><a name="Doxygen_python_unsupported_tags">16.4.3 Unsupported tags</a></H3>
+<H3><a name="Doxygen_python_unsupported_tags">17.4.3 Unsupported tags</a></H3>
 
 
 <p>
@@ -1627,21 +1627,21 @@ Here is the list of these tags:
 </table>
 </div>
 
-<H3><a name="Doxygen_python_further_details">16.4.4 Further details</a></H3>
+<H3><a name="Doxygen_python_further_details">17.4.4 Further details</a></H3>
 
 
 <p>
 TO BE ADDED.
 </p>
 
-<H2><a name="Doxygen_developer_details">16.5 Developer information</a></H2>
+<H2><a name="Doxygen_developer_details">17.5 Developer information</a></H2>
 
 
 <p>
 This section contains information for developers enhancing the Doxygen translator.
 </p>
 
-<H3><a name="Doxygen_translator_design">16.5.1 Doxygen translator design</a></H3>
+<H3><a name="Doxygen_translator_design">17.5.1 Doxygen translator design</a></H3>
 
 
 <p>
@@ -1667,7 +1667,7 @@ class for translation into the target documentation language.  For
 example, <tt>JavaDocConverter</tt> is the Javadoc module class.
 </p>
 
-<H3><a name="Doxygen_debugging_commands">16.5.2 Debugging the Doxygen parser and translator</a></H3>
+<H3><a name="Doxygen_debugging_commands">17.5.2 Debugging the Doxygen parser and translator</a></H3>
 
 
 <p>
@@ -1680,7 +1680,7 @@ detailed debug information printing.
   -debug-doxygen-translator - Display Doxygen translator module debugging information
 </pre></div>
 
-<H3><a name="Doxygen_tests">16.5.3 Tests</a></H3>
+<H3><a name="Doxygen_tests">17.5.3 Tests</a></H3>
 
 
 <p>
@@ -1732,7 +1732,7 @@ Runtime tests in Python are just plain string comparisons of the __doc__
 properties.
 </p>
 
-<H2><a name="Doxygen_language_extension">16.6 Extending to other languages</a></H2>
+<H2><a name="Doxygen_language_extension">17.6 Extending to other languages</a></H2>
 
 
 <p>
diff --git a/Doc/Manual/Extending.html b/Doc/Manual/Extending.html
index 1d9fc83ac..1deb1cb12 100644
--- a/Doc/Manual/Extending.html
+++ b/Doc/Manual/Extending.html
@@ -7,7 +7,7 @@
 </head>
 
 <body bgcolor="#ffffff">
-<H1><a name="Extending">38 Extending SWIG to support new languages</a></H1>
+<H1><a name="Extending">39 Extending SWIG to support new languages</a></H1>
 <!-- INDEX -->
 <div class="sectiontoc">
 <ul>
@@ -81,7 +81,7 @@
 
 
 
-<H2><a name="Extending_nn2">38.1 Introduction</a></H2>
+<H2><a name="Extending_nn2">39.1 Introduction</a></H2>
 
 
 <p>
@@ -97,7 +97,7 @@ Also, this chapter is not meant to be a hand-holding tutorial.  As a starting po
 you should probably look at one of SWIG's existing modules.
 </p>
 
-<H2><a name="Extending_nn3">38.2 Prerequisites</a></H2>
+<H2><a name="Extending_nn3">39.2 Prerequisites</a></H2>
 
 
 <p>
@@ -127,7 +127,7 @@ obvious, but almost all SWIG directives as well as the low-level generation of
 wrapper code are driven by C++ datatypes.
 </p>
 
-<H2><a name="Extending_nn4">38.3 The Big Picture</a></H2>
+<H2><a name="Extending_nn4">39.3 The Big Picture</a></H2>
 
 
 <p>
@@ -164,7 +164,7 @@ role in making the system work.  For example, both typemaps and declaration anno
 based on pattern matching and interact heavily with the underlying type system.
 </p>
 
-<H2><a name="Extending_nn5">38.4 Execution Model</a></H2>
+<H2><a name="Extending_nn5">39.4 Execution Model</a></H2>
 
 
 <p>
@@ -209,7 +209,7 @@ latter stage of compilation.
 The next few sections briefly describe some of these stages.
 </p>
 
-<H3><a name="Extending_nn6">38.4.1 Preprocessing</a></H3>
+<H3><a name="Extending_nn6">39.4.1 Preprocessing</a></H3>
 
 
 <p>
@@ -290,7 +290,7 @@ been expanded as well as everything else that goes into the low-level
 construction of the wrapper code.
 </p>
 
-<H3><a name="Extending_nn7">38.4.2 Parsing</a></H3>
+<H3><a name="Extending_nn7">39.4.2 Parsing</a></H3>
 
 
 <p>
@@ -391,7 +391,7 @@ returning a <tt>foo</tt> and taking types <tt>a</tt> and <tt>b</tt> as
 arguments).
 </p>
 
-<H3><a name="Extending_nn8">38.4.3 Parse Trees</a></H3>
+<H3><a name="Extending_nn8">39.4.3 Parse Trees</a></H3>
 
 
 <p>
@@ -646,7 +646,7 @@ $ swig -c++ -python -debug-module 4 example.i
 </pre>
 </div>
 
-<H3><a name="Extending_nn9">38.4.4 Attribute namespaces</a></H3>
+<H3><a name="Extending_nn9">39.4.4 Attribute namespaces</a></H3>
 
 
 <p>
@@ -665,7 +665,7 @@ that matches the name of the target language.  For example, <tt>python:foo</tt>
 <tt>perl:foo</tt>.
 </p>
 
-<H3><a name="Extending_nn10">38.4.5 Symbol Tables</a></H3>
+<H3><a name="Extending_nn10">39.4.5 Symbol Tables</a></H3>
 
 
 <p>
@@ -756,7 +756,7 @@ example.i:5. Previous declaration is foo_i(int )
 </pre>
 </div>
 
-<H3><a name="Extending_nn11">38.4.6 The %feature directive</a></H3>
+<H3><a name="Extending_nn11">39.4.6 The %feature directive</a></H3>
 
 
 <p>
@@ -812,7 +812,7 @@ For example, the exception code above is simply
 stored without any modifications.
 </p>
 
-<H3><a name="Extending_nn12">38.4.7 Code Generation</a></H3>
+<H3><a name="Extending_nn12">39.4.7 Code Generation</a></H3>
 
 
 <p>
@@ -934,7 +934,7 @@ public :
 The role of these functions is described shortly.
 </p>
 
-<H3><a name="Extending_nn13">38.4.8 SWIG and XML</a></H3>
+<H3><a name="Extending_nn13">39.4.8 SWIG and XML</a></H3>
 
 
 <p>
@@ -947,7 +947,7 @@ internal data structures, it may be useful to keep XML in the back of
 your mind as a model.
 </p>
 
-<H2><a name="Extending_nn14">38.5 Primitive Data Structures</a></H2>
+<H2><a name="Extending_nn14">39.5 Primitive Data Structures</a></H2>
 
 
 <p>
@@ -993,7 +993,7 @@ typedef Hash   Typetab;
 </pre>
 </div>
 
-<H3><a name="Extending_nn15">38.5.1 Strings</a></H3>
+<H3><a name="Extending_nn15">39.5.1 Strings</a></H3>
 
 
 <p>
@@ -1134,7 +1134,7 @@ Returns the number of replacements made (if any).
 
 </div>
 
-<H3><a name="Extending_nn16">38.5.2 Hashes</a></H3>
+<H3><a name="Extending_nn16">39.5.2 Hashes</a></H3>
 
 
 <p>
@@ -1211,7 +1211,7 @@ Returns the list of hash table keys.
 </div>
 
 
-<H3><a name="Extending_nn17">38.5.3 Lists</a></H3>
+<H3><a name="Extending_nn17">39.5.3 Lists</a></H3>
 
 
 <p>
@@ -1300,7 +1300,7 @@ If <tt>t</tt> is not a standard object, it is assumed to be a <tt>char *</tt>
 and is used to create a String object.
 </div>
 
-<H3><a name="Extending_nn18">38.5.4 Common operations</a></H3>
+<H3><a name="Extending_nn18">39.5.4 Common operations</a></H3>
 
 
 The following operations are applicable to all datatypes.
@@ -1355,7 +1355,7 @@ objects and report errors.
 Gets the line number associated with <tt>x</tt>.
 </div>
 
-<H3><a name="Extending_nn19">38.5.5 Iterating over Lists and Hashes</a></H3>
+<H3><a name="Extending_nn19">39.5.5 Iterating over Lists and Hashes</a></H3>
 
 
 To iterate over the elements of a list or a hash table, the following functions are used:
@@ -1400,7 +1400,7 @@ for (j = First(j); j.item; j= Next(j)) {
 
 </div>
 
-<H3><a name="Extending_nn20">38.5.6 I/O</a></H3>
+<H3><a name="Extending_nn20">39.5.6 I/O</a></H3>
 
 
 Special I/O functions are used for all internal I/O.  These operations
@@ -1534,7 +1534,7 @@ Printf(f, "%s\n", s);
 Similarly, the preprocessor and parser all operate on string-files.
 </p>
 
-<H2><a name="Extending_nn21">38.6 Navigating and manipulating parse trees</a></H2>
+<H2><a name="Extending_nn21">39.6 Navigating and manipulating parse trees</a></H2>
 
 
 Parse trees are built as collections of hash tables.   Each node is a hash table in which
@@ -1668,7 +1668,7 @@ Deletes a node from the parse tree.  Deletion reconnects siblings and properly u
 the parent so that sibling nodes are unaffected.
 </div>
 
-<H2><a name="Extending_nn22">38.7 Working with attributes</a></H2>
+<H2><a name="Extending_nn22">39.7 Working with attributes</a></H2>
 
 
 <p>
@@ -1785,7 +1785,7 @@ the attribute is optional.   <tt>Swig_restore()</tt> must always be called after
 function.
 </div>
 
-<H2><a name="Extending_nn23">38.8 Type system</a></H2>
+<H2><a name="Extending_nn23">39.8 Type system</a></H2>
 
 
 <p>
@@ -1794,7 +1794,7 @@ pointers, references, and pointers to members.   A detailed discussion of
 type theory is impossible here.   However, let's cover the highlights.
 </p>
 
-<H3><a name="Extending_nn24">38.8.1 String encoding of types</a></H3>
+<H3><a name="Extending_nn24">39.8.1 String encoding of types</a></H3>
 
 
 <p>
@@ -1895,7 +1895,7 @@ make the final type, the two parts are just joined together using
 string concatenation.
 </p>
 
-<H3><a name="Extending_nn25">38.8.2 Type construction</a></H3>
+<H3><a name="Extending_nn25">39.8.2 Type construction</a></H3>
 
 
 <p>
@@ -2064,7 +2064,7 @@ Returns the prefix of a type. For example, if <tt>ty</tt> is
 <tt>ty</tt> is unmodified.
 </div>
 
-<H3><a name="Extending_nn26">38.8.3 Type tests</a></H3>
+<H3><a name="Extending_nn26">39.8.3 Type tests</a></H3>
 
 
 <p>
@@ -2151,7 +2151,7 @@ Checks if <tt>ty</tt> is a varargs type.
 Checks if <tt>ty</tt> is a templatized type.
 </div>
 
-<H3><a name="Extending_nn27">38.8.4 Typedef and inheritance</a></H3>
+<H3><a name="Extending_nn27">39.8.4 Typedef and inheritance</a></H3>
 
 
 <p>
@@ -2253,7 +2253,7 @@ Fully reduces <tt>ty</tt> according to typedef rules.  Resulting datatype
 will consist only of primitive typenames.
 </div>
 
-<H3><a name="Extending_nn28">38.8.5 Lvalues</a></H3>
+<H3><a name="Extending_nn28">39.8.5 Lvalues</a></H3>
 
 
 <p>
@@ -2290,7 +2290,7 @@ Literal y;    // type = 'Literal', ltype='p.char'
 </pre>
 </div>
 
-<H3><a name="Extending_nn29">38.8.6 Output functions</a></H3>
+<H3><a name="Extending_nn29">39.8.6 Output functions</a></H3>
 
 
 <p>
@@ -2352,7 +2352,7 @@ SWIG, but is most commonly associated with type-descriptor objects
 that appear in wrappers (e.g., <tt>SWIGTYPE_p_double</tt>).
 </div>
 
-<H2><a name="Extending_nn30">38.9 Parameters</a></H2>
+<H2><a name="Extending_nn30">39.9 Parameters</a></H2>
 
 
 <p>
@@ -2451,7 +2451,7 @@ included.  Used to emit prototypes.
 Returns the number of required (non-optional) arguments in <tt>p</tt>.
 </div>
 
-<H2><a name="Extending_nn31">38.10 Writing a Language Module</a></H2>
+<H2><a name="Extending_nn31">39.10 Writing a Language Module</a></H2>
 
 
 <p>
@@ -2466,7 +2466,7 @@ describes the creation of a minimal Python module.   You should be able to extra
 this to other languages.
 </p>
 
-<H3><a name="Extending_nn32">38.10.1 Execution model</a></H3>
+<H3><a name="Extending_nn32">39.10.1 Execution model</a></H3>
 
 
 <p>
@@ -2476,7 +2476,7 @@ the parsing of command line options, all aspects of code generation are controll
 different methods of the <tt>Language</tt> that must be defined by your module.
 </p>
 
-<H3><a name="Extending_starting_out">38.10.2 Starting out</a></H3>
+<H3><a name="Extending_starting_out">39.10.2 Starting out</a></H3>
 
 
 <p>
@@ -2584,7 +2584,7 @@ that activates your module. For example, <tt>swig -python foo.i</tt>. The
 messages from your new module should appear.
 </p>
 
-<H3><a name="Extending_nn34">38.10.3 Command line options</a></H3>
+<H3><a name="Extending_nn34">39.10.3 Command line options</a></H3>
 
 
 <p>
@@ -2643,7 +2643,7 @@ to mark the option as valid.   If you forget to do this, SWIG will terminate wit
 unrecognized command line option error.
 </p>
 
-<H3><a name="Extending_nn35">38.10.4 Configuration and preprocessing</a></H3>
+<H3><a name="Extending_nn35">39.10.4 Configuration and preprocessing</a></H3>
 
 
 <p>
@@ -2692,7 +2692,7 @@ an implementation file <tt>python.cxx</tt> and a configuration file
 <tt>python.swg</tt>.
 </p>
 
-<H3><a name="Extending_nn36">38.10.5 Entry point to code generation</a></H3>
+<H3><a name="Extending_nn36">39.10.5 Entry point to code generation</a></H3>
 
 
 <p>
@@ -2750,7 +2750,7 @@ int Python::top(Node *n) {
 </pre>
 </div>
 
-<H3><a name="Extending_nn37">38.10.6 Module I/O and wrapper skeleton</a></H3>
+<H3><a name="Extending_nn37">39.10.6 Module I/O and wrapper skeleton</a></H3>
 
 
 <!-- please report bugs in this section to mgossage -->
@@ -2898,7 +2898,7 @@ functionWrapper   : void Shape_y_set(Shape *self, double y)
 </pre>
 </div>
 
-<H3><a name="Extending_nn38">38.10.7 Low-level code generators</a></H3>
+<H3><a name="Extending_nn38">39.10.7 Low-level code generators</a></H3>
 
 
 <!-- please report bugs in this section to mgossage -->
@@ -3052,7 +3052,7 @@ but without the typemaps, there is still work to do.
 </p>
 
 
-<H3><a name="Extending_configuration_files">38.10.8 Configuration files</a></H3>
+<H3><a name="Extending_configuration_files">39.10.8 Configuration files</a></H3>
 
 
 <!-- please report bugs in this section to ttn -->
@@ -3196,7 +3196,7 @@ politely displays the ignoring language message.
 </dl>
 
 
-<H3><a name="Extending_nn40">38.10.9 Runtime support</a></H3>
+<H3><a name="Extending_nn40">39.10.9 Runtime support</a></H3>
 
 
 <p>
@@ -3205,7 +3205,7 @@ Discuss the kinds of functions typically needed for SWIG runtime support (e.g.
 the SWIG files that implement those functions.
 </p>
 
-<H3><a name="Extending_nn41">38.10.10 Standard library files</a></H3>
+<H3><a name="Extending_nn41">39.10.10 Standard library files</a></H3>
 
 
 <p>
@@ -3224,7 +3224,7 @@ The following are the minimum that are usually supported:
 Please copy these and modify for any new language.
 </p>
 
-<H3><a name="Extending_nn42">38.10.11 User examples</a></H3>
+<H3><a name="Extending_nn42">39.10.11 User examples</a></H3>
 
 
 <p>
@@ -3253,7 +3253,7 @@ during this process, see the section on <a href="#Extending_configuration_files"
 files</a>.
 </p>
 
-<H3><a name="Extending_test_suite">38.10.12 Test driven development and the test-suite</a></H3>
+<H3><a name="Extending_test_suite">39.10.12 Test driven development and the test-suite</a></H3>
 
 
 <p>
@@ -3312,7 +3312,7 @@ It is therefore essential that the runtime tests are written in a manner that di
 but error/exception out with an error message on stderr on failure.
 </p>
 
-<H4><a name="Extending_running_test_suite">38.10.12.1 Running the test-suite</a></H4>
+<H4><a name="Extending_running_test_suite">39.10.12.1 Running the test-suite</a></H4>
 
 
 <p>
@@ -3504,7 +3504,7 @@ It can be run in the same way as the other language test-suites, replacing [lang
 The test cases used and the way it works is described in <tt>Examples/test-suite/errors/Makefile.in</tt>.
 </p>
 
-<H3><a name="Extending_nn43">38.10.13 Documentation</a></H3>
+<H3><a name="Extending_nn43">39.10.13 Documentation</a></H3>
 
 
 <p>
@@ -3536,7 +3536,7 @@ Some topics that you'll want to be sure to address include:
      if available.
 </ul>
 
-<H3><a name="Extending_coding_style_guidelines">38.10.14 Coding style guidelines</a></H3>
+<H3><a name="Extending_coding_style_guidelines">39.10.14 Coding style guidelines</a></H3>
 
 
 <p>
@@ -3561,7 +3561,7 @@ should be avoided as unlike the SWIG developers, users will never have consisten
 </p>
 
 
-<H3><a name="Extending_language_status">38.10.15 Target language status</a></H3>
+<H3><a name="Extending_language_status">39.10.15 Target language status</a></H3>
 
 
 <p>
@@ -3570,7 +3570,7 @@ the <a href="Introduction.html#Introduction_target_languages">Target language in
 This section provides more details on how this status is given.
 </p>
 
-<H4><a name="Extending_supported_status">38.10.15.1 Supported status</a></H4>
+<H4><a name="Extending_supported_status">39.10.15.1 Supported status</a></H4>
 
 
 <p>
@@ -3617,7 +3617,7 @@ A target language is given the 'Supported' status when
 </li>
 </ul>
 
-<H4><a name="Extending_experimental_status">38.10.15.2 Experimental status</a></H4>
+<H4><a name="Extending_experimental_status">39.10.15.2 Experimental status</a></H4>
 
 
 <p>
@@ -3682,7 +3682,7 @@ Some minimum requirements and notes about languages with the 'Experimental' stat
 </li>
 </ul>
 
-<H3><a name="Extending_prerequisites">38.10.16 Prerequisites for adding a new language module to the SWIG distribution</a></H3>
+<H3><a name="Extending_prerequisites">39.10.16 Prerequisites for adding a new language module to the SWIG distribution</a></H3>
 
 
 <p>
@@ -3746,7 +3746,7 @@ the existing tests.
 </p>
 
 
-<H2><a name="Extending_debugging_options">38.11 Debugging Options</a></H2>
+<H2><a name="Extending_debugging_options">39.11 Debugging Options</a></H2>
 
 
 <p>
@@ -3773,7 +3773,7 @@ There are various command line options which can aid debugging a SWIG interface
 The complete list of command line options for SWIG are available by running <tt>swig -help</tt>.
 </p>
 
-<H2><a name="Extending_nn46">38.12 Guide to parse tree nodes</a></H2>
+<H2><a name="Extending_nn46">39.12 Guide to parse tree nodes</a></H2>
 
 
 <p>
@@ -4181,7 +4181,7 @@ extern "X" { ... } declaration.
 </pre>
 </div>
 
-<H2><a name="Extending_further_info">38.13 Further Development Information</a></H2>
+<H2><a name="Extending_further_info">39.13 Further Development Information</a></H2>
 
 
 <p>
diff --git a/Doc/Manual/Go.html b/Doc/Manual/Go.html
index 8523f74aa..4a60e45e0 100644
--- a/Doc/Manual/Go.html
+++ b/Doc/Manual/Go.html
@@ -6,7 +6,7 @@
 <meta http-equiv="content-type" content="text/html; charset=UTF-8">
 </head>
 <body bgcolor="#FFFFFF">
-<H1><a name="Go">23 SWIG and Go</a></H1>
+<H1><a name="Go">24 SWIG and Go</a></H1>
 <!-- INDEX -->
 <div class="sectiontoc">
 <ul>
@@ -57,7 +57,7 @@ the Go programming language
 see <a href="http://golang.org/">golang.org</a>.
 </p>
 
-<H2><a name="Go_overview">23.1 Overview</a></H2>
+<H2><a name="Go_overview">24.1 Overview</a></H2>
 
 
 <p>
@@ -86,7 +86,7 @@ type-safe as well.  In case of type issues the build will fail and hence SWIG's
 are not used.
 </p>
 
-<H2><a name="Go_examples">23.2 Examples</a></H2>
+<H2><a name="Go_examples">24.2 Examples</a></H2>
 
 
 <p>
@@ -101,7 +101,7 @@ SWIG interface file extension for backwards compatibility with Go 1.
 </p>
 
 
-<H2><a name="Go_running_swig">23.3 Running SWIG with Go</a></H2>
+<H2><a name="Go_running_swig">24.3 Running SWIG with Go</a></H2>
 
 
 <p>
@@ -181,7 +181,7 @@ sequence for this approach would look like this:
 </pre></div>
 
 
-<H3><a name="Go_commandline">23.3.1 Go-specific Commandline Options</a></H3>
+<H3><a name="Go_commandline">24.3.1 Go-specific Commandline Options</a></H3>
 
 
 <p>
@@ -264,7 +264,7 @@ swig -go -help
 </table>
 
 
-<H3><a name="Go_outputs">23.3.2 Generated Wrapper Files</a></H3>
+<H3><a name="Go_outputs">24.3.2 Generated Wrapper Files</a></H3>
 
 
 <p>There are two different approaches to generating wrapper files,
@@ -308,7 +308,7 @@ combined with the compiled MODULE.go using go tool pack.
 </ul>
 
 
-<H2><a name="Go_basic_tour">23.4 A tour of basic C/C++ wrapping</a></H2>
+<H2><a name="Go_basic_tour">24.4 A tour of basic C/C++ wrapping</a></H2>
 
 
 <p>
@@ -318,7 +318,7 @@ modifications have to occur.  This section briefly covers the
 essential aspects of this wrapping.
 </p>
 
-<H3><a name="Go_package">23.4.1 Go Package Name</a></H3>
+<H3><a name="Go_package">24.4.1 Go Package Name</a></H3>
 
 
 <p>
@@ -328,7 +328,7 @@ directive.  You may override this by using SWIG's <tt>-package</tt>
 command line option.
 </p>
 
-<H3><a name="Go_names">23.4.2 Go Names</a></H3>
+<H3><a name="Go_names">24.4.2 Go Names</a></H3>
 
 
 <p>
@@ -360,7 +360,7 @@ followed by that name, and the destructor will be
 named <tt>Delete</tt> followed by that name.
 </p>
 
-<H3><a name="Go_constants">23.4.3 Go Constants</a></H3>
+<H3><a name="Go_constants">24.4.3 Go Constants</a></H3>
 
 
 <p>
@@ -368,7 +368,7 @@ C/C++ constants created via <tt>#define</tt> or the <tt>%constant</tt>
 directive become Go constants, declared with a <tt>const</tt>
 declaration.
 
-<H3><a name="Go_enumerations">23.4.4 Go Enumerations</a></H3>
+<H3><a name="Go_enumerations">24.4.4 Go Enumerations</a></H3>
 
 
 <p>
@@ -378,7 +378,7 @@ usual).  The values of the enumeration will become variables in Go;
 code should avoid modifying those variables.
 </p>
 
-<H3><a name="Go_classes">23.4.5 Go Classes</a></H3>
+<H3><a name="Go_classes">24.4.5 Go Classes</a></H3>
 
 
 <p>
@@ -456,7 +456,7 @@ returns a go interface.  If the returned pointer can be null, you can check
 for this by calling the Swigcptr() method.
 </p>
 
-<H4><a name="Go_class_memory">23.4.5.1 Go Class Memory Management</a></H4>
+<H4><a name="Go_class_memory">24.4.5.1 Go Class Memory Management</a></H4>
 
 
 <p>
@@ -578,7 +578,7 @@ func (o *GoClassName) Close() {
 </pre>
 </div>
 
-<H4><a name="Go_class_inheritance">23.4.5.2 Go Class Inheritance</a></H4>
+<H4><a name="Go_class_inheritance">24.4.5.2 Go Class Inheritance</a></H4>
 
 
 <p>
@@ -590,7 +590,7 @@ Doing the reverse will require an explicit type assertion, which will
 be checked dynamically.
 </p>
 
-<H3><a name="Go_templates">23.4.6 Go Templates</a></H3>
+<H3><a name="Go_templates">24.4.6 Go Templates</a></H3>
 
 
 <p>
@@ -599,7 +599,7 @@ wrappers for a particular template instantation.  To do this, use
 the <tt>%template</tt> directive.
 
 
-<H3><a name="Go_director_classes">23.4.7 Go Director Classes</a></H3>
+<H3><a name="Go_director_classes">24.4.7 Go Director Classes</a></H3>
 
 
 <p>
@@ -617,7 +617,7 @@ completely to avoid common pitfalls with directors in Go.
 </p>
 
 
-<H4><a name="Go_director_example_cpp_code">23.4.7.1 Example C++ code</a></H4>
+<H4><a name="Go_director_example_cpp_code">24.4.7.1 Example C++ code</a></H4>
 
 
 <p>
@@ -689,7 +689,7 @@ be found in <a href="#Go_director_foobargo_class">the end of the guide</a>.
 </p>
 
 
-<H4><a name="Go_director_enable">23.4.7.2 Enable director feature</a></H4>
+<H4><a name="Go_director_enable">24.4.7.2 Enable director feature</a></H4>
 
 
 <p>
@@ -724,7 +724,7 @@ documentation on directors.
 </p>
 
 
-<H4><a name="Go_director_ctor_dtor">23.4.7.3 Constructor and destructor</a></H4>
+<H4><a name="Go_director_ctor_dtor">24.4.7.3 Constructor and destructor</a></H4>
 
 
 <p>
@@ -777,7 +777,7 @@ embedding</a>.
 </p>
 
 
-<H4><a name="Go_director_overriding">23.4.7.4 Override virtual methods</a></H4>
+<H4><a name="Go_director_overriding">24.4.7.4 Override virtual methods</a></H4>
 
 
 <p>
@@ -843,7 +843,7 @@ the Go methods.
 </p>
 
 
-<H4><a name="Go_director_base_methods">23.4.7.5 Call base methods</a></H4>
+<H4><a name="Go_director_base_methods">24.4.7.5 Call base methods</a></H4>
 
 
 <p>
@@ -880,7 +880,7 @@ be found in <a href="#Go_director_foobargo_class">the end of the guide</a>.
 </p>
 
 
-<H4><a name="Go_director_subclass">23.4.7.6 Subclass via embedding</a></H4>
+<H4><a name="Go_director_subclass">24.4.7.6 Subclass via embedding</a></H4>
 
 
 <p>
@@ -948,7 +948,7 @@ class.
 </p>
 
 
-<H4><a name="Go_director_finalizer">23.4.7.7 Memory management with runtime.SetFinalizer</a></H4>
+<H4><a name="Go_director_finalizer">24.4.7.7 Memory management with runtime.SetFinalizer</a></H4>
 
 
 <p>
@@ -1013,7 +1013,7 @@ before using <tt>runtime.SetFinalizer</tt> to know all of its gotchas.
 </p>
 
 
-<H4><a name="Go_director_foobargo_class">23.4.7.8 Complete FooBarGo example class</a></H4>
+<H4><a name="Go_director_foobargo_class">24.4.7.8 Complete FooBarGo example class</a></H4>
 
 
 <p>
@@ -1142,7 +1142,7 @@ SWIG/Examples/go/director/</a>.
 </p>
 
 
-<H3><a name="Go_primitive_type_mappings">23.4.8 Default Go primitive type mappings</a></H3>
+<H3><a name="Go_primitive_type_mappings">24.4.8 Default Go primitive type mappings</a></H3>
 
 
 <p>
@@ -1249,7 +1249,7 @@ that typemap, or add new values, to control how C/C++ types are mapped
 into Go types.
 </p>
 
-<H3><a name="Go_output_arguments">23.4.9 Output arguments</a></H3>
+<H3><a name="Go_output_arguments">24.4.9 Output arguments</a></H3>
 
 
 <p>Because of limitations in the way output arguments are processed in swig,
@@ -1302,7 +1302,7 @@ void f(char *output);
 </pre>
 </div>
 
-<H3><a name="Go_adding_additional_code">23.4.10 Adding additional go code</a></H3>
+<H3><a name="Go_adding_additional_code">24.4.10 Adding additional go code</a></H3>
 
 
 <p>Often the APIs generated by swig are not very natural in go, especially if
@@ -1397,7 +1397,7 @@ func bar() {
 </pre>
 </div>
 
-<H3><a name="Go_typemaps">23.4.11 Go typemaps</a></H3>
+<H3><a name="Go_typemaps">24.4.11 Go typemaps</a></H3>
 
 
 <p>
diff --git a/Doc/Manual/Guile.html b/Doc/Manual/Guile.html
index 6acdd2dc3..31d822599 100644
--- a/Doc/Manual/Guile.html
+++ b/Doc/Manual/Guile.html
@@ -8,7 +8,7 @@
 
 <body bgcolor="#ffffff">
 
-<H1><a name="Guile">24 SWIG and Guile</a></H1>
+<H1><a name="Guile">25 SWIG and Guile</a></H1>
 <!-- INDEX -->
 <div class="sectiontoc">
 <ul>
@@ -48,7 +48,7 @@
 <p>
 This section details guile-specific support in SWIG.
 
-<H2><a name="Guile_nn1">24.1 Supported Guile Versions</a></H2>
+<H2><a name="Guile_nn1">25.1 Supported Guile Versions</a></H2>
 
 
 <p>
@@ -62,7 +62,7 @@ improved performance. This is currently not tested with swig
 so your mileage may vary. To be safe set environment variable
 GUILE_AUTO_COMPILE to 0 when using swig generated guile code.
 
-<H2><a name="Guile_nn2">24.2 Meaning of "Module"</a></H2>
+<H2><a name="Guile_nn2">25.2 Meaning of "Module"</a></H2>
 
 
 <p>
@@ -70,7 +70,7 @@ There are three different concepts of "module" involved, defined
 separately for SWIG, Guile, and Libtool.  To avoid horrible confusion,
 we explicitly prefix the context, e.g., "guile-module".
 
-<H2><a name="Guile_nn3">24.3 Old GH Guile API</a></H2>
+<H2><a name="Guile_nn3">25.3 Old GH Guile API</a></H2>
 
 
 <p>Guile 1.8 and older could be interfaced using two different api's, the SCM
@@ -81,7 +81,7 @@ or the GH API. The GH interface to guile is deprecated.  Read more about why in
 version of SWIG that can still generate guile GH wrapper code is 2.0.9. Please
 use that version if you really need the GH wrapper code.
 
-<H2><a name="Guile_nn4">24.4 Linkage</a></H2>
+<H2><a name="Guile_nn4">25.4 Linkage</a></H2>
 
 
 <p>
@@ -89,7 +89,7 @@ Guile support is complicated by a lack of user community cohesiveness,
 which manifests in multiple shared-library usage conventions.  A set of
 policies implementing a usage convention is called a <b>linkage</b>.
 
-<H3><a name="Guile_nn5">24.4.1 Simple Linkage</a></H3>
+<H3><a name="Guile_nn5">25.4.1 Simple Linkage</a></H3>
 
 
 <p>
@@ -194,7 +194,7 @@ placed between the <code>define-module</code> form and the
 <code>SWIG_init</code> via a preprocessor define to avoid symbol
 clashes. For this case, however, passive linkage is available.
 
-<H3><a name="Guile_nn6">24.4.2 Passive Linkage</a></H3>
+<H3><a name="Guile_nn6">25.4.2 Passive Linkage</a></H3>
 
 
 <p>Passive linkage is just like simple linkage, but it generates an
@@ -204,7 +204,7 @@ package name (see below).
 <p>You should use passive linkage rather than simple linkage when you
 are using multiple modules.
 
-<H3><a name="Guile_nn7">24.4.3 Native Guile Module Linkage</a></H3>
+<H3><a name="Guile_nn7">25.4.3 Native Guile Module Linkage</a></H3>
 
 
 <p>SWIG can also generate wrapper code that does all the Guile module
@@ -245,7 +245,7 @@ Newer Guile versions have a shorthand procedure for this:
 </div>
 </ul>
 
-<H3><a name="Guile_nn8">24.4.4 Old Auto-Loading Guile Module Linkage</a></H3>
+<H3><a name="Guile_nn8">25.4.4 Old Auto-Loading Guile Module Linkage</a></H3>
 
 
 <p>Guile used to support an autoloading facility for object-code
@@ -271,7 +271,7 @@ option, SWIG generates an exported module initialization function with
 an appropriate name. 
 
 
-<H3><a name="Guile_nn9">24.4.5 Hobbit4D Linkage</a></H3>
+<H3><a name="Guile_nn9">25.4.5 Hobbit4D Linkage</a></H3>
 
 
 <p>
@@ -296,7 +296,7 @@ my/lib/libfoo.so.X.Y.Z and friends.  This scheme is still very
 experimental; the (hobbit4d link) conventions are not well understood.
 </p>
 
-<H2><a name="Guile_nn10">24.5 Underscore Folding</a></H2>
+<H2><a name="Guile_nn10">25.5 Underscore Folding</a></H2>
 
 
 <p>
@@ -308,7 +308,7 @@ complained so far.
 <code>%rename</code> to specify the Guile name of the wrapped
 functions and variables (see CHANGES).
 
-<H2><a name="Guile_nn11">24.6 Typemaps</a></H2>
+<H2><a name="Guile_nn11">25.6 Typemaps</a></H2>
 
 
 <p>
@@ -400,7 +400,7 @@ constant will appear as a scheme variable. See
 <a href="Customization.html#Customization_features">Features and the %feature directive</a>
 for info on how to apply the %feature.</p>
 
-<H2><a name="Guile_nn12">24.7 Representation of pointers as smobs</a></H2>
+<H2><a name="Guile_nn12">25.7 Representation of pointers as smobs</a></H2>
 
 
 <p>
@@ -421,7 +421,7 @@ representing the expected pointer type.  See also
 If the Scheme object passed was not a SWIG smob representing a compatible
 pointer, a <code>wrong-type-arg</code> exception is raised.
 
-<H3><a name="Guile_nn14">24.7.1 Smobs</a></H3>
+<H3><a name="Guile_nn14">25.7.1 Smobs</a></H3>
 
 
 <p>
@@ -440,7 +440,7 @@ structure describing this type.  If a generated GOOPS module has been loaded, sm
 the corresponding GOOPS class.</p>
 
 
-<H3><a name="Guile_nn15">24.7.2 Garbage Collection</a></H3>
+<H3><a name="Guile_nn15">25.7.2 Garbage Collection</a></H3>
 
 
 <p>Garbage collection is a feature of Guile since version 1.6. As SWIG now requires Guile &gt; 1.8,
@@ -454,14 +454,14 @@ is exactly like described in <a href="Customization.html#Customization_ownership
 Object ownership and %newobject</a> in the SWIG manual.  All typemaps use an $owner var, and
 the guile module replaces $owner with 0 or 1 depending on feature:new.</p>
 
-<H2><a name="Guile_nn16">24.8 Native Guile pointers</a></H2>
+<H2><a name="Guile_nn16">25.8 Native Guile pointers</a></H2>
 
 
 <p>
 In addition to SWIG smob pointers, <a href="https://www.gnu.org/software/guile/manual/html_node/Foreign-Pointers.html">Guile's native pointer type</a> are accepted as arguments to wrapped SWIG functions. This can be useful for passing <a href="https://www.gnu.org/software/guile/manual/html_node/Void-Pointers-and-Byte-Access.html#">pointers to bytevector data</a> to wrapped functions.
 </p>
 
-<H2><a name="Guile_nn17">24.9 Exception Handling</a></H2>
+<H2><a name="Guile_nn17">25.9 Exception Handling</a></H2>
 
 
 <p>
@@ -487,7 +487,7 @@ mapping:
 The default when not specified here is to use "swig-error".
 See Lib/exception.i for details.
 
-<H2><a name="Guile_nn18">24.10 Procedure documentation</a></H2>
+<H2><a name="Guile_nn18">25.10 Procedure documentation</a></H2>
 
 
 <p>If invoked with the command-line option <code>-procdoc
@@ -522,7 +522,7 @@ like this:
 typemap argument <code>doc</code>. See <code>Lib/guile/typemaps.i</code> for
 details.
 
-<H2><a name="Guile_nn19">24.11 Procedures with setters</a></H2>
+<H2><a name="Guile_nn19">25.11 Procedures with setters</a></H2>
 
 
 <p>For global variables, SWIG creates a single wrapper procedure
@@ -550,7 +550,7 @@ struct members, the procedures <code>(<var>struct</var>-<var>member</var>-get
 pointer)</code> and <code>(<var>struct-member</var>-set pointer
 value)</code> are <em>not</em> generated.
 
-<H2><a name="Guile_nn20">24.12 GOOPS Proxy Classes</a></H2>
+<H2><a name="Guile_nn20">25.12 GOOPS Proxy Classes</a></H2>
 
 
 <p>SWIG can also generate classes and generic functions for use with
@@ -696,7 +696,7 @@ Notice that &lt;Foo&gt; is used before it is defined.  The fix is to just put th
 <code>%import "foo.h"</code> before the <code>%inline</code> block.
 </p>
 
-<H3><a name="Guile_nn21">24.12.1 Naming Issues</a></H3>
+<H3><a name="Guile_nn21">25.12.1 Naming Issues</a></H3>
 
 
 <p>As you can see in the example above, there are potential naming conflicts.  The default exported
@@ -733,7 +733,7 @@ guile-modules.  For example,</p>
 (use-modules ((Test) #:renamer (symbol-prefix-proc 'goops:)))
 </pre></div>
 
-<H3><a name="Guile_nn22">24.12.2 Linking</a></H3>
+<H3><a name="Guile_nn22">25.12.2 Linking</a></H3>
 
 
 <p>The guile-modules generated above all need to be linked together.  GOOPS support requires
diff --git a/Doc/Manual/Java.html b/Doc/Manual/Java.html
index 77a81995e..4c7b6d058 100644
--- a/Doc/Manual/Java.html
+++ b/Doc/Manual/Java.html
@@ -6,7 +6,7 @@
 <meta http-equiv="content-type" content="text/html; charset=UTF-8">
 </head>
 <body bgcolor="#FFFFFF">
-<H1><a name="Java">25 SWIG and Java</a></H1>
+<H1><a name="Java">26 SWIG and Java</a></H1>
 <!-- INDEX -->
 <div class="sectiontoc">
 <ul>
@@ -167,7 +167,7 @@ It covers most SWIG features, but certain low-level details are covered in less
 </p>
 
 
-<H2><a name="Java_overview">25.1 Overview</a></H2>
+<H2><a name="Java_overview">26.1 Overview</a></H2>
 
 
 <p>
@@ -202,7 +202,7 @@ Various customisation tips and techniques using SWIG directives are covered.
 The latter sections cover the advanced techniques of using typemaps for complete control of the wrapping process.
 </p>
 
-<H2><a name="Java_preliminaries">25.2 Preliminaries</a></H2>
+<H2><a name="Java_preliminaries">26.2 Preliminaries</a></H2>
 
 
 <p>
@@ -222,7 +222,7 @@ This is the commonly used method to load JNI code so your system will more than
 Android uses Java JNI and also works with SWIG. Please read the <a href="Android.html#Android">Android chapter</a> in conjunction with this one if you are targeting Android.
 </p>
 
-<H3><a name="Java_running_swig">25.2.1 Running SWIG</a></H3>
+<H3><a name="Java_running_swig">26.2.1 Running SWIG</a></H3>
 
 
 <p>
@@ -281,7 +281,7 @@ The following sections have further practical examples and details on how you mi
 compiling and using the generated files.
 </p>
 
-<H3><a name="Java_commandline">25.2.2 Additional Commandline Options</a></H3>
+<H3><a name="Java_commandline">26.2.2 Additional Commandline Options</a></H3>
 
 
 <p>
@@ -318,7 +318,7 @@ swig -java -help
 Their use will become clearer by the time you have finished reading this section on SWIG and Java.
 </p>
 
-<H3><a name="Java_getting_right_headers">25.2.3 Getting the right header files</a></H3>
+<H3><a name="Java_getting_right_headers">26.2.3 Getting the right header files</a></H3>
 
 
 <p>
@@ -333,7 +333,7 @@ They are usually in directories like this:</p>
 <p>
 The exact location may vary on your machine, but the above locations are typical. </p>
 
-<H3><a name="Java_compiling_dynamic">25.2.4 Compiling a dynamic module</a></H3>
+<H3><a name="Java_compiling_dynamic">26.2.4 Compiling a dynamic module</a></H3>
 
 
 <p>
@@ -368,7 +368,7 @@ The name of the shared library output file is important.
 If the name of your SWIG module is "<tt>example</tt>", the name of the corresponding shared library file should be "<tt>libexample.so</tt>" (or equivalent depending on your machine, see <a href="#Java_dynamic_linking_problems">Dynamic linking problems</a> for more information). 
 The name of the module is specified using the <tt>%module</tt> directive or <tt>-module</tt> command line option.</p>
 
-<H3><a name="Java_using_module">25.2.5 Using your module</a></H3>
+<H3><a name="Java_using_module">26.2.5 Using your module</a></H3>
 
 
 <p>
@@ -403,7 +403,7 @@ $
 If it doesn't work have a look at the following section which discusses problems loading the shared library.
 </p>
 
-<H3><a name="Java_dynamic_linking_problems">25.2.6 Dynamic linking problems</a></H3>
+<H3><a name="Java_dynamic_linking_problems">26.2.6 Dynamic linking problems</a></H3>
 
 
 <p>
@@ -490,7 +490,7 @@ The following section also contains some C++ specific linking problems and solut
 </p>
 
 
-<H3><a name="Java_compilation_problems_cpp">25.2.7 Compilation problems and compiling with C++</a></H3>
+<H3><a name="Java_compilation_problems_cpp">26.2.7 Compilation problems and compiling with C++</a></H3>
 
 
 <p>
@@ -542,7 +542,7 @@ Finally make sure the version of JDK header files matches the version of Java th
 </p>
 
 
-<H3><a name="Java_building_windows">25.2.8 Building on Windows</a></H3>
+<H3><a name="Java_building_windows">26.2.8 Building on Windows</a></H3>
 
 
 <p>
@@ -551,7 +551,7 @@ You will want to produce a DLL that can be loaded by the Java Virtual Machine.
 This section covers the process of using SWIG with Microsoft Visual C++ 6 although the procedure may be similar with other compilers.  
 In order for everything to work, you will need to have a JDK installed on your machine in order to read the JNI header files.</p>
 
-<H4><a name="Java_visual_studio">25.2.8.1 Running SWIG from Visual Studio</a></H4>
+<H4><a name="Java_visual_studio">26.2.8.1 Running SWIG from Visual Studio</a></H4>
 
 
 <p>
@@ -590,7 +590,7 @@ To run the native code in the DLL (example.dll), make sure that it is in your pa
 If the library fails to load have a look at <a href="#Java_dynamic_linking_problems">Dynamic linking problems</a>.
 </p>
 
-<H4><a name="Java_nmake">25.2.8.2 Using NMAKE</a></H4>
+<H4><a name="Java_nmake">26.2.8.2 Using NMAKE</a></H4>
 
 
 <p>
@@ -649,7 +649,7 @@ Of course you may want to make changes for it to work for C++ by adding in the -
 </p>
 
 
-<H2><a name="Java_basic_tour">25.3 A tour of basic C/C++ wrapping</a></H2>
+<H2><a name="Java_basic_tour">26.3 A tour of basic C/C++ wrapping</a></H2>
 
 
 <p>
@@ -659,7 +659,7 @@ variables are wrapped with JavaBean type getters and setters and so forth.
 This section briefly covers the essential aspects of this wrapping.
 </p>
 
-<H3><a name="Java_module_packages_classes">25.3.1 Modules, packages and generated Java classes</a></H3>
+<H3><a name="Java_module_packages_classes">26.3.1 Modules, packages and generated Java classes</a></H3>
 
 
 <p>
@@ -695,7 +695,7 @@ swig -java -package com.bloggs.swig -outdir com/bloggs/swig example.i
 SWIG won't create the directory, so make sure it exists beforehand.
 </p>
 
-<H3><a name="Java_functions">25.3.2 Functions</a></H3>
+<H3><a name="Java_functions">26.3.2 Functions</a></H3>
 
 
 <p>
@@ -729,7 +729,7 @@ System.out.println(example.fact(4));
 </pre></div>
 
 
-<H3><a name="Java_global_variables">25.3.3 Global variables</a></H3>
+<H3><a name="Java_global_variables">26.3.3 Global variables</a></H3>
 
 
 <p>
@@ -816,7 +816,7 @@ extern char *path;      // Read-only (due to %immutable)
 </div>
 
 
-<H3><a name="Java_constants">25.3.4 Constants</a></H3>
+<H3><a name="Java_constants">26.3.4 Constants</a></H3>
 
 
 <p>
@@ -956,7 +956,7 @@ Or if you decide this practice isn't so bad and your own class implements <tt>ex
 </p>
 
 
-<H3><a name="Java_enumerations">25.3.5 Enumerations</a></H3>
+<H3><a name="Java_enumerations">26.3.5 Enumerations</a></H3>
 
 
 <p>
@@ -970,7 +970,7 @@ The final two approaches use simple integers for each enum item.
 Before looking at the various approaches for wrapping named C/C++ enums, anonymous enums are considered.
 </p>
 
-<H4><a name="Java_anonymous_enums">25.3.5.1 Anonymous enums</a></H4>
+<H4><a name="Java_anonymous_enums">26.3.5.1 Anonymous enums</a></H4>
 
 
 <p>
@@ -1033,7 +1033,7 @@ As in the case of constants, you can access them through either the module class
 </p>
 
 
-<H4><a name="Java_typesafe_enums">25.3.5.2 Typesafe enums</a></H4>
+<H4><a name="Java_typesafe_enums">26.3.5.2 Typesafe enums</a></H4>
 
 
 <p>
@@ -1127,7 +1127,7 @@ When upgrading to JDK 1.5 or later, proper Java enums could be used instead, wit
 The following section details proper Java enum generation.
 </p>
 
-<H4><a name="Java_proper_enums">25.3.5.3 Proper Java enums</a></H4>
+<H4><a name="Java_proper_enums">26.3.5.3 Proper Java enums</a></H4>
 
 
 <p>
@@ -1180,7 +1180,7 @@ The additional support methods need not be generated if none of the enum items h
 <a href="#Java_simpler_enum_classes">Simpler Java enums for enums without initializers</a> section.
 </p>
 
-<H4><a name="Java_typeunsafe_enums">25.3.5.4 Type unsafe enums</a></H4>
+<H4><a name="Java_typeunsafe_enums">26.3.5.4 Type unsafe enums</a></H4>
 
 
 <p>
@@ -1228,7 +1228,7 @@ Note that unlike typesafe enums, this approach requires users to mostly use diff
 Thus the upgrade path to proper enums provided in JDK 1.5 is more painful.
 </p>
 
-<H4><a name="Java_simple_enums">25.3.5.5 Simple enums</a></H4>
+<H4><a name="Java_simple_enums">26.3.5.5 Simple enums</a></H4>
 
 
 <p>
@@ -1247,7 +1247,7 @@ SWIG-1.3.21 and earlier versions wrapped all enums using this approach.
 The type unsafe approach is preferable to this one and this simple approach is only included for backwards compatibility with these earlier versions of SWIG.
 </p>
 
-<H3><a name="Java_pointers">25.3.6 Pointers</a></H3>
+<H3><a name="Java_pointers">26.3.6 Pointers</a></H3>
 
 
 <p>
@@ -1335,7 +1335,7 @@ C-style cast may return a bogus result whereas as the C++-style cast will return
 a NULL pointer if the conversion can't be performed.
 </p>
 
-<H3><a name="Java_structures">25.3.7 Structures</a></H3>
+<H3><a name="Java_structures">26.3.7 Structures</a></H3>
 
 
 <p>
@@ -1503,7 +1503,7 @@ x.setA(3);          // Modify x.a - this is the same as b.f.a
 </div>
 
 
-<H3><a name="Java_classes">25.3.8 C++ classes</a></H3>
+<H3><a name="Java_classes">26.3.8 C++ classes</a></H3>
 
 
 <p>
@@ -1566,7 +1566,7 @@ int bar = Spam.getBar();
 </div>
 
 
-<H3><a name="Java_inheritance">25.3.9 C++ inheritance</a></H3>
+<H3><a name="Java_inheritance">26.3.9 C++ inheritance</a></H3>
 
 
 <p>
@@ -1627,7 +1627,7 @@ Note that Java does not support multiple inheritance so any multiple inheritance
 A warning is given when multiple inheritance is detected and only the first base class is used. 
 </p>
 
-<H3><a name="Java_pointers_refs_arrays">25.3.10 Pointers, references, arrays and pass by value</a></H3>
+<H3><a name="Java_pointers_refs_arrays">26.3.10 Pointers, references, arrays and pass by value</a></H3>
 
 
 <p>
@@ -1682,7 +1682,7 @@ to hold the result and a pointer is returned (Java will release this memory
 when the returned object's finalizer is run by the garbage collector).
 </p>
 
-<H4><a name="Java_null_pointers">25.3.10.1 Null pointers</a></H4>
+<H4><a name="Java_null_pointers">26.3.10.1 Null pointers</a></H4>
 
 
 <p>
@@ -1706,7 +1706,7 @@ For <tt>spam1</tt> and <tt>spam4</tt> above the Java <tt>null</tt> gets translat
 The converse also occurs, that is, NULL pointers are translated into <tt>null</tt> Java objects when returned from a C/C++ function.
 </p>
 
-<H3><a name="Java_overloaded_functions">25.3.11 C++ overloaded functions</a></H3>
+<H3><a name="Java_overloaded_functions">26.3.11 C++ overloaded functions</a></H3>
 
 
 <p>
@@ -1821,7 +1821,7 @@ void spam(unsigned short);   // Ignored
 </pre>
 </div>
 
-<H3><a name="Java_default_arguments">25.3.12 C++ default arguments</a></H3>
+<H3><a name="Java_default_arguments">26.3.12 C++ default arguments</a></H3>
 
 
 <p>
@@ -1864,7 +1864,7 @@ Further details on default arguments and how to restore this approach are given
 </p>
 
 
-<H3><a name="Java_namespaces">25.3.13 C++ namespaces</a></H3>
+<H3><a name="Java_namespaces">26.3.13 C++ namespaces</a></H3>
 
 
 <p>
@@ -1954,7 +1954,7 @@ If the resulting use of the nspace feature and hence packages results in a proxy
 you will need to open up the visibility for the pointer constructor and <tt>getCPtr</tt> method from the default 'protected' to 'public' with the <tt>SWIG_JAVABODY_PROXY</tt> macro. See <a href="#Java_code_typemaps">Java code typemaps</a>.
 </p>
 
-<H3><a name="Java_templates">25.3.14 C++ templates</a></H3>
+<H3><a name="Java_templates">26.3.14 C++ templates</a></H3>
 
 
 <p>
@@ -2003,10 +2003,10 @@ Obviously, there is more to template wrapping than shown in this example.
 More details can be found in the <a href="SWIGPlus.html#SWIGPlus">SWIG and C++</a> chapter.   
 </p>
 
-<H3><a name="Java_smart_pointers">25.3.15 C++ Smart Pointers</a></H3>
+<H3><a name="Java_smart_pointers">26.3.15 C++ Smart Pointers</a></H3>
 
 
-<H4><a name="Java_smart_pointers_shared_ptr">25.3.15.1 The shared_ptr Smart Pointer</a></H4>
+<H4><a name="Java_smart_pointers_shared_ptr">26.3.15.1 The shared_ptr Smart Pointer</a></H4>
 
 
 <p>
@@ -2017,7 +2017,7 @@ in the <a href="Library.html#Library_std_shared_ptr">shared_ptr smart pointer</a
 </p>
 
 
-<H4><a name="Java_smart_pointers_generic">25.3.15.2 Generic Smart Pointers</a></H4>
+<H4><a name="Java_smart_pointers_generic">26.3.15.2 Generic Smart Pointers</a></H4>
 
 
 <p>
@@ -2101,7 +2101,7 @@ Foo f = p.__deref__();               // Returns underlying Foo *
 </pre>
 </div>
 
-<H2><a name="Java_further_details">25.4 Further details on the generated Java classes</a></H2>
+<H2><a name="Java_further_details">26.4 Further details on the generated Java classes</a></H2>
 
 
 <p>
@@ -2116,7 +2116,7 @@ Finally enum classes are covered.
 First, the crucial intermediary JNI class is considered.
 </p>
 
-<H3><a name="Java_imclass">25.4.1 The intermediary JNI class</a></H3>
+<H3><a name="Java_imclass">26.4.1 The intermediary JNI class</a></H3>
 
 
 <p>
@@ -2236,7 +2236,7 @@ If <tt>name</tt> is the same as <tt>modulename</tt> then the module class name g
 from <tt>modulename</tt> to <tt>modulenameModule</tt>.
 </p>
 
-<H4><a name="Java_imclass_pragmas">25.4.1.1 The intermediary JNI class pragmas</a></H4>
+<H4><a name="Java_imclass_pragmas">26.4.1.1 The intermediary JNI class pragmas</a></H4>
 
 
 <p>
@@ -2318,7 +2318,7 @@ For example, let's change the intermediary JNI class access to just the default
 All the methods in the intermediary JNI class will then not be callable outside of the package as the method modifiers have been changed from public access to default access. This is useful if you want to prevent users calling these low level functions.
 </p>
 
-<H3><a name="Java_module_class">25.4.2 The Java module class</a></H3>
+<H3><a name="Java_module_class">26.4.2 The Java module class</a></H3>
 
 
 <p>
@@ -2349,7 +2349,7 @@ example.egg(new Foo());
 The primary reason for having the module class wrapping the calls in the intermediary JNI class is to implement static type checking. In this case only a <tt>Foo</tt> can be passed to the <tt>egg</tt> function, whereas any <tt>long</tt> can be passed to the <tt>egg</tt> function in the intermediary JNI class.
 </p>
 
-<H4><a name="Java_module_class_pragmas">25.4.2.1 The Java module class pragmas</a></H4>
+<H4><a name="Java_module_class_pragmas">26.4.2.1 The Java module class pragmas</a></H4>
 
 
 <p>
@@ -2400,7 +2400,7 @@ See <a href="#Java_imclass_pragmas">The intermediary JNI class pragmas</a> secti
 </p>
 
 
-<H3><a name="Java_proxy_classes">25.4.3 Java proxy classes</a></H3>
+<H3><a name="Java_proxy_classes">26.4.3 Java proxy classes</a></H3>
 
 
 <p>
@@ -2476,7 +2476,7 @@ int y = f.spam(5, new Foo());
 </pre>
 </div>
 
-<H4><a name="Java_memory_management">25.4.3.1 Memory management</a></H4>
+<H4><a name="Java_memory_management">26.4.3.1 Memory management</a></H4>
 
 
 <p>
@@ -2638,7 +2638,7 @@ and
 </p>
 
 
-<H4><a name="Java_inheritance_mirroring">25.4.3.2 Inheritance</a></H4>
+<H4><a name="Java_inheritance_mirroring">26.4.3.2 Inheritance</a></H4>
 
 
 <p>
@@ -2754,7 +2754,7 @@ However, true cross language polymorphism can be achieved using the <a href="#Ja
 </p>
 
 
-<H4><a name="Java_proxy_classes_gc">25.4.3.3 Proxy classes and garbage collection</a></H4>
+<H4><a name="Java_proxy_classes_gc">26.4.3.3 Proxy classes and garbage collection</a></H4>
 
 
 <p>
@@ -2837,7 +2837,7 @@ The section on <a href="#Java_typemaps">Java typemaps</a> details how to specify
 See the <a href="http://www.devx.com/Java/Article/30192">How to Handle Java Finalization's Memory-Retention Issues</a> article for alternative approaches to managing memory by avoiding finalizers altogether.
 </p>
 
-<H4><a name="Java_pgcpp">25.4.3.4 The premature garbage collection prevention parameter for proxy class marshalling</a></H4>
+<H4><a name="Java_pgcpp">26.4.3.4 The premature garbage collection prevention parameter for proxy class marshalling</a></H4>
 
 
 <p>
@@ -2959,7 +2959,7 @@ For example:
 <b>Compatibility note:</b> The generation of this additional parameter did not occur in versions prior to SWIG-1.3.30.
 </p>
 
-<H4><a name="Java_multithread_libraries">25.4.3.5 Single threaded applications and thread safety</a></H4>
+<H4><a name="Java_multithread_libraries">26.4.3.5 Single threaded applications and thread safety</a></H4>
 
 
 <p>
@@ -3047,7 +3047,7 @@ for (int i=0; i&lt;100000; i++) {
 </pre></div>
  
 
-<H3><a name="Java_type_wrapper_classes">25.4.4 Type wrapper classes</a></H3>
+<H3><a name="Java_type_wrapper_classes">26.4.4 Type wrapper classes</a></H3>
 
 
 <p>
@@ -3134,7 +3134,7 @@ public static void spam(SWIGTYPE_p_int x, SWIGTYPE_p_int y, int z) { ... }
 </div>
 
 
-<H3><a name="Java_enum_classes">25.4.5 Enum classes</a></H3>
+<H3><a name="Java_enum_classes">26.4.5 Enum classes</a></H3>
 
 
 <p>
@@ -3143,7 +3143,7 @@ The <a href="#Java_enumerations">Enumerations</a> section discussed these but om
 The following sub-sections detail the various types of enum classes that can be generated.
 </p>
 
-<H4><a name="Java_typesafe_enums_classes">25.4.5.1 Typesafe enum classes</a></H4>
+<H4><a name="Java_typesafe_enums_classes">26.4.5.1 Typesafe enum classes</a></H4>
 
 
 <p>
@@ -3227,7 +3227,7 @@ The <tt>swigValue</tt> method is used for marshalling in the other direction.
 The <tt>toString</tt> method is overridden so that the enum name is available.
 </p>
 
-<H4><a name="Java_proper_enums_classes">25.4.5.2 Proper Java enum classes</a></H4>
+<H4><a name="Java_proper_enums_classes">26.4.5.2 Proper Java enum classes</a></H4>
 
 
 <p>
@@ -3305,7 +3305,7 @@ These needn't be generated if the enum being wrapped does not have any initializ
 <a href="#Java_simpler_enum_classes">Simpler Java enums for enums without initializers</a> section describes how typemaps can be used to achieve this.
 </p>
 
-<H4><a name="Java_typeunsafe_enums_classes">25.4.5.3 Type unsafe enum classes</a></H4>
+<H4><a name="Java_typeunsafe_enums_classes">26.4.5.3 Type unsafe enum classes</a></H4>
 
 
 <p>
@@ -3336,7 +3336,7 @@ public final class Beverage {
 </pre>
 </div>
 
-<H3><a name="Java_interfaces">25.4.6 Interfaces</a></H3>
+<H3><a name="Java_interfaces">26.4.6 Interfaces</a></H3>
 
 
 <p>
@@ -3581,7 +3581,7 @@ typemap which is only used when a class is marked with the <tt>interface</tt> fe
 See <a href="Java.html#Java_code_typemaps">Java code typemaps</a> for details.
 </p>
 
-<H2><a name="Java_directors">25.5 Cross language polymorphism using directors</a></H2>
+<H2><a name="Java_directors">26.5 Cross language polymorphism using directors</a></H2>
 
 
 <p>
@@ -3603,7 +3603,7 @@ The upshot is that C++ classes can be extended in Java and from C++ these extens
 Neither C++ code nor Java code needs to know where a particular method is implemented: the combination of proxy classes, director classes, and C wrapper functions transparently takes care of all the cross-language method routing.
 </p>
 
-<H3><a name="Java_enabling_directors">25.5.1 Enabling directors</a></H3>
+<H3><a name="Java_enabling_directors">26.5.1 Enabling directors</a></H3>
 
 
 <p>
@@ -3671,7 +3671,7 @@ public:
 </pre>
 </div>
 
-<H3><a name="Java_directors_classes">25.5.2 Director classes</a></H3>
+<H3><a name="Java_directors_classes">26.5.2 Director classes</a></H3>
 
 
 <p>
@@ -3698,7 +3698,7 @@ If the correct implementation is in Java, the Java API is used to call the metho
 </p>
 
 
-<H3><a name="Java_directors_overhead">25.5.3 Overhead and code bloat</a></H3>
+<H3><a name="Java_directors_overhead">26.5.3 Overhead and code bloat</a></H3>
 
 
 <p>
@@ -3716,7 +3716,7 @@ This situation can be optimized by selectively enabling director methods (using
 </p>
 
 
-<H3><a name="Java_directors_example">25.5.4 Simple directors example</a></H3>
+<H3><a name="Java_directors_example">26.5.4 Simple directors example</a></H3>
 
 
 <p>
@@ -3779,7 +3779,7 @@ DirectorDerived.upcall_method() invoked.
 </pre>
 </div>
 
-<H3><a name="Java_directors_threading">25.5.5 Director threading issues</a></H3>
+<H3><a name="Java_directors_threading">26.5.5 Director threading issues</a></H3>
 
 
 <p>
@@ -3799,7 +3799,7 @@ Macros can be defined on the commandline when compiling your C++ code, or altern
 </pre>
 </div>
 
-<H3><a name="Java_directors_performance">25.5.6 Director performance tuning</a></H3>
+<H3><a name="Java_directors_performance">26.5.6 Director performance tuning</a></H3>
 
 
 <p>
@@ -3820,7 +3820,7 @@ However, if all director methods are expected to usually be overridden by Java s
 The disadvantage is that invocation of director methods from C++ when Java doesn't actually override the method will require an additional call up into Java and back to C++.  As such, this option is only useful when overrides are extremely common and instantiation is frequent enough that its performance is critical.
 </p>
 
-<H3><a name="Java_exceptions_from_directors">25.5.7 Java exceptions from directors</a></H3>
+<H3><a name="Java_exceptions_from_directors">26.5.7 Java exceptions from directors</a></H3>
 
 
 <p>
@@ -3896,7 +3896,7 @@ Exception in thread "main" java.lang.RuntimeException: There was a problem!
 More on the <tt>Swig::DirectorException</tt> class can be found in the next section which details how to customize the handling of director exceptions.
 </p>
 
-<H4><a name="Java_customizing_director_exceptions">25.5.7.1 Customizing director exceptions</a></H4>
+<H4><a name="Java_customizing_director_exceptions">26.5.7.1 Customizing director exceptions</a></H4>
 
 
 <p>
@@ -4454,7 +4454,7 @@ Exception in thread "main" java.lang.IndexOutOfBoundsException: Index is negativ
 </pre>
 </div>
 
-<H2><a name="Java_allprotected">25.6 Accessing protected members</a></H2>
+<H2><a name="Java_allprotected">26.6 Accessing protected members</a></H2>
 
 
 <p>
@@ -4550,7 +4550,7 @@ class MyProtectedBase extends ProtectedBase
 
 
 
-<H2><a name="Java_common_customization">25.7 Common customization features</a></H2>
+<H2><a name="Java_common_customization">26.7 Common customization features</a></H2>
 
 
 <p>
@@ -4562,7 +4562,7 @@ be awkward.  This section describes some common SWIG features that are used
 to improve the interface to existing C/C++ code.
 </p>
 
-<H3><a name="Java_helper_functions">25.7.1 C/C++ helper functions</a></H3>
+<H3><a name="Java_helper_functions">26.7.1 C/C++ helper functions</a></H3>
 
 
 <p>
@@ -4628,7 +4628,7 @@ hard to implement.  It is possible to improve on this using Java code, typemaps,
 customization features as covered in later sections, but sometimes helper functions are a quick and easy solution to difficult cases.  
 </p>
 
-<H3><a name="Java_class_extension">25.7.2 Class extension with %extend</a></H3>
+<H3><a name="Java_class_extension">26.7.2 Class extension with %extend</a></H3>
 
 
 <p>
@@ -4691,7 +4691,7 @@ Vector(2, 3, 4)
 in any way---the extensions only show up in the Java interface.
 </p>
 
-<H3><a name="Java_proxycode">25.7.3 Class extension with %proxycode</a></H3>
+<H3><a name="Java_proxycode">26.7.3 Class extension with %proxycode</a></H3>
 
 
 <p>
@@ -4828,7 +4828,7 @@ public class ValueUnsignedInt {
 </pre>
 </div>
 
-<H3><a name="Java_exception_handling">25.7.4 Exception handling with %exception and %javaexception</a></H3>
+<H3><a name="Java_exception_handling">26.7.4 Exception handling with %exception and %javaexception</a></H3>
 
 
 <p>
@@ -4987,7 +4987,7 @@ to raise exceptions.  See the <a href="Library.html#Library">SWIG Library</a> ch
 The typemap example <a href="#Java_exception_typemap">Handling C++ exception specifications as Java exceptions</a> provides further exception handling capabilities.
 </p>
 
-<H3><a name="Java_method_access">25.7.5 Method access with %javamethodmodifiers</a></H3>
+<H3><a name="Java_method_access">26.7.5 Method access with %javamethodmodifiers</a></H3>
 
 
 <p>
@@ -5013,7 +5013,7 @@ protected static void protect_me() {
 </pre>
 </div>
 
-<H2><a name="Java_tips_techniques">25.8 Tips and techniques</a></H2>
+<H2><a name="Java_tips_techniques">26.8 Tips and techniques</a></H2>
 
 
 <p>
@@ -5023,7 +5023,7 @@ strings and arrays.   This chapter discusses the common techniques for
 solving these problems.
 </p>
 
-<H3><a name="Java_input_output_parameters">25.8.1 Input and output parameters using primitive pointers and references</a></H3>
+<H3><a name="Java_input_output_parameters">26.8.1 Input and output parameters using primitive pointers and references</a></H3>
 
 
 <p>
@@ -5197,7 +5197,7 @@ void foo(Bar *OUTPUT);
 will not have the intended effect since <tt>typemaps.i</tt> does not define an OUTPUT rule for <tt>Bar</tt>.
 </p>
 
-<H3><a name="Java_simple_pointers">25.8.2 Simple pointers</a></H3>
+<H3><a name="Java_simple_pointers">26.8.2 Simple pointers</a></H3>
 
 
 <p>
@@ -5263,7 +5263,7 @@ System.out.println("3 + 4 = " + result);
 See the <a href="Library.html#Library">SWIG Library</a> chapter for further details.
 </p>
 
-<H3><a name="Java_c_arrays">25.8.3 Wrapping C arrays with Java arrays</a></H3>
+<H3><a name="Java_c_arrays">26.8.3 Wrapping C arrays with Java arrays</a></H3>
 
 
 <p>
@@ -5330,7 +5330,7 @@ Please be aware that the typemaps in this library are not efficient as all the e
 There is an alternative approach using the SWIG array library and this is covered in the next section.
 </p>
 
-<H3><a name="Java_unbounded_c_arrays">25.8.4 Unbounded C Arrays</a></H3>
+<H3><a name="Java_unbounded_c_arrays">26.8.4 Unbounded C Arrays</a></H3>
 
 
 <p>
@@ -5475,7 +5475,7 @@ well suited for applications in which you need to create buffers,
 package binary data, etc.
 </p>
 
-<H3><a name="Java_binary_char">25.8.5 Binary data vs Strings</a></H3>
+<H3><a name="Java_binary_char">26.8.5 Binary data vs Strings</a></H3>
 
 
 <p>
@@ -5519,7 +5519,7 @@ len: 5 data: 68 69 0 6a 6b
 </pre></div>
 
 
-<H3><a name="Java_heap_allocations">25.8.6 Overriding new and delete to allocate from Java heap</a></H3>
+<H3><a name="Java_heap_allocations">26.8.6 Overriding new and delete to allocate from Java heap</a></H3>
 
 
 <p>
@@ -5636,7 +5636,7 @@ model and use these functions in place of malloc and free in your own
 code.
 </p>
 
-<H2><a name="Java_typemaps">25.9 Java typemaps</a></H2>
+<H2><a name="Java_typemaps">26.9 Java typemaps</a></H2>
 
 
 <p>
@@ -5657,7 +5657,7 @@ Before proceeding, it should be stressed that typemaps are not a required
 part of using SWIG---the default wrapping behavior is enough in most cases.
 Typemaps are only used if you want to change some aspect of the generated code.
 
-<H3><a name="Java_default_primitive_type_mappings">25.9.1 Default primitive type mappings</a></H3>
+<H3><a name="Java_default_primitive_type_mappings">26.9.1 Default primitive type mappings</a></H3>
 
 
 <p>
@@ -5809,7 +5809,7 @@ However, the mappings allow the full range of values for each C type from Java.
 </p>
 
 
-<H3><a name="Java_default_non_primitive_typemaps">25.9.2 Default typemaps for non-primitive types</a></H3>
+<H3><a name="Java_default_non_primitive_typemaps">26.9.2 Default typemaps for non-primitive types</a></H3>
 
 
 <p>
@@ -5824,7 +5824,7 @@ So in summary, the C/C++ pointer to non-primitive types is cast into the 64 bit
 The Java type is either the proxy class or type wrapper class.
 </p>
 
-<H3><a name="Java_jvm64">25.9.3 Sixty four bit JVMs</a></H3>
+<H3><a name="Java_jvm64">26.9.3 Sixty four bit JVMs</a></H3>
 
 
 <p>
@@ -5837,7 +5837,7 @@ Unfortunately it won't of course hold true for JNI code.
 </p>
 
 
-<H3><a name="Java_what_is_typemap">25.9.4 What is a typemap?</a></H3>
+<H3><a name="Java_what_is_typemap">26.9.4 What is a typemap?</a></H3>
 
 
 <p>
@@ -5960,7 +5960,7 @@ int c = example.count('e', "Hello World");
 </pre>
 </div>
 
-<H3><a name="Java_typemaps_c_to_java_types">25.9.5 Typemaps for mapping C/C++ types to Java types</a></H3>
+<H3><a name="Java_typemaps_c_to_java_types">26.9.5 Typemaps for mapping C/C++ types to Java types</a></H3>
 
 
 <p>
@@ -6240,7 +6240,7 @@ These are listed below:
 
 </table>
 
-<H3><a name="Java_typemap_attributes">25.9.6 Java typemap attributes</a></H3>
+<H3><a name="Java_typemap_attributes">26.9.6 Java typemap attributes</a></H3>
 
 
 <p>
@@ -6286,7 +6286,7 @@ The "javain" typemap has the optional 'pre', 'post' and 'pgcppname' attributes.
 Note that when the 'pre' or 'post' attributes are specified and the associated type is used in a constructor, a constructor helper function is generated. This is necessary as the Java proxy constructor wrapper makes a call to a support constructor using a <i>this</i> call. In Java the <i>this</i> call must be the first statement in the constructor body. The constructor body thus calls the helper function and the helper function instead makes the JNI call, ensuring the 'pre' code is called before the JNI call is made. There is a <a href="#Java_date_marshalling">Date marshalling</a> example showing 'pre', 'post' and 'pgcppname' attributes in action.
 </p>
 
-<H3><a name="Java_special_variables">25.9.7 Java special variables</a></H3>
+<H3><a name="Java_special_variables">26.9.7 Java special variables</a></H3>
 
 
 <p>
@@ -6468,7 +6468,7 @@ in that it is not fully qualified with the package name when using the
 <a href="SWIGPlus.html#SWIGPlus_nspace">nspace feature</a>.
 </p>
 
-<H3><a name="Java_typemaps_for_c_and_cpp">25.9.8 Typemaps for both C and C++ compilation</a></H3>
+<H3><a name="Java_typemaps_for_c_and_cpp">26.9.8 Typemaps for both C and C++ compilation</a></H3>
 
 
 <p>
@@ -6505,7 +6505,7 @@ If you do not intend your code to be targeting both C and C++ then your typemaps
 </p>
 
 
-<H3><a name="Java_code_typemaps">25.9.9 Java code typemaps</a></H3>
+<H3><a name="Java_code_typemaps">26.9.9 Java code typemaps</a></H3>
 
 
 <p>
@@ -6801,7 +6801,7 @@ to make the method and constructor public:
 </pre>
 </div>
 
-<H3><a name="Java_directors_typemaps">25.9.10 Director specific typemaps</a></H3>
+<H3><a name="Java_directors_typemaps">26.9.10 Director specific typemaps</a></H3>
 
 
 <p>
@@ -7078,7 +7078,7 @@ The basic strategy here is to provide a default package typemap for the majority
 
 </div>
 
-<H2><a name="Java_typemap_examples">25.10 Typemap Examples</a></H2>
+<H2><a name="Java_typemap_examples">26.10 Typemap Examples</a></H2>
 
 
 <p>
@@ -7088,7 +7088,7 @@ the SWIG library.
 </p>
 
 
-<H3><a name="Java_simpler_enum_classes">25.10.1 Simpler Java enums for enums without initializers</a></H3>
+<H3><a name="Java_simpler_enum_classes">26.10.1 Simpler Java enums for enums without initializers</a></H3>
 
 
 <p>
@@ -7167,7 +7167,7 @@ This would be done by using the original versions of these typemaps in "enums.sw
 </p>
 
 
-<H3><a name="Java_exception_typemap">25.10.2 Handling C++ exception specifications as Java exceptions</a></H3>
+<H3><a name="Java_exception_typemap">26.10.2 Handling C++ exception specifications as Java exceptions</a></H3>
 
 
 <p>
@@ -7292,7 +7292,7 @@ We could alternatively have used <tt>%rename</tt> to rename <tt>what()</tt> into
 </p>
 
 
-<H3><a name="Java_nan_exception_typemap">25.10.3 NaN Exception - exception handling for a particular type</a></H3>
+<H3><a name="Java_nan_exception_typemap">26.10.3 NaN Exception - exception handling for a particular type</a></H3>
 
 
 <p>
@@ -7447,7 +7447,7 @@ If we were a martyr to the JNI cause, we could replace the succinct code within
 If we had, we would have put it in the "in" typemap which, like all JNI and Java typemaps, also supports the 'throws' attribute.
 </p>
 
-<H3><a name="Java_converting_java_string_arrays">25.10.4 Converting Java String arrays to char ** </a></H3>
+<H3><a name="Java_converting_java_string_arrays">26.10.4 Converting Java String arrays to char ** </a></H3>
 
 
 <p>
@@ -7591,7 +7591,7 @@ Lastly the "jni", "jtype" and "jstype" typemaps are also required to specify
 what Java types to use.
 </p>
 
-<H3><a name="Java_expanding_java_object">25.10.5 Expanding a Java object to multiple arguments</a></H3>
+<H3><a name="Java_expanding_java_object">26.10.5 Expanding a Java object to multiple arguments</a></H3>
 
 
 <p>
@@ -7673,7 +7673,7 @@ example.foo(new String[]{"red", "green", "blue", "white"});
 </div>
 
 
-<H3><a name="Java_using_typemaps_return_arguments">25.10.6 Using typemaps to return arguments</a></H3>
+<H3><a name="Java_using_typemaps_return_arguments">26.10.6 Using typemaps to return arguments</a></H3>
 
 
 <p>
@@ -7791,7 +7791,7 @@ $ java runme
 1 12.0  340.0
 </pre></div>
 
-<H3><a name="Java_adding_downcasts">25.10.7 Adding Java downcasts to polymorphic return types</a></H3>
+<H3><a name="Java_adding_downcasts">26.10.7 Adding Java downcasts to polymorphic return types</a></H3>
 
 
 <p>
@@ -7997,7 +7997,7 @@ SWIG usually generates code which constructs the proxy classes using Java code a
 Note that the JNI code above uses a number of string lookups to call a constructor, whereas this would not occur using byte compiled Java code.
 </p>
 
-<H3><a name="Java_adding_equals_method">25.10.8 Adding an equals method to the Java classes</a></H3>
+<H3><a name="Java_adding_equals_method">26.10.8 Adding an equals method to the Java classes</a></H3>
 
 
 <p>
@@ -8041,7 +8041,7 @@ System.out.println("foo1? " + foo1.equals(foo2));
 </div>
 
 
-<H3><a name="Java_void_pointers">25.10.9 Void pointers and a common Java base class</a></H3>
+<H3><a name="Java_void_pointers">26.10.9 Void pointers and a common Java base class</a></H3>
 
 
 <p>
@@ -8100,7 +8100,7 @@ This example contains some useful functionality which you may want in your code.
     <li> It also has a function which effectively implements a cast from the type of the proxy/type wrapper class to a void pointer. This is necessary for passing a proxy class or a type wrapper class to a function that takes a void pointer.
 </ul>
 
-<H3><a name="Java_struct_pointer_pointer">25.10.10 Struct pointer to pointer</a></H3>
+<H3><a name="Java_struct_pointer_pointer">26.10.10 Struct pointer to pointer</a></H3>
 
 
 <p>
@@ -8280,7 +8280,7 @@ The C functional interface has been completely morphed into an object-oriented i
 the Butler class would behave much like any pure Java class and feel more natural to Java users.
 </p>
 
-<H3><a name="Java_memory_management_member_variables">25.10.11 Memory management when returning references to member variables</a></H3>
+<H3><a name="Java_memory_management_member_variables">26.10.11 Memory management when returning references to member variables</a></H3>
 
 
 <p>
@@ -8403,7 +8403,7 @@ public class Bike {
 Note the <tt>addReference</tt> call.
 </p>
 
-<H3><a name="Java_memory_management_objects">25.10.12 Memory management for objects passed to the C++ layer</a></H3>
+<H3><a name="Java_memory_management_objects">26.10.12 Memory management for objects passed to the C++ layer</a></H3>
 
 
 <p>
@@ -8531,7 +8531,7 @@ as mentioned earlier, <tt>setElement</tt> is actually:
 </pre>
 </div>
 
-<H3><a name="Java_date_marshalling">25.10.13 Date marshalling using the javain typemap and associated attributes</a></H3>
+<H3><a name="Java_date_marshalling">26.10.13 Date marshalling using the javain typemap and associated attributes</a></H3>
 
 
 <p>
@@ -8708,7 +8708,7 @@ A few things to note:
 
 
 
-<H2><a name="Java_directors_faq">25.11 Living with Java Directors</a></H2>
+<H2><a name="Java_directors_faq">26.11 Living with Java Directors</a></H2>
 
 
 <p>
@@ -8887,10 +8887,10 @@ public abstract class UserVisibleFoo extends Foo {
   </li>
 </ol>
 
-<H2><a name="Java_odds_ends">25.12 Odds and ends</a></H2>
+<H2><a name="Java_odds_ends">26.12 Odds and ends</a></H2>
 
 
-<H3><a name="Java_javadoc_comments">25.12.1 JavaDoc comments</a></H3>
+<H3><a name="Java_javadoc_comments">26.12.1 JavaDoc comments</a></H3>
 
 
 <p>
@@ -8946,7 +8946,7 @@ public class Barmy {
 
 
 
-<H3><a name="Java_functional_interface">25.12.2 Functional interface without proxy classes</a></H3>
+<H3><a name="Java_functional_interface">26.12.2 Functional interface without proxy classes</a></H3>
 
 
 <p>
@@ -9007,7 +9007,7 @@ All destructors have to be called manually for example the <tt>delete_Foo(foo)</
 </p>
 
 
-<H3><a name="Java_using_own_jni_functions">25.12.3 Using your own JNI functions</a></H3>
+<H3><a name="Java_using_own_jni_functions">26.12.3 Using your own JNI functions</a></H3>
 
 
 <p>
@@ -9057,7 +9057,7 @@ This directive is only really useful if you want to mix your own hand crafted JN
 </p>
 
 
-<H3><a name="Java_performance">25.12.4 Performance concerns and hints</a></H3>
+<H3><a name="Java_performance">26.12.4 Performance concerns and hints</a></H3>
 
 
 <p>
@@ -9078,7 +9078,7 @@ However, you will have to be careful about memory management and make sure that
 This method normally calls the C++ destructor or <tt>free()</tt> for C code.
 </p>
 
-<H3><a name="Java_debugging">25.12.5 Debugging</a></H3>
+<H3><a name="Java_debugging">26.12.5 Debugging</a></H3>
 
 
 <p>
@@ -9100,7 +9100,7 @@ The -verbose:jni and -verbose:gc are also useful options for monitoring code beh
 </p>
 
 
-<H2><a name="Java_examples">25.13 Java Examples</a></H2>
+<H2><a name="Java_examples">26.13 Java Examples</a></H2>
 
 
 <p>
diff --git a/Doc/Manual/Javascript.html b/Doc/Manual/Javascript.html
index 8de528511..c328bbb6b 100644
--- a/Doc/Manual/Javascript.html
+++ b/Doc/Manual/Javascript.html
@@ -7,7 +7,7 @@
 </head>
 <body>
 
-<H1><a name="Javascript">26 SWIG and Javascript</a></H1>
+<H1><a name="Javascript">27 SWIG and Javascript</a></H1>
 <!-- INDEX -->
 <div class="sectiontoc">
 <ul>
@@ -52,7 +52,7 @@
 
 <p>This chapter describes SWIG's support of Javascript. It does not cover SWIG basics, but only information that is specific to this module.</p>
 
-<H2><a name="Javascript_overview">26.1 Overview</a></H2>
+<H2><a name="Javascript_overview">27.1 Overview</a></H2>
 
 
 <p>Javascript is a prototype-based scripting language that is dynamic, weakly typed and has first-class functions. Its arguably the most popular language for web development.
@@ -63,10 +63,10 @@ Javascript has gone beyond being a browser-based scripting language and with <a
 With <a href="https://github.com/rogerwang/node-webkit">node-webkit</a> there is a platform which uses Google's <code>Chromium</code> as Web-Browser widget and <code>node.js</code> for javascript extensions.
 </p>
 
-<H2><a name="Javascript_preliminaries">26.2 Preliminaries</a></H2>
+<H2><a name="Javascript_preliminaries">27.2 Preliminaries</a></H2>
 
 
-<H3><a name="Javascript_running_swig">26.2.1 Running SWIG</a></H3>
+<H3><a name="Javascript_running_swig">27.2.1 Running SWIG</a></H3>
 
 
 <p>Suppose that you defined a SWIG module such as the following:</p>
@@ -121,7 +121,7 @@ void example_initialize(v8::Handle&lt;v8::Object&gt; exports)</pre>
 <b>Note</b>: be aware that <code>v8</code> has a C++ API, and thus, the generated modules must be compiled as C++.
 </p>
 
-<H3><a name="Javascript_running_tests_examples">26.2.2 Running Tests and Examples</a></H3>
+<H3><a name="Javascript_running_tests_examples">27.2.2 Running Tests and Examples</a></H3>
 
 
 <p>The configuration for tests and examples currently supports Linux and Mac only and not MinGW (Windows) yet.</p>
@@ -153,7 +153,7 @@ $ make check-javascript-test-suite ENGINE=jsc</pre>
 $ make check-javascript-examples V8_VERSION=0x032530 ENGINE=v8</pre>
 </div>
 
-<H3><a name="Javascript_known_issues">26.2.3 Known Issues</a></H3>
+<H3><a name="Javascript_known_issues">27.2.3 Known Issues</a></H3>
 
 
 <p>At the moment, the Javascript generators pass all tests syntactically, i.e., the generated source code compiles. However, there are still remaining runtime issues.</p>
@@ -170,12 +170,12 @@ $ make check-javascript-examples V8_VERSION=0x032530 ENGINE=v8</pre>
 
 <p>The primary development environment has been Linux (Ubuntu 12.04). Windows and Mac OS X have been tested sporadically. Therefore, the generators might have more issues on those platforms. Please report back any problem you observe to help us improving this module quickly.</p>
 
-<H2><a name="Javascript_integration">26.3 Integration</a></H2>
+<H2><a name="Javascript_integration">27.3 Integration</a></H2>
 
 
 <p>This chapter gives a short introduction how to use a native Javascript extension: as a <code>node.js</code> module, and as an extension for an embedded Webkit.</p>
 
-<H3><a name="Javascript_node_extensions">26.3.1 Creating node.js Extensions</a></H3>
+<H3><a name="Javascript_node_extensions">27.3.1 Creating node.js Extensions</a></H3>
 
 
 <p>To install <code>node.js</code> you can download an installer from their <a href="https://launchpad.net/~chris-lea/+archive/node.js">web-site</a> for Mac OS X and Windows. For Linux you can either build the source yourself and run <code>sudo checkinstall</code> or keep to the (probably stone-age) packaged version. For Ubuntu there is a <a href="https://launchpad.net/~chris-lea/+archive/ubuntu/node.js/">PPA</a> available.</p>
@@ -221,7 +221,7 @@ require("./build/Release/example")</pre>
 </div>
 <p>A more detailed explanation is given in the <a href="#Javascript_examples">Examples</a> section.</p>
 
-<H4><a name="Javascript_troubleshooting">26.3.1.1 Troubleshooting</a></H4>
+<H4><a name="Javascript_troubleshooting">27.3.1.1 Troubleshooting</a></H4>
 
 
 <ul>
@@ -233,12 +233,12 @@ require("./build/Release/example")</pre>
 $ sudo apt-get remove gyp</pre>
 </div>
 
-<H3><a name="Javascript_embedded_webkit">26.3.2 Embedded Webkit</a></H3>
+<H3><a name="Javascript_embedded_webkit">27.3.2 Embedded Webkit</a></H3>
 
 
 <p>Webkit is pre-installed on Mac OS X and available as a library for GTK.</p>
 
-<H4><a name="Javascript_osx">26.3.2.1 Mac OS X</a></H4>
+<H4><a name="Javascript_osx">27.3.2.1 Mac OS X</a></H4>
 
 
 <p>There is general information about programming with WebKit on <a href="https://developer.apple.com/library/mac/documentation/cocoa/conceptual/DisplayWebContent/DisplayWebContent.html">Apple Developer Documentation</a>. Details about <code>Cocoa</code> programming are not covered here.</p>
@@ -286,7 +286,7 @@ extern bool example_initialize(JSGlobalContextRef context, JSObjectRef* exports)
 @end</pre>
 </div>
 
-<H4><a name="Javascript_gtk">26.3.2.2 GTK</a></H4>
+<H4><a name="Javascript_gtk">27.3.2.2 GTK</a></H4>
 
 
 <p>There is general information about programming GTK at <a href="https://developer.gnome.org/gtk2/">GTK documentation</a> and in the <a href="https://developer.gnome.org/gtk-tutorial">GTK tutorial</a>, and for Webkit there is a <a href="http://webkitgtk.org/reference/webkitgtk/stable/index.html">Webkit GTK+ API Reference</a>.</p>
@@ -331,7 +331,7 @@ int main(int argc, char* argv[])
 }</pre>
 </div>
 
-<H3><a name="Javascript_applications_webkit">26.3.3 Creating Applications with node-webkit</a></H3>
+<H3><a name="Javascript_applications_webkit">27.3.3 Creating Applications with node-webkit</a></H3>
 
 
 <p>To get started with <code>node-webkit</code> there is a very informative set of <a href="https://github.com/rogerwang/node-webkit/wiki">wiki pages</a>.</p>
@@ -422,12 +422,12 @@ open new windows, and many more things.
 };</pre>
 </div>
 
-<H2><a name="Javascript_examples">26.4 Examples</a></H2>
+<H2><a name="Javascript_examples">27.4 Examples</a></H2>
 
 
 <p>Some basic examples are shown here in more detail.</p>
 
-<H3><a name="Javascript_simple_example">26.4.1 Simple</a></H3>
+<H3><a name="Javascript_simple_example">27.4.1 Simple</a></H3>
 
 
 <p>The common example <code>simple</code> looks like this:</p>
@@ -477,7 +477,7 @@ example.Foo = 3.1415926;</pre>
 
 <p><b>Note</b>: ECMAScript 5, the currently implemented Javascript standard, does not have modules. <code>node.js</code> and other implementations provide this mechanism defined by the <a href="http://wiki.commonjs.org/wiki/CommonJS">CommonJS</a> group. For browsers this is provided by <a href="http://browserify.org">Browserify</a>, for instance.</p>
 
-<H3><a name="Javascript_class_example">26.4.2 Class</a></H3>
+<H3><a name="Javascript_class_example">27.4.2 Class</a></H3>
 
 
 <p>The common example <code>class</code> defines three classes, <code>Shape</code>, <code>Circle</code>, and <code>Square</code>:</p>
@@ -607,12 +607,12 @@ at emitKey (readline.js:1095:12)</pre>
 <b>Note</b>: In ECMAScript 5 there is no concept for classes. Instead each function can be used as a constructor function which is executed by the 'new' operator. Furthermore, during construction the key property <code>prototype</code> of the constructor function is used to attach a prototype instance to the created object. A prototype is essentially an object itself that is the first-class delegate of a class used whenever the access to a property of an object fails. The very same prototype instance is shared among all instances of one type. Prototypal inheritance is explained in more detail on in <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Inheritance_and_the_prototype_chain">Inheritance and the prototype chain</a>, for instance.
 </p>
 
-<H2><a name="Javascript_implementation">26.5 Implementation</a></H2>
+<H2><a name="Javascript_implementation">27.5 Implementation</a></H2>
 
 
 <p>The Javascript Module implementation has taken a very different approach compared to other language modules in order to support different Javascript interpreters.</p>
 
-<H3><a name="Javascript_source_code">26.5.1 Source Code</a></H3>
+<H3><a name="Javascript_source_code">27.5.1 Source Code</a></H3>
 
 
 <p>The Javascript module is implemented in <code>Source/Modules/javascript.cxx</code>. It dispatches the code generation to a <code>JSEmitter</code> instance, <code>V8Emitter</code> or <code>JSCEmitter</code>. Additionally there are some helpers: <code>Template</code>, for templated code generation, and <code>JSEmitterState</code>, which is used to manage state information during AST traversal. This rough map shall make it easier to find a way through this huge source file:</p>
@@ -713,7 +713,7 @@ Template::Template(const String *code_) { ... }
 ...</pre>
 </div>
 
-<H3><a name="Javascript_code_templates">26.5.2 Code Templates</a></H3>
+<H3><a name="Javascript_code_templates">27.5.2 Code Templates</a></H3>
 
 
 <p>All generated code is created on the basis of code templates. The templates for <em>JavascriptCore</em> can be found in <code>Lib/javascript/jsc/javascriptcode.swg</code>, for <em>v8</em> in <code>Lib/javascript/v8/javascriptcode.swg</code>.</p>
@@ -752,7 +752,7 @@ t_register.replace("$jsparent", state.clazz(NAME_MANGLED))
 </div>
 <p><code>Template</code> creates a copy of that string and <code>Template::replace</code> uses Swig's <code>Replaceall</code> to replace variables in the template. <code>Template::trim</code> can be used to eliminate leading and trailing whitespaces. <code>Template::print</code> is used to write the final template string to a Swig <code>DOH</code> (based on <code>Printv</code>). All methods allow chaining.</p>
 
-<H3><a name="Javascript_emitter">26.5.3 Emitter</a></H3>
+<H3><a name="Javascript_emitter">27.5.3 Emitter</a></H3>
 
 
 <p>The Javascript module delegates code generation to a <code>JSEmitter</code> instance. The following extract shows the essential interface:</p>
@@ -871,7 +871,7 @@ int JAVASCRIPT::classHandler(Node *n) {
 </div>
 <p>In <code>enterClass</code> the emitter stores state information that is necessary when processing class members. In <code>exitClass</code> the wrapper code for the whole class is generated.</p>
 
-<H3><a name="Javascript_emitter_states">26.5.4 Emitter states</a></H3>
+<H3><a name="Javascript_emitter_states">27.5.4 Emitter states</a></H3>
 
 
 <p>For storing information during the AST traversal the emitter provides a <code>JSEmitterState</code> with different slots to store data representing the scopes global, class, function, and variable.</p>
@@ -915,7 +915,7 @@ state.clazz(NAME, Getattr(n, "sym:name"));</pre>
 <p>State information can be retrieved using <code>state.clazz(NAME)</code> or with <code>Getattr</code> on <code>state.clazz()</code> which actually returns a <code>Hash</code> instance.</p>
 
 
-<H3><a name="Javascript_jsc_exceptions">26.5.5 Handling Exceptions in JavascriptCore</a></H3>
+<H3><a name="Javascript_jsc_exceptions">27.5.5 Handling Exceptions in JavascriptCore</a></H3>
 
 
 <p>Applications with an embedded JavascriptCore should be able to present detailed exception messages that occur in the Javascript engine. Below is an example derived from code provided by Brian Barnes on how these exception details can be extracted.</p>
diff --git a/Doc/Manual/Library.html b/Doc/Manual/Library.html
index c2c02fc7d..4ef6aeb83 100644
--- a/Doc/Manual/Library.html
+++ b/Doc/Manual/Library.html
@@ -7,7 +7,7 @@
 </head>
 
 <body bgcolor="#ffffff">
-<H1><a name="Library">10 SWIG library</a></H1>
+<H1><a name="Library">11 SWIG library</a></H1>
 <!-- INDEX -->
 <div class="sectiontoc">
 <ul>
@@ -67,7 +67,7 @@ Alternative libraries provide similar functionality.  Please read this chapter
 carefully if you used the old libraries.
 </p>
 
-<H2><a name="Library_nn2">10.1 The %include directive and library search path</a></H2>
+<H2><a name="Library_nn2">11.1 The %include directive and library search path</a></H2>
 
 
 <p>
@@ -99,7 +99,7 @@ Set the environment variable to hold an alternative library directory.
 The directories that are searched are displayed when using <tt>-verbose</tt> commandline option.
 </p>
 
-<H2><a name="Library_nn3">10.2 C arrays and pointers</a></H2>
+<H2><a name="Library_nn3">11.2 C arrays and pointers</a></H2>
 
 
 <p>
@@ -111,7 +111,7 @@ pointers as class-like objects.   Since these functions provide direct access to
 memory, their use is potentially unsafe and you should exercise caution.
 </p>
 
-<H3><a name="Library_nn4">10.2.1 cpointer.i</a></H3>
+<H3><a name="Library_nn4">11.2.1 cpointer.i</a></H3>
 
 
 <p>
@@ -327,7 +327,7 @@ In this example,  the function <tt>int_to_uint()</tt> would be used to cast type
 <b>Note:</b> When working with simple pointers, typemaps can often be used to provide more seamless operation.
 </p>
 
-<H3><a name="Library_carrays">10.2.2 carrays.i</a></H3>
+<H3><a name="Library_carrays">11.2.2 carrays.i</a></H3>
 
 
 <p>
@@ -506,7 +506,7 @@ used with types of <tt>char</tt> or <tt>char *</tt>.
 SWIG's default handling of these types is to handle them as character strings and the two macros do not do enough to change this.
 </p>
 
-<H3><a name="Library_nn6">10.2.3 cmalloc.i</a></H3>
+<H3><a name="Library_nn6">11.2.3 cmalloc.i</a></H3>
 
 
 <p>
@@ -667,7 +667,7 @@ Now, in a script:
 </pre>
 </div>
 
-<H3><a name="Library_nn7">10.2.4 cdata.i</a></H3>
+<H3><a name="Library_nn7">11.2.4 cdata.i</a></H3>
 
 
 <p>
@@ -769,7 +769,7 @@ char *cdata_<em>name</em>(type* ptr, int nitems)
 Clearly they are unsafe.
 </p>
 
-<H2><a name="Library_nn8">10.3 C string handling</a></H2>
+<H2><a name="Library_nn8">11.3 C string handling</a></H2>
 
 
 <p>
@@ -789,7 +789,7 @@ morality.  The modules in this section provide basic functionality
 for manipulating raw C strings.
 </p>
 
-<H3><a name="Library_nn9">10.3.1 Default string handling</a></H3>
+<H3><a name="Library_nn9">11.3.1 Default string handling</a></H3>
 
 
 <p>
@@ -830,7 +830,7 @@ interpreter and lead to a crash).  Furthermore, the default behavior does
 not work well with binary data. Instead, strings are assumed to be NULL-terminated.
 </p>
 
-<H3><a name="Library_nn10">10.3.2 Passing binary data</a></H3>
+<H3><a name="Library_nn10">11.3.2 Passing binary data</a></H3>
 
 
 <p>
@@ -872,7 +872,7 @@ In the wrapper function, the passed string will be expanded to a pointer and len
 The <tt>(char *STRING, int LENGTH)</tt> multi-argument typemap is also available in addition to <tt>(char *STRING, size_t LENGTH)</tt>.
 </p>
 
-<H3><a name="Library_nn11">10.3.3 Using %newobject to release memory</a></H3>
+<H3><a name="Library_nn11">11.3.3 Using %newobject to release memory</a></H3>
 
 
 <p>
@@ -913,7 +913,7 @@ however, you may need to provide your own "newfree" typemap for other types.
 See <a href="Customization.html#Customization_ownership">Object ownership and %newobject</a> for more details.
 </p>
 
-<H3><a name="Library_nn12">10.3.4 cstring.i</a></H3>
+<H3><a name="Library_nn12">11.3.4 cstring.i</a></H3>
 
 
 <p>
@@ -1373,7 +1373,7 @@ structure or class instead.
 </li>
 </ul>
 
-<H2><a name="Library_stl_cpp_library">10.4 STL/C++ library</a></H2>
+<H2><a name="Library_stl_cpp_library">11.4 STL/C++ library</a></H2>
 
 
 <p>
@@ -1420,7 +1420,7 @@ Please look for the library files in the appropriate language library directory.
 </p>
 
 
-<H3><a name="Library_std_string">10.4.1 std::string</a></H3>
+<H3><a name="Library_std_string">11.4.1 std::string</a></H3>
 
 
 <p>
@@ -1504,7 +1504,7 @@ void foo(string s, const String &amp;t);     // std_string typemaps still applie
 </pre>
 </div>
 
-<H3><a name="Library_std_vector">10.4.2 std::vector</a></H3>
+<H3><a name="Library_std_vector">11.4.2 std::vector</a></H3>
 
 
 <p>
@@ -1683,7 +1683,7 @@ if you want to make their head explode.
 details and the public API exposed to the interpreter vary.
 </p>
 
-<H3><a name="Library_stl_exceptions">10.4.3 STL exceptions</a></H3>
+<H3><a name="Library_stl_exceptions">11.4.3 STL exceptions</a></H3>
 
 
 <p>
@@ -1733,10 +1733,10 @@ The <tt>%exception</tt> directive can be used by placing the following code befo
 Any thrown STL exceptions will then be gracefully handled instead of causing a crash.
 </p>
 
-<H3><a name="Library_std_shared_ptr">10.4.4 shared_ptr smart pointer</a></H3>
+<H3><a name="Library_std_shared_ptr">11.4.4 shared_ptr smart pointer</a></H3>
 
 
-<H4><a name="Library_shared_ptr_basics">10.4.4.1 shared_ptr basics</a></H4>
+<H4><a name="Library_shared_ptr_basics">11.4.4.1 shared_ptr basics</a></H4>
 
 
 <p>
@@ -1832,7 +1832,7 @@ System.out.println(val1 + " " + val2);
 </pre>
 </div>
 
-<H4><a name="Library_shared_ptr_inheritance">10.4.4.2 shared_ptr and inheritance</a></H4>
+<H4><a name="Library_shared_ptr_inheritance">11.4.4.2 shared_ptr and inheritance</a></H4>
 
 
 <p>
@@ -1923,7 +1923,7 @@ Adding the missing <tt>%shared_ptr</tt> macros will fix this:
 </pre>
 </div>
 
-<H4><a name="Library_shared_ptr_overloading">10.4.4.3 shared_ptr and method overloading</a></H4>
+<H4><a name="Library_shared_ptr_overloading">11.4.4.3 shared_ptr and method overloading</a></H4>
 
 
 <p>
@@ -1945,7 +1945,7 @@ SWIG will choose to wrap just the first method by default.
 For the interested reader, SWIG detects that they are equivalent types via the <a href=Typemaps.html#Typemaps_typecheck_pointer>typecheck typemaps</a> in the shared_ptr library.
 </p>
 
-<H4><a name="Library_shared_ptr_templates">10.4.4.4 shared_ptr and templates</a></H4>
+<H4><a name="Library_shared_ptr_templates">11.4.4.4 shared_ptr and templates</a></H4>
 
 
 <p>
@@ -1987,7 +1987,7 @@ The SWIG code below shows the required ordering:
 </pre>
 </div>
 
-<H4><a name="Library_shared_ptr_directors">10.4.4.5 shared_ptr and directors</a></H4>
+<H4><a name="Library_shared_ptr_directors">11.4.4.5 shared_ptr and directors</a></H4>
 
 
 <p>
@@ -1995,7 +1995,7 @@ The languages that support shared_ptr also have support for using shared_ptr wit
 </p>
 
 
-<H3><a name="Library_std_auto_ptr">10.4.5 auto_ptr smart pointer</a></H3>
+<H3><a name="Library_std_auto_ptr">11.4.5 auto_ptr smart pointer</a></H3>
 
 
 <p>
@@ -2044,10 +2044,10 @@ int value = k.getValue();
 </pre>
 </div>
 
-<H2><a name="Library_nn16">10.5 Utility Libraries</a></H2>
+<H2><a name="Library_nn16">11.5 Utility Libraries</a></H2>
 
 
-<H3><a name="Library_nn17">10.5.1 exception.i</a></H3>
+<H3><a name="Library_nn17">11.5.1 exception.i</a></H3>
 
 
 <p>
diff --git a/Doc/Manual/Lua.html b/Doc/Manual/Lua.html
index 90bcc5a00..0fa1ecb13 100644
--- a/Doc/Manual/Lua.html
+++ b/Doc/Manual/Lua.html
@@ -7,7 +7,7 @@
 </head>
 
 <body bgcolor="#ffffff">
-<H1><a name="Lua">27 SWIG and Lua</a></H1>
+<H1><a name="Lua">28 SWIG and Lua</a></H1>
 <!-- INDEX -->
 <div class="sectiontoc">
 <ul>
@@ -83,14 +83,14 @@ Lua is an extension programming language designed to support general procedural
 eLua stands for Embedded Lua (can be thought of as a flavor of Lua) and offers the full implementation of the Lua programming language to the embedded world, extending it with specific features for efficient and portable software embedded development. eLua runs on smaller devices like microcontrollers and provides the full features of the regular Lua desktop version. More information on eLua can be found here: <a href="http://www.eluaproject.net">http://www.eluaproject.net</a>
 </p>
 
-<H2><a name="Lua_nn2">27.1 Preliminaries</a></H2>
+<H2><a name="Lua_nn2">28.1 Preliminaries</a></H2>
 
 
 <p>
 The current SWIG implementation is designed to work with Lua 5.0.x, 5.1.x and 5.2.x. It should work with later versions of Lua, but certainly not with Lua 4.0 due to substantial API changes. It is possible to either static link or dynamic link a Lua module into the interpreter (normally Lua static links its libraries, as dynamic linking is not available on all platforms). SWIG also has support for eLua starting from eLua 0.8. Due to substantial changes between SWIG 2.x and SWIG 3.0 and unavailability of testing platform, eLua status was downgraded to 'experimental'.
 </p>
 
-<H2><a name="Lua_nn3">27.2 Running SWIG</a></H2>
+<H2><a name="Lua_nn3">28.2 Running SWIG</a></H2>
 
 
 <p>
@@ -138,7 +138,7 @@ $ swig -lua -eluac example.i
 The <tt>-elua</tt> option puts all the C function wrappers and variable get/set wrappers in rotables. It also generates a metatable which will control the access to these variables from eLua. It also offers a significant amount of module size compression. On the other hand, the <tt>-eluac</tt> option puts all the wrappers in a single rotable. With this option, no matter how huge the module, it will consume no additional microcontroller SRAM (crass compression). There is a catch though: Metatables are not generated with <tt>-eluac</tt>. To access any value from eLua, one must directly call the wrapper function associated with that value.
 </p>
 
-<H3><a name="Lua_commandline">27.2.1 Additional command line options</a></H3>
+<H3><a name="Lua_commandline">28.2.1 Additional command line options</a></H3>
 
 
 <p>
@@ -179,7 +179,7 @@ swig -lua -help
 </tr>
 </table>
 
-<H3><a name="Lua_nn4">27.2.2 Compiling and Linking and Interpreter</a></H3>
+<H3><a name="Lua_nn4">28.2.2 Compiling and Linking and Interpreter</a></H3>
 
 
 <p>
@@ -250,7 +250,7 @@ LUALIB_API int ( luaopen_mod )(lua_State *L );
 More information on building and configuring eLua can be found here: <a href="http://www.eluaproject.net/doc/v0.8/en_building.html">http://www.eluaproject.net/doc/v0.8/en_building.html</a>
 </p>
 
-<H3><a name="Lua_nn5">27.2.3 Compiling a dynamic module</a></H3>
+<H3><a name="Lua_nn5">28.2.3 Compiling a dynamic module</a></H3>
 
 
 <p>
@@ -318,7 +318,7 @@ Is quite obvious (Go back and consult the Lua documents on how to enable loadlib
 
 
 
-<H3><a name="Lua_nn6">27.2.4 Using your module</a></H3>
+<H3><a name="Lua_nn6">28.2.4 Using your module</a></H3>
 
 
 <p>
@@ -336,19 +336,19 @@ $ ./my_lua
 &gt;
 </pre></div>
 
-<H2><a name="Lua_nn7">27.3 A tour of basic C/C++ wrapping</a></H2>
+<H2><a name="Lua_nn7">28.3 A tour of basic C/C++ wrapping</a></H2>
 
 
 <p>
 By default, SWIG tries to build a very natural Lua interface to your C/C++ code. This section briefly covers the essential aspects of this wrapping.
 </p>
-<H3><a name="Lua_nn8">27.3.1 Modules</a></H3>
+<H3><a name="Lua_nn8">28.3.1 Modules</a></H3>
 
 
 <p>
 The SWIG module directive specifies the name of the Lua module. If you specify `module example', then everything is wrapped into a Lua table 'example' containing all the functions and variables. When choosing a module name, make sure you don't use the same name as a built-in Lua command or standard module name.
 </p>
-<H3><a name="Lua_nn9">27.3.2 Functions</a></H3>
+<H3><a name="Lua_nn9">28.3.2 Functions</a></H3>
 
 
 <p>
@@ -389,7 +389,7 @@ It is also possible to rename the module with an assignment.
 24
 </pre></div>
 
-<H3><a name="Lua_nn10">27.3.3 Global variables</a></H3>
+<H3><a name="Lua_nn10">28.3.3 Global variables</a></H3>
 
 
 <p>
@@ -477,7 +477,7 @@ If you have used the <tt>-eluac</tt> option for your eLua module, you will have
 In general, functions of the form <tt>"variable_get()"</tt> and <tt>"variable_set()"</tt> are automatically generated by SWIG for use with <tt>-eluac</tt>.
 </p>
 
-<H3><a name="Lua_nn11">27.3.4 Constants and enums</a></H3>
+<H3><a name="Lua_nn11">28.3.4 Constants and enums</a></H3>
 
 
 <p>
@@ -512,7 +512,7 @@ If you're using eLua and have used <tt>-elua</tt> or <tt>-eluac</tt> to generate
 Hello World
 </pre></div>
 
-<H4><a name="Lua_nn13">27.3.4.1 Constants/enums and classes/structures</a></H4>
+<H4><a name="Lua_nn13">28.3.4.1 Constants/enums and classes/structures</a></H4>
 
 
 <p>
@@ -568,7 +568,7 @@ If the <tt>-no-old-metatable-bindings</tt> option is used, then these old-style
 It is worth mentioning, that <tt>example.Test.TEST1</tt> and <tt>example.Test_TEST1</tt> are different entities and changing one does not change the other. 
 Given the fact that these are constantes and they are not supposed to be changed, it is up to you to avoid such issues.
 </p>
-<H3><a name="Lua_nn12">27.3.5 Pointers</a></H3>
+<H3><a name="Lua_nn12">28.3.5 Pointers</a></H3>
 
 
 <p>
@@ -606,7 +606,7 @@ Lua enforces the integrity of its userdata, so it is virtually impossible to cor
 nil
 </pre></div>
 
-<H3><a name="Lua_structures">27.3.6 Structures</a></H3>
+<H3><a name="Lua_structures">28.3.6 Structures</a></H3>
 
 
 <p>
@@ -710,7 +710,7 @@ For eLua with the <tt>-eluac</tt> option, structure manipulation has to be perfo
 In general, functions of the form <tt>"new_struct()"</tt>, <tt>"struct_member_get()"</tt>, <tt>"struct_member_set()"</tt> and <tt>"free_struct()"</tt> are automatically generated by SWIG for each structure defined in C. (Please note: This doesn't apply for modules generated with the <tt>-elua</tt> option)
 </p>
 
-<H3><a name="Lua_nn14">27.3.7 C++ classes</a></H3>
+<H3><a name="Lua_nn14">28.3.7 C++ classes</a></H3>
 
 
 <p>
@@ -785,7 +785,7 @@ Both style names are generated by default now.
 However, if the <tt>-no-old-metatable-bindings</tt> option is used, then the backward compatible names are not generated in addition to ordinary ones.
 </p>
 
-<H3><a name="Lua_nn15">27.3.8 C++ inheritance</a></H3>
+<H3><a name="Lua_nn15">28.3.8 C++ inheritance</a></H3>
 
 
 <p>
@@ -810,7 +810,7 @@ then the function <tt>spam()</tt> accepts a Foo pointer or a pointer to any clas
 <p>
 It is safe to use multiple inheritance with SWIG.
 </p>
-<H3><a name="Lua_nn16">27.3.9 Pointers, references, values, and arrays</a></H3>
+<H3><a name="Lua_nn16">28.3.9 Pointers, references, values, and arrays</a></H3>
 
 
 <p>
@@ -841,7 +841,7 @@ Foo  spam7();
 <p>
 then all three functions will return a pointer to some Foo object. Since the third function (spam7) returns a value, newly allocated memory is used to hold the result and a pointer is returned (Lua will release this memory when the return value is garbage collected). The other two are pointers which are assumed to be managed by the C code and so will not be garbage collected.
 </p>
-<H3><a name="Lua_nn17">27.3.10 C++ overloaded functions</a></H3>
+<H3><a name="Lua_nn17">28.3.10 C++ overloaded functions</a></H3>
 
 
 <p>
@@ -927,7 +927,7 @@ Please refer to the "SWIG and C++" chapter for more information about overloadin
 <p>
 Dealing with the Lua coercion mechanism, the priority is roughly (integers, floats, strings, userdata). But it is better to rename the functions rather than rely upon the ordering.
 </p>
-<H3><a name="Lua_nn18">27.3.11 C++ operators</a></H3>
+<H3><a name="Lua_nn18">28.3.11 C++ operators</a></H3>
 
 
 <p>
@@ -1059,7 +1059,7 @@ operators and pseudo-operators):</p>
 </ul>
 <p>No other lua metafunction is inherited. For example, __gc is not inherited and must be redefined in every class. <tt>__tostring</tt> is subject to a special handling. If absent in class and in class bases, a default one will be provided by SWIG.
 </p>
-<H3><a name="Lua_nn19">27.3.12 Class extension with %extend</a></H3>
+<H3><a name="Lua_nn19">28.3.12 Class extension with %extend</a></H3>
 
 
 <p>
@@ -1116,7 +1116,7 @@ true
 Extend works with both C and C++ code, on classes and structs. It does not modify the underlying object in any way---the extensions only show up in the Lua interface. The only item to take note of is the code has to use the '$self' instead of 'this', and that you cannot access protected/private members of the code (as you are not officially part of the class).
 </p>
 
-<H3><a name="Lua_nn20">27.3.13 Using %newobject to release memory</a></H3>
+<H3><a name="Lua_nn20">28.3.13 Using %newobject to release memory</a></H3>
 
 
 <p> If you have a function that allocates memory like this,</p>
@@ -1140,7 +1140,7 @@ char *foo();
 </div>
 <p> This will release the allocated memory.</p>
 
-<H3><a name="Lua_nn21">27.3.14 C++ templates</a></H3>
+<H3><a name="Lua_nn21">28.3.14 C++ templates</a></H3>
 
 
 <p>
@@ -1175,7 +1175,7 @@ In Lua:
 <p>
 Obviously, there is more to template wrapping than shown in this example. More details can be found in the SWIG and C++ chapter. Some more complicated examples will appear later.
 </p>
-<H3><a name="Lua_nn22">27.3.15 C++ Smart Pointers</a></H3>
+<H3><a name="Lua_nn22">28.3.15 C++ Smart Pointers</a></H3>
 
 
 <p>
@@ -1227,7 +1227,7 @@ If you ever need to access the underlying pointer returned by <tt>operator-&gt;(
 &gt; f = p:__deref__()     -- Returns underlying Foo *
 </pre></div>
 
-<H3><a name="Lua_nn23">27.3.16 C++ Exceptions</a></H3>
+<H3><a name="Lua_nn23">28.3.16 C++ Exceptions</a></H3>
 
 
 <p>
@@ -1370,7 +1370,7 @@ and the "<a href="Customization.html#Customization_exception">Exception handling
 add exception specification to functions or globally (respectively).
 </p>
 
-<H3><a name="Lua_namespaces">27.3.17 Namespaces </a></H3>
+<H3><a name="Lua_namespaces">28.3.17 Namespaces </a></H3>
 
 
 <p>
@@ -1421,7 +1421,7 @@ Now, from Lua usage is as follows:
 19
 &gt;
 </pre></div>
-<H4><a name="Lua_nn27">27.3.17.1 Compatibility Note </a></H4>
+<H4><a name="Lua_nn27">28.3.17.1 Compatibility Note </a></H4>
 
 
 <p>
@@ -1437,7 +1437,7 @@ If SWIG is running in a backwards compatible way, i.e. without the <tt>-no-old-m
 </pre></div>
 
 
-<H4><a name="Lua_nn29">27.3.17.2 Names </a></H4>
+<H4><a name="Lua_nn29">28.3.17.2 Names </a></H4>
 
 
 <p> If SWIG is launched without <tt>-no-old-metatable-bindings</tt> option, then it enters backward-compatible mode. While in this mode, it tries
@@ -1481,7 +1481,7 @@ surrounding scope without any prefixing. Pretending that Test2 is a struct, not
 &gt;
 </pre></div>
 
-<H4><a name="Lua_nn30">27.3.17.3 Inheritance </a></H4>
+<H4><a name="Lua_nn30">28.3.17.3 Inheritance </a></H4>
 
 
 <p> The internal organization of inheritance has changed. 
@@ -1522,12 +1522,12 @@ function
 &gt;
 </pre></div>
 
-<H2><a name="Lua_nn24">27.4 Typemaps</a></H2>
+<H2><a name="Lua_nn24">28.4 Typemaps</a></H2>
 
 
 <p>This section explains what typemaps are and how to use them. The default wrapping behaviour of SWIG is enough in most cases. However sometimes SWIG may need a little additional assistance to know which typemap to apply to provide the best wrapping. This section will be explaining how to use typemaps to best effect</p>
 
-<H3><a name="Lua_nn25">27.4.1 What is a typemap?</a></H3>
+<H3><a name="Lua_nn25">28.4.1 What is a typemap?</a></H3>
 
 
 <p>A typemap is nothing more than a code generation rule that is attached to a specific C datatype. For example, to convert integers from Lua to C, you might define a typemap like this:</p>
@@ -1555,7 +1555,7 @@ Received an integer : 6
 720
 </pre></div>
 
-<H3><a name="Lua_nn26">27.4.2 Using typemaps</a></H3>
+<H3><a name="Lua_nn26">28.4.2 Using typemaps</a></H3>
 
 
 <p>There are many ready written typemaps built into SWIG for all common types (int, float, short, long, char*, enum and more), which SWIG uses automatically, with no effort required on your part.</p>
@@ -1608,7 +1608,7 @@ void swap(int *sx, int *sy);
 
 <p>Note: C++ references must be handled exactly the same way. However SWIG will automatically wrap a <tt>const int&amp;</tt>  as an input parameter (since that it obviously input).</p>
 
-<H3><a name="Lua_typemap_arrays">27.4.3 Typemaps and arrays</a></H3>
+<H3><a name="Lua_typemap_arrays">28.4.3 Typemaps and arrays</a></H3>
 
 
 <p>Arrays present a challenge for SWIG, because like pointers SWIG does not know whether these are input or output values, nor
@@ -1672,7 +1672,7 @@ and Lua tables to be 1..N, (the indexing follows the norm for the language). In
 
 <p>Note: SWIG also can support arrays of pointers in a similar manner.</p>
 
-<H3><a name="Lua_typemaps_ptr_ptr_functions">27.4.4 Typemaps and pointer-pointer functions</a></H3>
+<H3><a name="Lua_typemaps_ptr_ptr_functions">28.4.4 Typemaps and pointer-pointer functions</a></H3>
 
 
 <p>Several C++ libraries use a pointer-pointer functions to create its objects. These functions require a pointer to a pointer which is then filled with the pointer to the new object. Microsoft's COM and DirectX as well as many other libraries have this kind of function. An example is given below:</p>
@@ -1706,7 +1706,7 @@ int Create_Math(iMath** pptr); // its creator (assume it mallocs)
 ptr=nil -- the iMath* will be GC'ed as normal
 </pre></div>
 
-<H2><a name="Lua_writing_typemaps">27.5 Writing typemaps</a></H2>
+<H2><a name="Lua_writing_typemaps">28.5 Writing typemaps</a></H2>
 
 
 <p>This section describes how you can modify SWIG's default wrapping behavior for various C/C++ datatypes using the <tt>%typemap</tt> directive. This is an advanced topic that assumes familiarity with the Lua C API as well as the material in the "<a href="Typemaps.html#Typemaps">Typemaps</a>" chapter.</p>
@@ -1715,7 +1715,7 @@ ptr=nil -- the iMath* will be GC'ed as normal
 
 <p>Before proceeding, you should read the previous section on using typemaps, and look at the existing typemaps found in luatypemaps.swg and typemaps.i. These are both well documented and fairly easy to read. You should not attempt to write your own typemaps until you have read and can understand both of these files (they may well also give you an idea to base your work on).</p>
 
-<H3><a name="Lua_typemaps_write">27.5.1 Typemaps you can write</a></H3>
+<H3><a name="Lua_typemaps_write">28.5.1 Typemaps you can write</a></H3>
 
 
 <p>There are many different types of typemap that can be written, the full list can be found in the "<a href="Typemaps.html#Typemaps">Typemaps</a>" chapter. However the following are the most commonly used ones.</p>
@@ -1728,7 +1728,7 @@ ptr=nil -- the iMath* will be GC'ed as normal
 (the syntax for the typecheck is different from the typemap, see typemaps for details).</li>
 </ul>
 
-<H3><a name="Lua_nn31">27.5.2 SWIG's Lua-C API</a></H3>
+<H3><a name="Lua_nn31">28.5.2 SWIG's Lua-C API</a></H3>
 
 
 <p>This section explains the SWIG specific Lua-C API. It does not cover the main Lua-C api, as this is well documented and not worth covering.</p>
@@ -1777,7 +1777,7 @@ This macro, when called within the context of a SWIG wrapped function, will disp
 <div class="indent">
 Similar to SWIG_fail_arg, except that it will display the swig_type_info information instead.</div>
 
-<H2><a name="Lua_nn32">27.6 Customization of your Bindings</a></H2>
+<H2><a name="Lua_nn32">28.6 Customization of your Bindings</a></H2>
 
 
 <p>
@@ -1786,7 +1786,7 @@ This section covers adding of some small extra bits to your module to add the la
 
 
 
-<H3><a name="Lua_nn33">27.6.1 Writing your own custom wrappers</a></H3>
+<H3><a name="Lua_nn33">28.6.1 Writing your own custom wrappers</a></H3>
 
 
 <p>
@@ -1805,7 +1805,7 @@ int native_function(lua_State*L) // my native code
 The <tt>%native</tt> directive in the above example, tells SWIG that there is a function <tt>int native_function(lua_State*L);</tt> which is to be added into the module under the name '<tt>my_func</tt>'. SWIG will not add any wrapper for this function, beyond adding it into the function table. How you write your code is entirely up to you.
 </p>
 
-<H3><a name="Lua_nn34">27.6.2 Adding additional Lua code</a></H3>
+<H3><a name="Lua_nn34">28.6.2 Adding additional Lua code</a></H3>
 
 
 <p>
@@ -1843,7 +1843,7 @@ Good uses for this feature is adding of new code, or writing helper functions to
 See Examples/lua/arrays for an example of this code.
 </p>
 
-<H2><a name="Lua_nn35">27.7 Details on the Lua binding</a></H2>
+<H2><a name="Lua_nn35">28.7 Details on the Lua binding</a></H2>
 
 
 <p>
@@ -1854,7 +1854,7 @@ See Examples/lua/arrays for an example of this code.
  </i>
 </p>
 
-<H3><a name="Lua_nn36">27.7.1 Binding global data into the module.</a></H3>
+<H3><a name="Lua_nn36">28.7.1 Binding global data into the module.</a></H3>
 
 
 <p>
@@ -1914,7 +1914,7 @@ end
 <p>
 That way when you call '<tt>a=example.Foo</tt>', the interpreter looks at the table 'example' sees that there is no field 'Foo' and calls __index. This will in turn check in '.get' table and find the existence of 'Foo' and then return the value of the C function call 'Foo_get()'. Similarly for the code '<tt>example.Foo=10</tt>', the interpreter will check the table, then call the __newindex which will then check the '.set' table and call the C function 'Foo_set(10)'.
 </p>
-<H3><a name="Lua_nn37">27.7.2 Userdata and Metatables</a></H3>
+<H3><a name="Lua_nn37">28.7.2 Userdata and Metatables</a></H3>
 
 
 <p>
@@ -1994,7 +1994,7 @@ Note: Both the opaque structures (like the FILE*) and normal wrapped classes/str
 <p>
 Note: Operator overloads are basically done in the same way, by adding functions such as '__add' &amp; '__call' to the class' metatable. The current implementation is a bit rough as it will add any member function beginning with '__' into the metatable too, assuming its an operator overload.
 </p>
-<H3><a name="Lua_nn38">27.7.3 Memory management</a></H3>
+<H3><a name="Lua_nn38">28.7.3 Memory management</a></H3>
 
 
 <p>
diff --git a/Doc/Manual/Modules.html b/Doc/Manual/Modules.html
index 19b69e5f4..7efd74e2b 100644
--- a/Doc/Manual/Modules.html
+++ b/Doc/Manual/Modules.html
@@ -7,7 +7,7 @@
 </head>
 
 <body bgcolor="#ffffff">
-<H1><a name="Modules">18 Working with Modules</a></H1>
+<H1><a name="Modules">19 Working with Modules</a></H1>
 <!-- INDEX -->
 <div class="sectiontoc">
 <ul>
@@ -24,7 +24,7 @@
 
 
 
-<H2><a name="Modules_introduction">18.1 Modules Introduction</a></H2>
+<H2><a name="Modules_introduction">19.1 Modules Introduction</a></H2>
 
 
 <p>
@@ -78,7 +78,7 @@ where you want to create a collection of modules.
 Each module in the collection is created via separate invocations of SWIG.
 </p>
 
-<H2><a name="Modules_nn1">18.2 Basics</a></H2>
+<H2><a name="Modules_nn1">19.2 Basics</a></H2>
 
 
 <p>
@@ -177,7 +177,7 @@ in parallel from multiple threads as SWIG provides no locking - for more on that
 issue, read on.
 </p>
 
-<H2><a name="Modules_nn2">18.3 The SWIG runtime code</a></H2>
+<H2><a name="Modules_nn2">19.3 The SWIG runtime code</a></H2>
 
 
 <p>
@@ -243,7 +243,7 @@ can peacefully coexist. So the type structures are separated by the
 is empty. Only modules compiled with the same pair will share type information.
 </p>
 
-<H2><a name="Modules_external_run_time">18.4 External access to the runtime</a></H2>
+<H2><a name="Modules_external_run_time">19.4 External access to the runtime</a></H2>
 
 
 <p>As described in <a href="Typemaps.html#Typemaps_runtime_type_checker">The run-time type checker</a>,
@@ -282,7 +282,7 @@ SWIG_TYPE_TABLE to be the same as the module whose types you are trying to
 access.
 </p>
 
-<H2><a name="Modules_nn4">18.5 A word of caution about static libraries</a></H2>
+<H2><a name="Modules_nn4">19.5 A word of caution about static libraries</a></H2>
 
 
 <p>
@@ -293,7 +293,7 @@ into it. This is very often <b>NOT</b> what you want and it can lead to unexpect
 behavior. When working with dynamically loadable modules, you should try to work exclusively with shared libraries.
 </p>
 
-<H2><a name="Modules_nn5">18.6 References</a></H2>
+<H2><a name="Modules_nn5">19.6 References</a></H2>
 
 
 <p>
@@ -301,7 +301,7 @@ Due to the complexity of working with shared libraries and multiple modules, it
 an outside reference.  John Levine's "Linkers and Loaders" is highly recommended.
 </p>
 
-<H2><a name="Modules_nn6">18.7 Reducing the wrapper file size</a></H2>
+<H2><a name="Modules_nn6">19.7 Reducing the wrapper file size</a></H2>
 
 
 <p>
diff --git a/Doc/Manual/Ocaml.html b/Doc/Manual/Ocaml.html
index 11d21ce1b..8e456b9e6 100644
--- a/Doc/Manual/Ocaml.html
+++ b/Doc/Manual/Ocaml.html
@@ -7,7 +7,7 @@
 </head>
 
 <body bgcolor="#ffffff">
-<H1><a name="Ocaml">28 SWIG and OCaml</a></H1>
+<H1><a name="Ocaml">38 SWIG and OCaml</a></H1>
 <!-- INDEX -->
 <div class="sectiontoc">
 <ul>
@@ -88,7 +88,7 @@ If you're not familiar with the Objective Caml language, you can visit
 <a href="http://ocaml.org/">The Ocaml Website</a>.
 </p>
 
-<H2><a name="Ocaml_nn2">28.1 Preliminaries</a></H2>
+<H2><a name="Ocaml_nn2">38.1 Preliminaries</a></H2>
 
 
 <p>
@@ -106,7 +106,7 @@ file Examples/Makefile illustrate how to compile and link SWIG modules that
 will be loaded dynamically.  This has only been tested on Linux so far.
 </p>
 
-<H3><a name="Ocaml_nn3">28.1.1 Running SWIG</a></H3>
+<H3><a name="Ocaml_nn3">38.1.1 Running SWIG</a></H3>
 
 
 <p>
@@ -129,7 +129,7 @@ you will compile the file <tt>example_wrap.c</tt> with <tt>ocamlc</tt> or
 the resulting .ml and .mli files as well, and do the final link with -custom
 (not needed for native link).</p>
 
-<H3><a name="Ocaml_nn4">28.1.2 Compiling the code</a></H3>
+<H3><a name="Ocaml_nn4">38.1.2 Compiling the code</a></H3>
 
 
 <p>
@@ -166,7 +166,7 @@ in C++ mode, you must:</p>
 </pre>
 </div>
 
-<H3><a name="Ocaml_nn5">28.1.3 The camlp4 module</a></H3>
+<H3><a name="Ocaml_nn5">38.1.3 The camlp4 module</a></H3>
 
 
 <p>
@@ -242,7 +242,7 @@ let b = C_string (getenv "PATH")
 </td></tr>
 </table>
 
-<H3><a name="Ocaml_nn6">28.1.4 Using your module</a></H3>
+<H3><a name="Ocaml_nn6">38.1.4 Using your module</a></H3>
 
 
 <p>
@@ -256,7 +256,7 @@ option to build your functions into the primitive list. This
 option is not needed when you build native code.
 </p>
 
-<H3><a name="Ocaml_nn7">28.1.5 Compilation problems and compiling with C++</a></H3>
+<H3><a name="Ocaml_nn7">38.1.5 Compilation problems and compiling with C++</a></H3>
 
 
 <p>
@@ -267,7 +267,7 @@ liberal with pointer types may not compile under the C++ compiler.
 Most code meant to be compiled as C++ will not have problems.
 </p>
 
-<H2><a name="Ocaml_nn8">28.2 The low-level Ocaml/C interface</a></H2>
+<H2><a name="Ocaml_nn8">38.2 The low-level Ocaml/C interface</a></H2>
 
 
 <p>
@@ -367,7 +367,7 @@ value items pass through directly, but you must make your own type
 signature for a function that uses value in this way.
 </p>
 
-<H3><a name="Ocaml_nn9">28.2.1 The generated module</a></H3>
+<H3><a name="Ocaml_nn9">38.2.1 The generated module</a></H3>
 
 
 <p>
@@ -401,7 +401,7 @@ it describes the output SWIG will generate for class definitions.
 </td></tr>
 </table>
 
-<H3><a name="Ocaml_nn10">28.2.2 Enums</a></H3>
+<H3><a name="Ocaml_nn10">38.2.2 Enums</a></H3>
 
 
 <p>
@@ -464,7 +464,7 @@ val x : Enum_test.c_obj = C_enum `a
 </pre>
 </div>
 
-<H4><a name="Ocaml_nn11">28.2.2.1 Enum typing in Ocaml</a></H4>
+<H4><a name="Ocaml_nn11">38.2.2.1 Enum typing in Ocaml</a></H4>
 
 
 <p>
@@ -477,10 +477,10 @@ functions imported from different modules.  You must convert values to master
 values using the swig_val function before sharing them with another module.
 </p>
 
-<H3><a name="Ocaml_nn12">28.2.3 Arrays</a></H3>
+<H3><a name="Ocaml_nn12">38.2.3 Arrays</a></H3>
 
 
-<H4><a name="Ocaml_nn13">28.2.3.1 Simple types of bounded arrays</a></H4>
+<H4><a name="Ocaml_nn13">38.2.3.1 Simple types of bounded arrays</a></H4>
 
 
 <p>
@@ -501,7 +501,7 @@ arrays of simple types with known bounds in your code, but this only works
 for arrays whose bounds are completely specified.
 </p>
 
-<H4><a name="Ocaml_nn14">28.2.3.2 Complex and unbounded arrays</a></H4>
+<H4><a name="Ocaml_nn14">38.2.3.2 Complex and unbounded arrays</a></H4>
 
 
 <p>
@@ -514,7 +514,7 @@ SWIG can't predict which of these methods will be used in the array,
 so you have to specify it for yourself in the form of a typemap.
 </p>
 
-<H4><a name="Ocaml_nn15">28.2.3.3 Using an object</a></H4>
+<H4><a name="Ocaml_nn15">38.2.3.3 Using an object</a></H4>
 
 
 <p>
@@ -528,7 +528,7 @@ Consider writing an object when the ending condition of your array is complex,
 such as using a required sentinel, etc.
 </p>
 
-<H4><a name="Ocaml_nn16">28.2.3.4 Example typemap for a function taking float * and int</a></H4>
+<H4><a name="Ocaml_nn16">38.2.3.4 Example typemap for a function taking float * and int</a></H4>
 
 
 <p>
@@ -579,7 +579,7 @@ void printfloats( float *tab, int len );
 </pre></td></tr></table>
 
 
-<H3><a name="Ocaml_nn17">28.2.4 C++ Classes</a></H3>
+<H3><a name="Ocaml_nn17">38.2.4 C++ Classes</a></H3>
 
 
 <p>
@@ -622,7 +622,7 @@ the underlying pointer, so using create_[x]_from_ptr alters the
 returned value for the same object.
 </p>
 
-<H4><a name="Ocaml_nn18">28.2.4.1 STL vector and string Example</a></H4>
+<H4><a name="Ocaml_nn18">38.2.4.1 STL vector and string Example</a></H4>
 
 
 <p>
@@ -702,7 +702,7 @@ baz
 #
 </pre></div>
 
-<H4><a name="Ocaml_nn19">28.2.4.2 C++ Class Example</a></H4>
+<H4><a name="Ocaml_nn19">38.2.4.2 C++ Class Example</a></H4>
 
 
 <p>
@@ -732,7 +732,7 @@ public:
 };
 </pre></td></tr></table>
 
-<H4><a name="Ocaml_nn20">28.2.4.3 Compiling the example</a></H4>
+<H4><a name="Ocaml_nn20">38.2.4.3 Compiling the example</a></H4>
 
 
 <div class="code"><pre>
@@ -750,7 +750,7 @@ bash-2.05a$ ocamlmktop -custom swig.cmo -I `camlp4 -where` \
   -L$QTPATH/lib -cclib -lqt
 </pre></div>
 
-<H4><a name="Ocaml_nn21">28.2.4.4 Sample Session</a></H4>
+<H4><a name="Ocaml_nn21">38.2.4.4 Sample Session</a></H4>
 
 
 <div class="code"><pre>
@@ -777,10 +777,10 @@ Assuming you have a working installation of QT, you will see a window
 containing the string "hi" in a button.
 </p>
 
-<H3><a name="Ocaml_nn22">28.2.5 Director Classes</a></H3>
+<H3><a name="Ocaml_nn22">38.2.5 Director Classes</a></H3>
 
 
-<H4><a name="Ocaml_nn23">28.2.5.1 Director Introduction</a></H4>
+<H4><a name="Ocaml_nn23">38.2.5.1 Director Introduction</a></H4>
 
 
 <p>
@@ -807,7 +807,7 @@ class foo {
 };
 </pre></div>
 
-<H4><a name="Ocaml_nn24">28.2.5.2 Overriding Methods in Ocaml</a></H4>
+<H4><a name="Ocaml_nn24">38.2.5.2 Overriding Methods in Ocaml</a></H4>
 
 
 <p>
@@ -835,7 +835,7 @@ In this example, I'll examine the objective caml code involved in providing
 an overloaded class.  This example is contained in Examples/ocaml/shapes.
 </p>
 
-<H4><a name="Ocaml_nn25">28.2.5.3 Director Usage Example</a></H4>
+<H4><a name="Ocaml_nn25">38.2.5.3 Director Usage Example</a></H4>
 
 
 <table border="1" bgcolor="#dddddd" summary="Director usage example">
@@ -896,7 +896,7 @@ in a more effortless style in ocaml, while leaving the "engine" part of the
 program in C++.
 </p>
 
-<H4><a name="Ocaml_nn26">28.2.5.4 Creating director objects</a></H4>
+<H4><a name="Ocaml_nn26">38.2.5.4 Creating director objects</a></H4>
 
 
 <p>
@@ -937,7 +937,7 @@ object from causing a core dump, as long as the object is destroyed
 properly.
 </p>
 
-<H4><a name="Ocaml_nn27">28.2.5.5 Typemaps for directors, directorin, directorout, directorargout</a></H4>
+<H4><a name="Ocaml_nn27">38.2.5.5 Typemaps for directors, directorin, directorout, directorargout</a></H4>
 
 
 <p>
@@ -948,7 +948,7 @@ well as a function return value in the same way you provide function arguments,
 and to receive arguments the same way you normally receive function returns.
 </p>
 
-<H4><a name="Ocaml_nn28">28.2.5.6 typemap</a></H4>
+<H4><a name="Ocaml_nn28">38.2.5.6 typemap</a></H4>
 
 
 <p>
@@ -959,7 +959,7 @@ code receives when you are called.  In general, a simple <tt>directorin</tt> typ
 can use the same body as a simple <tt>out</tt> typemap.
 </p>
 
-<H4><a name="Ocaml_nn29">28.2.5.7 directorout typemap</a></H4>
+<H4><a name="Ocaml_nn29">38.2.5.7 directorout typemap</a></H4>
 
 
 <p>
@@ -970,7 +970,7 @@ for the same type, except when there are special requirements for object
 ownership, etc.
 </p>
 
-<H4><a name="Ocaml_nn30">28.2.5.8 directorargout typemap</a></H4>
+<H4><a name="Ocaml_nn30">38.2.5.8 directorargout typemap</a></H4>
 
 
 <p>
@@ -987,7 +987,7 @@ In the event that you don't specify all of the necessary values, integral
 values will read zero, and struct or object returns have undefined results.
 </p>
 
-<H3><a name="Ocaml_nn31">28.2.6 Exceptions</a></H3>
+<H3><a name="Ocaml_nn31">38.2.6 Exceptions</a></H3>
 
 
 <p>
@@ -996,7 +996,7 @@ but not too useful example is provided by the throw_exception testcase in
 Examples/test-suite.  You can provide your own exceptions, too.
 </p>
 
-<H2><a name="Ocaml_nn32">28.3 Documentation Features</a></H2>
+<H2><a name="Ocaml_nn32">38.3 Documentation Features</a></H2>
 
 
 <p>
@@ -1005,7 +1005,7 @@ comments (colloquially referred to as "docstrings") that can be read by
 <a href="https://caml.inria.fr/pub/docs/manual-ocaml/ocamldoc.html">OCamldoc</a>.
 </p>
 
-<H3><a name="Ocaml_nn33">28.3.1 Module docstring</a></H3>
+<H3><a name="Ocaml_nn33">38.3.1 Module docstring</a></H3>
 
 
 <p>
diff --git a/Doc/Manual/Preprocessor.html b/Doc/Manual/Preprocessor.html
index 10efe0c15..1bf59e238 100644
--- a/Doc/Manual/Preprocessor.html
+++ b/Doc/Manual/Preprocessor.html
@@ -7,7 +7,7 @@
 </head>
 
 <body bgcolor="#ffffff">
-<H1><a name="Preprocessor">9 Preprocessing</a></H1>
+<H1><a name="Preprocessor">10 Preprocessing</a></H1>
 <!-- INDEX -->
 <div class="sectiontoc">
 <ul>
@@ -38,7 +38,7 @@ However, a number of modifications and enhancements have been made.  This
 chapter describes some of these modifications.
 </p>
 
-<H2><a name="Preprocessor_nn2">9.1 File inclusion</a></H2>
+<H2><a name="Preprocessor_nn2">10.1 File inclusion</a></H2>
 
 
 <p>
@@ -64,7 +64,7 @@ By default, the <tt>#include</tt> is ignored unless you run SWIG with the
 is that you often don't want SWIG to try and wrap everything included
 in standard header system headers and auxiliary files.
 
-<H2><a name="Preprocessor_nn3">9.2 File imports</a></H2>
+<H2><a name="Preprocessor_nn3">10.2 File imports</a></H2>
 
 
 <p>
@@ -93,7 +93,7 @@ The <tt>-importall</tt> directive tells SWIG to follow all <tt>#include</tt> sta
 as imports.    This might be useful if you want to extract type definitions from system 
 header files without generating any wrappers.
 
-<H2><a name="Preprocessor_condition_compilation">9.3 Conditional Compilation</a></H2>
+<H2><a name="Preprocessor_condition_compilation">10.3 Conditional Compilation</a></H2>
 
 
 <p>
@@ -151,7 +151,7 @@ SWIG (except for the symbol `<tt>SWIG</tt>' which is only defined
 within the SWIG compiler).
 </p>
 
-<H2><a name="Preprocessor_nn5">9.4 Macro Expansion</a></H2>
+<H2><a name="Preprocessor_nn5">10.4 Macro Expansion</a></H2>
 
 
 <p>
@@ -206,7 +206,7 @@ like <tt>#x</tt>.  This is a non-standard SWIG extension.
 </li>
 </ul>
 
-<H2><a name="Preprocessor_nn6">9.5 SWIG Macros</a></H2>
+<H2><a name="Preprocessor_nn6">10.5 SWIG Macros</a></H2>
 
 
 <p>
@@ -252,7 +252,7 @@ many of SWIG's advanced features and libraries are built using this mechanism (s
 support).
 </p>
 
-<H2><a name="Preprocessor_nn7">9.6 C99 and GNU Extensions</a></H2>
+<H2><a name="Preprocessor_nn7">10.6 C99 and GNU Extensions</a></H2>
 
 
 <p>
@@ -308,14 +308,14 @@ interface building.   However, they are used internally to implement a number of
 SWIG directives and are provided to make SWIG more compatible with C99 code.
 </p>
 
-<H2><a name="Preprocessor_delimiters">9.7 Preprocessing and delimiters</a></H2>
+<H2><a name="Preprocessor_delimiters">10.7 Preprocessing and delimiters</a></H2>
 
 
 <p>
 The preprocessor handles { }, " " and %{ %} delimiters differently.
 </p>
 
-<H3><a name="Preprocessor_nn8">9.7.1 Preprocessing and %{ ... %} &amp; " ... " delimiters</a></H3>
+<H3><a name="Preprocessor_nn8">10.7.1 Preprocessing and %{ ... %} &amp; " ... " delimiters</a></H3>
 
 
 <p>
@@ -340,7 +340,7 @@ the contents of the <tt>%{ ... %}</tt> block are copied without
 modification to the output (including all preprocessor directives).
 </p>
 
-<H3><a name="Preprocessor_nn9">9.7.2 Preprocessing and { ... } delimiters</a></H3>
+<H3><a name="Preprocessor_nn9">10.7.2 Preprocessing and { ... } delimiters</a></H3>
 
 
 <p>
@@ -382,7 +382,7 @@ to actually go into the wrapper file, prefix the preprocessor directives with <t
 SWIG will strip the extra <tt>%</tt> and leave the preprocessor directive in the code.
 </p>
 
-<H2><a name="Preprocessor_typemap_delimiters">9.8 Preprocessor and Typemaps</a></H2>
+<H2><a name="Preprocessor_typemap_delimiters">10.8 Preprocessor and Typemaps</a></H2>
 
 
 <p>
@@ -453,7 +453,7 @@ would generate
 </div>
 
 
-<H2><a name="Preprocessor_nn10">9.9 Viewing preprocessor output</a></H2>
+<H2><a name="Preprocessor_nn10">10.9 Viewing preprocessor output</a></H2>
 
 
 <p>
@@ -463,7 +463,7 @@ Instead the results after the preprocessor has run are displayed.
 This might be useful as an aid to debugging and viewing the results of macro expansions.
 </p>
 
-<H2><a name="Preprocessor_warning_error">9.10 The #error and #warning directives</a></H2>
+<H2><a name="Preprocessor_warning_error">10.10 The #error and #warning directives</a></H2>
 
 
 <p>
diff --git a/Doc/Manual/Typemaps.html b/Doc/Manual/Typemaps.html
index 1639423af..d34bb2801 100644
--- a/Doc/Manual/Typemaps.html
+++ b/Doc/Manual/Typemaps.html
@@ -7,7 +7,7 @@
 </head>
 
 <body bgcolor="#ffffff">
-<H1><a name="Typemaps">12 Typemaps</a></H1>
+<H1><a name="Typemaps">13 Typemaps</a></H1>
 <!-- INDEX -->
 <div class="sectiontoc">
 <ul>
@@ -102,7 +102,7 @@
 
 
 
-<H2><a name="Typemaps_nn2">12.1 Introduction</a></H2>
+<H2><a name="Typemaps_nn2">13.1 Introduction</a></H2>
 
 
 <p>
@@ -119,7 +119,7 @@ to re-read the earlier chapters if you have found your way to this
 chapter with only a vague idea of what SWIG already does by default.
 </p>
 
-<H3><a name="Typemaps_nn3">12.1.1 Type conversion</a></H3>
+<H3><a name="Typemaps_nn3">13.1.1 Type conversion</a></H3>
 
 
 <p>
@@ -212,7 +212,7 @@ to read the extension documentation for your favorite language to know
 how it works (an exercise left to the reader).
 </p>
 
-<H3><a name="Typemaps_nn4">12.1.2 Typemaps</a></H3>
+<H3><a name="Typemaps_nn4">13.1.2 Typemaps</a></H3>
 
 
 <p>
@@ -313,7 +313,7 @@ parts of the generated wrapper functions.   Because arbitrary code can be insert
 possible to completely change the way in which values are converted.
 </p>
 
-<H3><a name="Typemaps_nn5">12.1.3 Pattern matching</a></H3>
+<H3><a name="Typemaps_nn5">13.1.3 Pattern matching</a></H3>
 
 
 <p>
@@ -415,7 +415,7 @@ In this case, a single input object is expanded into a pair of C arguments.  Thi
 provides a hint to the unusual variable naming scheme involving <tt>$1</tt>, <tt>$2</tt>, and so forth.
 </p>
 
-<H3><a name="Typemaps_nn6">12.1.4 Reusing typemaps</a></H3>
+<H3><a name="Typemaps_nn6">13.1.4 Reusing typemaps</a></H3>
 
 
 <p>
@@ -493,7 +493,7 @@ typedef int size_t;
 then SWIG already knows that the <tt>int</tt> typemaps apply.  You don't have to do anything.
 </p>
 
-<H3><a name="Typemaps_nn7">12.1.5 What can be done with typemaps?</a></H3>
+<H3><a name="Typemaps_nn7">13.1.5 What can be done with typemaps?</a></H3>
 
 
 <p>
@@ -605,7 +605,7 @@ typemaps that expand upon this list.  For example, the Java module defines a var
 aspects of the Java bindings.  Consult language specific documentation for further details.
 </p>
 
-<H3><a name="Typemaps_nn8">12.1.6 What can't be done with typemaps?</a></H3>
+<H3><a name="Typemaps_nn8">13.1.6 What can't be done with typemaps?</a></H3>
 
 
 <p>
@@ -668,7 +668,7 @@ void wrap_foo(char *s, int x) {
 </pre>
 </div>
 
-<H3><a name="Typemaps_aspects">12.1.7 Similarities to Aspect Oriented Programming</a></H3>
+<H3><a name="Typemaps_aspects">13.1.7 Similarities to Aspect Oriented Programming</a></H3>
 
 
 <p>
@@ -686,7 +686,7 @@ SWIG can also be viewed as has having a second set of aspects based around <a hr
 Features such as <tt>%exception</tt> are also cross-cutting concerns as they encapsulate code that can be used to add logging or exception handling to any function.
 </p>
 
-<H3><a name="Typemaps_nn9">12.1.8 The rest of this chapter</a></H3>
+<H3><a name="Typemaps_nn9">13.1.8 The rest of this chapter</a></H3>
 
 
 <p>
@@ -706,14 +706,14 @@ of "The C Programming Language" by Kernighan and Ritchie or
 "The C++ Programming Language" by Stroustrup before going any further.
 </p>
 
-<H2><a name="Typemaps_nn10">12.2 Typemap specifications</a></H2>
+<H2><a name="Typemaps_nn10">13.2 Typemap specifications</a></H2>
 
 
 <p>
 This section describes the behavior of the <tt>%typemap</tt> directive itself.
 </p>
 
-<H3><a name="Typemaps_defining">12.2.1 Defining a typemap</a></H3>
+<H3><a name="Typemaps_defining">13.2.1 Defining a typemap</a></H3>
 
 
 <p>
@@ -826,7 +826,7 @@ Admittedly, it's not the most readable syntax at first glance.  However, the pur
 individual pieces will become clear.
 </p>
 
-<H3><a name="Typemaps_nn12">12.2.2 Typemap scope</a></H3>
+<H3><a name="Typemaps_nn12">13.2.2 Typemap scope</a></H3>
 
 
 <p>
@@ -876,7 +876,7 @@ class Foo {
 </pre>
 </div>
 
-<H3><a name="Typemaps_nn13">12.2.3 Copying a typemap</a></H3>
+<H3><a name="Typemaps_nn13">13.2.3 Copying a typemap</a></H3>
 
 
 <p>
@@ -934,7 +934,7 @@ The patterns for <tt>%apply</tt> follow the same rules as for <tt>%typemap</tt>.
 </pre>
 </div>
 
-<H3><a name="Typemaps_nn14">12.2.4 Deleting a typemap</a></H3>
+<H3><a name="Typemaps_nn14">13.2.4 Deleting a typemap</a></H3>
 
 
 <p>
@@ -968,7 +968,7 @@ For example:
 after the clear operation.
 </p>
 
-<H3><a name="Typemaps_nn15">12.2.5 Placement of typemaps</a></H3>
+<H3><a name="Typemaps_nn15">13.2.5 Placement of typemaps</a></H3>
 
 
 <p>
@@ -1048,7 +1048,7 @@ It should be noted that for scoping to work, SWIG has to know that <tt>string</t
 within a particular namespace.  In this example, this is done using the forward class declaration <tt>class string</tt>.
 </p>
 
-<H2><a name="Typemaps_pattern_matching">12.3 Pattern matching rules</a></H2>
+<H2><a name="Typemaps_pattern_matching">13.3 Pattern matching rules</a></H2>
 
 
 <p>
@@ -1056,7 +1056,7 @@ The section describes the pattern matching rules by which C/C++ datatypes are as
 The matching rules can be observed in practice by using the debugging options also described.
 </p>
 
-<H3><a name="Typemaps_nn17">12.3.1 Basic matching rules</a></H3>
+<H3><a name="Typemaps_nn17">13.3.1 Basic matching rules</a></H3>
 
 
 <p>
@@ -1155,7 +1155,7 @@ void F(int x[1000]);   // int [ANY] rule    (typemap 5)
 stripped all qualifiers in one step.
 </p>
 
-<H3><a name="Typemaps_typedef_reductions">12.3.2 Typedef reductions matching</a></H3>
+<H3><a name="Typemaps_typedef_reductions">13.3.2 Typedef reductions matching</a></H3>
 
 
 <p>
@@ -1330,7 +1330,7 @@ void go(Struct aStruct);
 </pre>
 </div>
 
-<H3><a name="Typemaps_nn19">12.3.3 Default typemap matching rules</a></H3>
+<H3><a name="Typemaps_nn19">13.3.3 Default typemap matching rules</a></H3>
 
 
 <p>
@@ -1468,7 +1468,7 @@ Finally the best way to view the typemap matching rules in action is via the <a
 simpler scheme to match the current C++ class template partial specialization matching rules.
 </p>
 
-<H3><a name="Typemaps_multi_argument_typemaps_patterns">12.3.4 Multi-arguments typemaps</a></H3>
+<H3><a name="Typemaps_multi_argument_typemaps_patterns">13.3.4 Multi-arguments typemaps</a></H3>
 
 
 <p>
@@ -1498,7 +1498,7 @@ but all subsequent arguments must match exactly.
 </p>
 
 
-<H3><a name="Typemaps_matching_template_comparison">12.3.5 Matching rules compared to C++ templates</a></H3>
+<H3><a name="Typemaps_matching_template_comparison">13.3.5 Matching rules compared to C++ templates</a></H3>
 
 
 <p>
@@ -1657,7 +1657,7 @@ are similar to those for specialized template handling.
 </p>
 
 
-<H3><a name="Typemaps_debugging_search">12.3.6 Debugging typemap pattern matching</a></H3>
+<H3><a name="Typemaps_debugging_search">13.3.6 Debugging typemap pattern matching</a></H3>
 
 
 <p>
@@ -1870,7 +1870,7 @@ Also the types may be displayed slightly differently - <tt>char const *</tt> and
 </li>
 </ul>
 
-<H2><a name="Typemaps_nn21">12.4 Code generation rules</a></H2>
+<H2><a name="Typemaps_nn21">13.4 Code generation rules</a></H2>
 
 
 <p>
@@ -1878,7 +1878,7 @@ This section describes rules by which typemap code is inserted into
 the generated wrapper code.
 </p>
 
-<H3><a name="Typemaps_nn22">12.4.1 Scope</a></H3>
+<H3><a name="Typemaps_nn22">13.4.1 Scope</a></H3>
 
 
 <p>
@@ -1956,7 +1956,7 @@ a block scope when it is emitted.   This sometimes results in a less complicated
 Note that only the third of the three typemaps have the typemap code passed through the SWIG preprocessor.
 </p>
 
-<H3><a name="Typemaps_nn23">12.4.2 Declaring new local variables</a></H3>
+<H3><a name="Typemaps_nn23">13.4.2 Declaring new local variables</a></H3>
 
 
 <p>
@@ -2123,7 +2123,7 @@ each type must have its own local variable declaration.
 </div>
 
 
-<H3><a name="Typemaps_special_variables">12.4.3 Special variables</a></H3>
+<H3><a name="Typemaps_special_variables">13.4.3 Special variables</a></H3>
 
 
 <p>
@@ -2375,7 +2375,7 @@ Another approach, which only works for arrays is to use the <tt>$1_basetype</tt>
 </pre>
 </div>
 
-<H3><a name="Typemaps_special_variable_macros">12.4.4 Special variable macros</a></H3>
+<H3><a name="Typemaps_special_variable_macros">13.4.4 Special variable macros</a></H3>
 
 
 <p>
@@ -2387,7 +2387,7 @@ it is done during the SWIG parsing/compilation stages.
 The following special variable macros are available across all language modules.
 </p>
 
-<H4><a name="Typemaps_special_macro_descriptor">12.4.4.1 $descriptor(type)</a></H4>
+<H4><a name="Typemaps_special_macro_descriptor">13.4.4.1 $descriptor(type)</a></H4>
 
 
 <p>
@@ -2398,7 +2398,7 @@ For example, <tt>$descriptor(std::vector&lt;int&gt; *)</tt> will expand into <tt
 This macro is mostly used in the scripting target languages and is demonstrated later in the <a href="#Typemaps_runtime_type_checker_usage">Run-time type checker usage</a> section.
 </p>
 
-<H4><a name="Typemaps_special_macro_typemap">12.4.4.2 $typemap(method, typepattern)</a></H4>
+<H4><a name="Typemaps_special_macro_typemap">13.4.4.2 $typemap(method, typepattern)</a></H4>
 
 
 <p>
@@ -2456,7 +2456,7 @@ The result is the following expansion
 </div>
 
 
-<H3><a name="Typemaps_special_variable_attributes">12.4.5 Special variables and typemap attributes</a></H3>
+<H3><a name="Typemaps_special_variable_attributes">13.4.5 Special variables and typemap attributes</a></H3>
 
 
 <p>
@@ -2483,7 +2483,7 @@ is equivalent to the following as <tt>$*1_ltype</tt> expands to <tt>unsigned int
 </pre>
 </div>
 
-<H3><a name="Typemaps_special_variables_and_macros">12.4.6 Special variables combined with special variable macros</a></H3>
+<H3><a name="Typemaps_special_variables_and_macros">13.4.6 Special variables combined with special variable macros</a></H3>
 
 
 <p>
@@ -2525,7 +2525,7 @@ which then expands to:
 </div>
 
 
-<H2><a name="Typemaps_nn25">12.5 Common typemap methods</a></H2>
+<H2><a name="Typemaps_nn25">13.5 Common typemap methods</a></H2>
 
 
 <p>
@@ -2533,7 +2533,7 @@ The family of typemaps recognized by a language module may vary.  However,
 the following typemap methods are nearly universal:
 </p>
 
-<H3><a name="Typemaps_nn26">12.5.1 "in" typemap</a></H3>
+<H3><a name="Typemaps_nn26">13.5.1 "in" typemap</a></H3>
 
 
 <p>
@@ -2593,7 +2593,7 @@ Usually <tt>numinputs</tt> is not specified, whereupon the default value is 1, t
 is the same as the old "ignore" typemap.
 </p>
 
-<H3><a name="Typemaps_nn27">12.5.2 "typecheck" typemap</a></H3>
+<H3><a name="Typemaps_nn27">13.5.2 "typecheck" typemap</a></H3>
 
 
 <p>
@@ -2620,7 +2620,7 @@ If you define new "in" typemaps <em>and</em> your program uses overloaded method
 "typecheck" typemaps.  More details about this follow in the <a href="#Typemaps_overloading">Typemaps and overloading</a> section.
 </p>
 
-<H3><a name="Typemaps_nn28">12.5.3 "out" typemap</a></H3>
+<H3><a name="Typemaps_nn28">13.5.3 "out" typemap</a></H3>
 
 
 <p>
@@ -2651,7 +2651,7 @@ $symname          - Name of function/method being wrapped
 The "out" typemap supports an optional attribute flag called "optimal". This is for code optimisation and is detailed in the <a href="#Typemaps_optimal">Optimal code generation when returning by value</a> section.
 </p>
 
-<H3><a name="Typemaps_nn29">12.5.4 "arginit" typemap</a></H3>
+<H3><a name="Typemaps_nn29">13.5.4 "arginit" typemap</a></H3>
 
 
 <p>
@@ -2670,7 +2670,7 @@ For example:
 </pre>
 </div>
 
-<H3><a name="Typemaps_nn30">12.5.5 "default" typemap</a></H3>
+<H3><a name="Typemaps_nn30">13.5.5 "default" typemap</a></H3>
 
 
 <p>
@@ -2703,7 +2703,7 @@ See the <a href="SWIG.html#SWIG_default_args">Default/optional arguments</a> sec
 for further information on default argument wrapping.
 </p>
 
-<H3><a name="Typemaps_nn31">12.5.6 "check" typemap</a></H3>
+<H3><a name="Typemaps_nn31">13.5.6 "check" typemap</a></H3>
 
 
 <p>
@@ -2722,7 +2722,7 @@ converted.  For example:
 </pre>
 </div>
 
-<H3><a name="Typemaps_nn32">12.5.7 "argout" typemap</a></H3>
+<H3><a name="Typemaps_nn32">13.5.7 "argout" typemap</a></H3>
 
 
 <p>
@@ -2768,7 +2768,7 @@ return values are often appended to return value of the function.
 See the <tt>typemaps.i</tt> library file for examples.
 </p>
 
-<H3><a name="Typemaps_nn33">12.5.8 "freearg" typemap</a></H3>
+<H3><a name="Typemaps_nn33">13.5.8 "freearg" typemap</a></H3>
 
 
 <p>
@@ -2801,7 +2801,7 @@ be used in other typemaps whenever a wrapper function needs to abort
 prematurely.
 </p>
 
-<H3><a name="Typemaps_nn34">12.5.9 "newfree" typemap</a></H3>
+<H3><a name="Typemaps_nn34">13.5.9 "newfree" typemap</a></H3>
 
 
 <p>
@@ -2830,7 +2830,7 @@ string *foo();
 See <a href="Customization.html#Customization_ownership">Object ownership and %newobject</a> for further details.
 </p>
 
-<H3><a name="Typemaps_ret">12.5.10 "ret" typemap</a></H3>
+<H3><a name="Typemaps_ret">13.5.10 "ret" typemap</a></H3>
 
 
 <p>
@@ -2869,7 +2869,7 @@ This approach is an alternative to using the "newfree" typemap and <tt>%newobjec
 is no need to list all the functions that require the memory cleanup, it is purely done on types.
 </p>
 
-<H3><a name="Typemaps_nn35">12.5.11 "memberin" typemap</a></H3>
+<H3><a name="Typemaps_nn35">13.5.11 "memberin" typemap</a></H3>
 
 
 <p>
@@ -2891,7 +2891,7 @@ It is rarely necessary to write "memberin" typemaps---SWIG already provides
 a default implementation for arrays, strings, and other objects.
 </p>
 
-<H3><a name="Typemaps_nn36">12.5.12 "varin" typemap</a></H3>
+<H3><a name="Typemaps_nn36">13.5.12 "varin" typemap</a></H3>
 
 
 <p>
@@ -2899,7 +2899,7 @@ The "varin" typemap is used to convert objects in the target language to C for t
 purposes of assigning to a C/C++ global variable.    This is implementation specific.
 </p>
 
-<H3><a name="Typemaps_nn37">12.5.13 "varout" typemap</a></H3>
+<H3><a name="Typemaps_nn37">13.5.13 "varout" typemap</a></H3>
 
 
 <p>
@@ -2907,7 +2907,7 @@ The "varout" typemap is used to convert a C/C++ object to an object in the targe
 language when reading a C/C++ global variable.  This is implementation specific.
 </p>
 
-<H3><a name="Typemaps_throws_typemap">12.5.14 "throws" typemap</a></H3>
+<H3><a name="Typemaps_throws_typemap">13.5.14 "throws" typemap</a></H3>
 
 
 <p>
@@ -2957,7 +2957,7 @@ Note that if your methods do not have an exception specification but they do thr
 Please also see the <a href="Customization.html#Customization_exception">Exception handling with %exception</a> section for another way to handle exceptions.
 </p>
 
-<H2><a name="Typemaps_nn39">12.6 Some typemap examples</a></H2>
+<H2><a name="Typemaps_nn39">13.6 Some typemap examples</a></H2>
 
 
 <p>
@@ -2965,7 +2965,7 @@ This section contains a few examples.  Consult language module documentation
 for more examples.
 </p>
 
-<H3><a name="Typemaps_nn40">12.6.1 Typemaps for arrays</a></H3>
+<H3><a name="Typemaps_nn40">13.6.1 Typemaps for arrays</a></H3>
 
 
 <p>
@@ -3224,7 +3224,7 @@ Now, you will find that member access is quite nice:
 useless and has since been eliminated.   To return structure members, simply use the "out" typemap.
 </p>
 
-<H3><a name="Typemaps_nn41">12.6.2 Implementing constraints with typemaps</a></H3>
+<H3><a name="Typemaps_nn41">13.6.2 Implementing constraints with typemaps</a></H3>
 
 
 <p>
@@ -3272,7 +3272,7 @@ a NULL pointer. As a result, SWIG can often prevent a potential
 segmentation faults or other run-time problems by raising an exception
 rather than blindly passing values to the underlying C/C++ program.</p>
 
-<H2><a name="Typemaps_nn43">12.7 Typemaps for multiple target languages</a></H2>
+<H2><a name="Typemaps_nn43">13.7 Typemaps for multiple target languages</a></H2>
 
 
 <p>
@@ -3302,7 +3302,7 @@ The example above also shows a common approach of issuing a warning for an as ye
 <tt>%typemap(ruby, in) int "$1 = NUM2INT($input);"</tt>.
 </p>
 
-<H2><a name="Typemaps_optimal">12.8 Optimal code generation when returning by value</a></H2>
+<H2><a name="Typemaps_optimal">13.8 Optimal code generation when returning by value</a></H2>
 
 
 <p>
@@ -3491,7 +3491,7 @@ example.i:7: Warning 475: optimal attribute usage in the out typemap.
 However, it doesn't always get it right, for example when <tt>$1</tt> is within some commented out code.
 </p>
 
-<H2><a name="Typemaps_multi_argument_typemaps">12.9 Multi-argument typemaps</a></H2>
+<H2><a name="Typemaps_multi_argument_typemaps">13.9 Multi-argument typemaps</a></H2>
 
 
 <p>
@@ -3768,7 +3768,7 @@ with non-consecutive C/C++ arguments; a workaround such as a helper function re-
 the arguments to make them consecutive will need to be written.
 </p>
 
-<H2><a name="Typemaps_warnings">12.10 Typemap warnings</a></H2>
+<H2><a name="Typemaps_warnings">13.10 Typemap warnings</a></H2>
 
 
 <p>
@@ -3777,7 +3777,7 @@ See the information in the <a href="Warnings.html#Warnings_nn5">issuing warnings
 </p>
 
 
-<H2><a name="Typemaps_fragments">12.11 Typemap fragments</a></H2>
+<H2><a name="Typemaps_fragments">13.11 Typemap fragments</a></H2>
 
 
 <p>
@@ -4113,7 +4113,7 @@ fragment usage unless a desire to really get to grips
 with some powerful but tricky macro and fragment usage that is used in parts of the SWIG typemap library.
 </p>
 
-<H3><a name="Typemaps_fragment_type_specialization">12.11.1 Fragment type specialization</a></H3>
+<H3><a name="Typemaps_fragment_type_specialization">13.11.1 Fragment type specialization</a></H3>
 
 
 <p>
@@ -4146,7 +4146,7 @@ struct A {
 </pre>
 </div>
 
-<H3><a name="Typemaps_automatic_specialization">12.11.2 Fragments and automatic typemap specialization</a></H3>
+<H3><a name="Typemaps_automatic_specialization">13.11.2 Fragments and automatic typemap specialization</a></H3>
 
 
 <p>
@@ -4192,7 +4192,7 @@ The interested (or very brave) reader can take a look at the fragments.swg file
 </p>
 
 
-<H2><a name="Typemaps_runtime_type_checker">12.12 The run-time type checker</a></H2>
+<H2><a name="Typemaps_runtime_type_checker">13.12 The run-time type checker</a></H2>
 
 
 <p>
@@ -4218,7 +4218,7 @@ language modules.</li>
 <li>Modules can be unloaded from the type system.</li>
 </ul>
 
-<H3><a name="Typemaps_nn45">12.12.1 Implementation</a></H3>
+<H3><a name="Typemaps_nn45">13.12.1 Implementation</a></H3>
 
 
 <p>
@@ -4412,7 +4412,7 @@ structures rather than creating new ones.  These <tt>swig_module_info</tt>
 structures are chained together in a circularly linked list.
 </p>
 
-<H3><a name="Typemaps_runtime_type_checker_usage">12.12.2 Usage</a></H3>
+<H3><a name="Typemaps_runtime_type_checker_usage">13.12.2 Usage</a></H3>
 
 
 <p>This section covers how to use these functions from typemaps.  To learn how to
@@ -4508,7 +4508,7 @@ probably just look at the output of SWIG to get a better sense for how types are
 managed.
 </p>
 
-<H2><a name="Typemaps_overloading">12.13 Typemaps and overloading</a></H2>
+<H2><a name="Typemaps_overloading">13.13 Typemaps and overloading</a></H2>
 
 
 <p>
@@ -4815,7 +4815,7 @@ Subsequent "in" typemaps would then perform more extensive type-checking.
 </li>
 </ul>
 
-<H3><a name="Typemaps_typecheck_pointer">12.13.1 SWIG_TYPECHECK_POINTER precedence level and the typecheck typemap</a></H3>
+<H3><a name="Typemaps_typecheck_pointer">13.13.1 SWIG_TYPECHECK_POINTER precedence level and the typecheck typemap</a></H3>
 
 
 <p>
@@ -4917,7 +4917,7 @@ Otherwise both can be wrapped by removing the overloading name ambiguity by rena
 The 'equivalent' attribute is used in the implementation for the <a href="Library.html#Library_std_shared_ptr">shared_ptr smart pointer</a> library.
 </p>
 
-<H2><a name="Typemaps_nn48">12.14 More about %apply and %clear</a></H2>
+<H2><a name="Typemaps_nn48">13.14 More about %apply and %clear</a></H2>
 
 
 <p>
@@ -5022,7 +5022,7 @@ will delete the typemaps for all the typemap methods; namely "in", "check" and "
 </pre>
 </div>
 
-<H2><a name="Typemaps_nn47">12.15 Passing data between typemaps</a></H2>
+<H2><a name="Typemaps_nn47">13.15 Passing data between typemaps</a></H2>
 
 
 <p>
@@ -5059,7 +5059,7 @@ sure that the typemaps sharing information have exactly the same types and names
 </p>
 
 
-<H2><a name="Typemaps_nn52">12.16 C++ "this" pointer</a></H2>
+<H2><a name="Typemaps_nn52">13.16 C++ "this" pointer</a></H2>
 
 
 <p>
@@ -5119,7 +5119,7 @@ will also match the typemap.  One work around is to create an interface file tha
 the method, but gives the argument a name other than <tt>self</tt>.
 </p>
 
-<H2><a name="Typemaps_nn51">12.17 Where to go for more information?</a></H2>
+<H2><a name="Typemaps_nn51">13.17 Where to go for more information?</a></H2>
 
 
 <p>
diff --git a/Doc/Manual/Varargs.html b/Doc/Manual/Varargs.html
index c6f0e8c63..9f20469d2 100644
--- a/Doc/Manual/Varargs.html
+++ b/Doc/Manual/Varargs.html
@@ -7,7 +7,7 @@
 </head>
 
 <body bgcolor="#ffffff">
-<H1><a name="Varargs">15 Variable Length Arguments</a></H1>
+<H1><a name="Varargs">16 Variable Length Arguments</a></H1>
 <!-- INDEX -->
 <div class="sectiontoc">
 <ul>
@@ -43,7 +43,7 @@ added in SWIG-1.3.12.  Most other wrapper generation tools have
 wisely chosen to avoid this issue.
 </p>
 
-<H2><a name="Varargs_nn2">15.1 Introduction</a></H2>
+<H2><a name="Varargs_nn2">16.1 Introduction</a></H2>
 
 
 <p>
@@ -140,7 +140,7 @@ List make_list(const char *s, ...) {
 </pre>
 </div>
 
-<H2><a name="Varargs_nn3">15.2 The Problem</a></H2>
+<H2><a name="Varargs_nn3">16.2 The Problem</a></H2>
 
 
 <p>
@@ -233,7 +233,7 @@ can also support real varargs wrapping (with stack-frame manipulation) if you
 are willing to get hands dirty.  Keep reading.
 </p>
 
-<H2><a name="Varargs_nn4">15.3 Default varargs support</a></H2>
+<H2><a name="Varargs_nn4">16.3 Default varargs support</a></H2>
 
 
 <p>
@@ -302,7 +302,7 @@ Read on for further solutions.
 </p>
 
 
-<H2><a name="Varargs_nn5">15.4 Argument replacement using %varargs</a></H2>
+<H2><a name="Varargs_nn5">16.4 Argument replacement using %varargs</a></H2>
 
 
 <p>
@@ -413,7 +413,7 @@ mixed argument types such as <tt>printf()</tt>.  Providing general purpose
 wrappers to such functions presents special problems (covered shortly).  
 </p>
 
-<H2><a name="Varargs_nn6">15.5 Varargs and typemaps</a></H2>
+<H2><a name="Varargs_nn6">16.5 Varargs and typemaps</a></H2>
 
 
 <p>
@@ -593,7 +593,7 @@ really want to elevate your guru status and increase your job
 security, continue to the next section.
 </p>
 
-<H2><a name="Varargs_nn7">15.6 Varargs wrapping with libffi</a></H2>
+<H2><a name="Varargs_nn7">16.6 Varargs wrapping with libffi</a></H2>
 
 
 <p>
@@ -845,7 +845,7 @@ provide an argument number for the first extra argument.  This can be used to in
 values.   Please consult the chapter on each language module for more details.
 </p>
 
-<H2><a name="Varargs_nn8">15.7 Wrapping of va_list</a></H2>
+<H2><a name="Varargs_nn8">16.7 Wrapping of va_list</a></H2>
 
 
 <p>
@@ -899,7 +899,7 @@ int my_vprintf(const char *fmt, ...) {
 </pre>
 </div>
 
-<H2><a name="Varargs_nn9">15.8 C++ Issues</a></H2>
+<H2><a name="Varargs_nn9">16.8 C++ Issues</a></H2>
 
 
 <p>
@@ -968,7 +968,7 @@ design or to provide an alternative interface using a helper function than it is
 fully general wrapper to a varargs C++ member function.
 </p>
 
-<H2><a name="Varargs_nn10">15.9 Discussion</a></H2>
+<H2><a name="Varargs_nn10">16.9 Discussion</a></H2>
 
 
 <p>
diff --git a/Doc/Manual/Warnings.html b/Doc/Manual/Warnings.html
index 968bdbac8..bff20801e 100644
--- a/Doc/Manual/Warnings.html
+++ b/Doc/Manual/Warnings.html
@@ -7,7 +7,7 @@
 </head>
 
 <body bgcolor="#ffffff">
-<H1><a name="Warnings">17 Warning Messages</a></H1>
+<H1><a name="Warnings">18 Warning Messages</a></H1>
 <!-- INDEX -->
 <div class="sectiontoc">
 <ul>
@@ -37,7 +37,7 @@
 
 
 
-<H2><a name="Warnings_nn2">17.1 Introduction</a></H2>
+<H2><a name="Warnings_nn2">18.1 Introduction</a></H2>
 
 
 <p>
@@ -57,7 +57,7 @@ where the generated wrapper code will probably compile, but it may not
 work like you expect.
 </p>
 
-<H2><a name="Warnings_suppression">17.2 Warning message suppression</a></H2>
+<H2><a name="Warnings_suppression">18.2 Warning message suppression</a></H2>
 
 
 <p>
@@ -149,7 +149,7 @@ your interface.  Ignore the warning messages at your own peril.
 </p>
 
 
-<H2><a name="Warnings_nn4">17.3 Enabling extra warnings</a></H2>
+<H2><a name="Warnings_nn4">18.3 Enabling extra warnings</a></H2>
 
 
 <p>
@@ -222,7 +222,7 @@ that is, any warnings suppressed or added in <tt>%warnfilter</tt>, <tt>#pragma S
 or the <tt>-w</tt> option.
 </p>
 
-<H2><a name="Warnings_nn5">17.4 Issuing a warning message</a></H2>
+<H2><a name="Warnings_nn5">18.4 Issuing a warning message</a></H2>
 
 
 <p>
@@ -276,7 +276,7 @@ example.i:24: Warning 901: You are really going to regret this usage of blah * s
 </pre>
 </div>
 
-<H2><a name="Warnings_symbolic_symbols">17.5 Symbolic symbols</a></H2>
+<H2><a name="Warnings_symbolic_symbols">18.5 Symbolic symbols</a></H2>
 
 
 <p>
@@ -311,7 +311,7 @@ or
 </pre>
 </div>
 
-<H2><a name="Warnings_nn6">17.6 Commentary</a></H2>
+<H2><a name="Warnings_nn6">18.6 Commentary</a></H2>
 
 
 <p>
@@ -328,7 +328,7 @@ no obvious recovery.  There is no mechanism for suppressing error
 messages.
 </p>
 
-<H2><a name="Warnings_nn7">17.7 Warnings as errors</a></H2>
+<H2><a name="Warnings_nn7">18.7 Warnings as errors</a></H2>
 
 
 <p>
@@ -337,7 +337,7 @@ option. This will cause SWIG to exit with a non successful exit code if a
 warning is encountered.
 </p>
 
-<H2><a name="Warnings_nn8">17.8 Message output format</a></H2>
+<H2><a name="Warnings_nn8">18.8 Message output format</a></H2>
 
 
 <p>
@@ -356,10 +356,10 @@ $ swig -python -Fmicrosoft example.i
 example.i(4) : Syntax error in input(1).
 </pre></div>
 
-<H2><a name="Warnings_nn9">17.9 Warning number reference</a></H2>
+<H2><a name="Warnings_nn9">18.9 Warning number reference</a></H2>
 
 
-<H3><a name="Warnings_nn10">17.9.1 Deprecated features (100-199)</a></H3>
+<H3><a name="Warnings_nn10">18.9.1 Deprecated features (100-199)</a></H3>
 
 
 <ul>
@@ -387,7 +387,7 @@ example.i(4) : Syntax error in input(1).
 <li>126. The 'nestedworkaround' feature is deprecated.
 </ul>
 
-<H3><a name="Warnings_nn11">17.9.2 Preprocessor (200-299)</a></H3>
+<H3><a name="Warnings_nn11">18.9.2 Preprocessor (200-299)</a></H3>
 
 
 <ul>
@@ -399,7 +399,7 @@ example.i(4) : Syntax error in input(1).
 <li>206. Unexpected tokens after #<em>directive</em> directive.
 </ul>
 
-<H3><a name="Warnings_nn12">17.9.3 C/C++ Parser (300-399)</a></H3>
+<H3><a name="Warnings_nn12">18.9.3 C/C++ Parser (300-399)</a></H3>
 
 
 <ul>
@@ -476,7 +476,7 @@ example.i(4) : Syntax error in input(1).
 <li>395. operator delete[] ignored.
 </ul>
 
-<H3><a name="Warnings_nn13">17.9.4 Types and typemaps (400-499) </a></H3>
+<H3><a name="Warnings_nn13">18.9.4 Types and typemaps (400-499) </a></H3>
 
 
 <ul>
@@ -507,7 +507,7 @@ example.i(4) : Syntax error in input(1).
 
 
 
-<H3><a name="Warnings_nn14">17.9.5 Code generation (500-559)</a></H3>
+<H3><a name="Warnings_nn14">18.9.5 Code generation (500-559)</a></H3>
 
 
 <ul>
@@ -537,7 +537,7 @@ example.i(4) : Syntax error in input(1).
 <li>524. Experimental target language. Target language <em>language</em> specified by <em>lang</em> is an experimental language. Please read about SWIG experimental languages, <em>htmllink</em>.
 </ul>
 
-<H3><a name="Warnings_doxygen">17.9.6 Doxygen comments (560-599)</a></H3>
+<H3><a name="Warnings_doxygen">18.9.6 Doxygen comments (560-599)</a></H3>
 
 
 <ul>
@@ -548,7 +548,7 @@ example.i(4) : Syntax error in input(1).
   <li>564: Error parsing Doxygen command <em>command</em>: <em>error text</em>. Command ignored."</li>
 </ul>
 
-<H3><a name="Warnings_nn15">17.9.7 Language module specific (700-899) </a></H3>
+<H3><a name="Warnings_nn15">18.9.7 Language module specific (700-899) </a></H3>
 
 
 <ul>
@@ -599,14 +599,14 @@ example.i(4) : Syntax error in input(1).
 <li>871. Unrecognized pragma <em>pragma</em>.   (Php).
 </ul>
 
-<H3><a name="Warnings_nn16">17.9.8 User defined (900-999)</a></H3>
+<H3><a name="Warnings_nn16">18.9.8 User defined (900-999)</a></H3>
 
 
 <p>
 These numbers can be used by your own application.
 </p>
 
-<H2><a name="Warnings_nn17">17.10 History</a></H2>
+<H2><a name="Warnings_nn17">18.10 History</a></H2>
 
 
 <p>
author	William S Fulton <wsf@fultondesigns.co.uk>	2019-02-11 19:02:03 +0000
committer	William S Fulton <wsf@fultondesigns.co.uk>	2019-02-11 19:02:03 +0000
commit	d16d145787c45954c533c2208b9a0ae721df9002 (patch)
tree	79eaa80d068fdb7859552b6c72488e064d67acb4 /Doc
parent	a5b301ba83810f55da9947765dd249a78ec99855 (diff)
download	swig-d16d145787c45954c533c2208b9a0ae721df9002.tar.gz