Merge branch 'swig:master' into imfunc

21 files changed, 404 insertions, 232 deletions

diff --git a/Doc/Devel/internals.html b/Doc/Devel/internals.html
index c9082d3f6..0fc6623e8 100644
--- a/Doc/Devel/internals.html
+++ b/Doc/Devel/internals.html
@@ -441,12 +441,12 @@ Resulting output:
 
 <blockquote>
 <pre>
-hash len: 5
-get: hashval2
-hash item: hashval5 [h5]
-hash item: hashval1 [h1]
-hash item: hashval2 [h2]
-hash item: hashval3 [h3]
+list len: 5
+get: listval2
+list item: newlistval1
+list item: listval2
+list item: listval3
+list item: listval5
 </pre>
 </blockquote>
 
@@ -494,12 +494,12 @@ Resulting output:
 
 <blockquote>
 <pre>
-list len: 5
-get: listval2
-list item: newlistval1
-list item: listval2
-list item: listval3
-list item: listval5
+hash len: 5
+get: hashval2
+hash item: hashval5 [h5]
+hash item: hashval1 [h1]
+hash item: hashval2 [h2]
+hash item: hashval3 [h3]
 </pre>
 </blockquote>
 
diff --git a/Doc/Manual/CPlusPlus11.html b/Doc/Manual/CPlusPlus11.html
index e5d7fbc2d..86a35bfaa 100644
--- a/Doc/Manual/CPlusPlus11.html
+++ b/Doc/Manual/CPlusPlus11.html
@@ -144,14 +144,39 @@ When either of these is used from a target language, a runtime call is made to o
 <H3><a name="CPlusPlus11_extern_template">7.2.3 Extern template</a></H3>
 
 
-<p>SWIG correctly parses the keywords <tt>extern template</tt>.
+<p>SWIG correctly parses <tt>extern template</tt> explicit instantiation declarations.
 However, this template instantiation suppression in a translation unit has no relevance outside of the C++ compiler and so is not used by SWIG.
-SWIG only uses <tt>%template</tt> for instantiating and wrapping templates.</p>
+SWIG only uses <tt>%template</tt> for instantiating and wrapping templates.
+Consider the class template below:
+</p>
+
+<div class="code"><pre>
+// Class template
+template class std::vector&lt;int&gt;;        // C++03 template explicit instantiation definition in C++
+extern template class std::vector&lt;int&gt;; // C++11 template explicit instantiation declaration (extern template)
+%template(VectorInt) std::vector&lt;int&gt;;  // SWIG template instantiation
+</pre></div>
+
+<p>
+The above result in warnings:
+</p>
+
+<div class="shell">
+<pre>
+example.i:2: Warning 320: Explicit template instantiation ignored.
+example.i:3: Warning 327: Extern template ignored.
+</pre>
+</div>
+
+<p>
+Similarly for the function template below:
+</p>
 
 <div class="code"><pre>
-template class std::vector&lt;int&gt;;        // C++03 explicit instantiation in C++
-extern template class std::vector&lt;int&gt;; // C++11 explicit instantiation suppression in C++
-%template(VectorInt) std::vector&lt;int&gt;;  // SWIG instantiation
+// Function template
+template void Func&lt;int&gt;();              // C++03 template explicit instantiation definition in C++
+extern template void Func&lt;int&gt;();       // C++11 template explicit instantiation declaration (extern template)
+%template(FuncInt) Func&lt;int&gt;;           // SWIG template instantiation
 </pre></div>
 
 <H3><a name="CPlusPlus11_initializer_lists">7.2.4 Initializer lists</a></H3>
diff --git a/Doc/Manual/Contents.html b/Doc/Manual/Contents.html
index 47b41186e..a3d0dcb4e 100644
--- a/Doc/Manual/Contents.html
+++ b/Doc/Manual/Contents.html
@@ -91,17 +91,16 @@
 </ul>
 <li><a href="Windows.html#Windows_other_compilers">Instructions for using the Examples with other compilers</a>
 </ul>
-<li><a href="Windows.html#Windows_cygwin_mingw">SWIG on Cygwin and MinGW</a>
-<ul>
 <li><a href="Windows.html#Windows_swig_exe">Building swig.exe on Windows</a>
 <ul>
 <li><a href="Windows.html#Windows_cmake">Building swig.exe using CMake</a>
-<li><a href="Windows.html#Windows_mingw_msys">Building swig.exe using MSYS2</a>
+<li><a href="Windows.html#Windows_msys2">Building swig.exe using MSYS2</a>
 <li><a href="Windows.html#Windows_mingw_msys">Building swig.exe using MinGW and MSYS</a>
 <li><a href="Windows.html#Windows_cygwin">Building swig.exe using Cygwin</a>
-</ul>
+<ul>
 <li><a href="Windows.html#Windows_examples_cygwin">Running the examples on Windows using Cygwin</a>
 </ul>
+</ul>
 <li><a href="Windows.html#Windows_interface_file">Microsoft extensions and other Windows quirks</a>
 </ul>
 </div>
@@ -172,6 +171,7 @@
 <li><a href="SWIG.html#SWIG_rename_ignore">Renaming and ignoring declarations</a>
 <ul>
 <li><a href="SWIG.html#SWIG_nn29">Simple renaming of specific identifiers</a>
+<li><a href="SWIG.html#SWIG_ignore">Ignoring identifiers</a>
 <li><a href="SWIG.html#SWIG_advanced_renaming">Advanced renaming support</a>
 <li><a href="SWIG.html#SWIG_limiting_renaming">Limiting global renaming rules</a>
 <li><a href="SWIG.html#SWIG_chosen_unignore">Ignoring everything then wrapping a few selected symbols</a>
@@ -251,6 +251,9 @@
 </ul>
 <li><a href="SWIGPlus.html#SWIGPlus_nn28">Overloaded operators</a>
 <li><a href="SWIGPlus.html#SWIGPlus_class_extension">Class extension</a>
+<ul>
+<li><a href="SWIGPlus.html#SWIGPlus_replacing_methods">Replacing class methods</a>
+</ul>
 <li><a href="SWIGPlus.html#SWIGPlus_nn30">Templates</a>
 <ul>
 <li><a href="SWIGPlus.html#SWIGPlus_template_directive">The %template directive</a>
diff --git a/Doc/Manual/Doxygen.html b/Doc/Manual/Doxygen.html
index 53238c24d..e7fd4c359 100644
--- a/Doc/Manual/Doxygen.html
+++ b/Doc/Manual/Doxygen.html
@@ -1354,7 +1354,7 @@ Here is the list of all Doxygen tags and the description of how they are transla
 </tr>
 <tr>
 <td>\throws</td>
-<td>replaced wih ':raises:'</td>
+<td>replaced with ':raises:'</td>
 </tr>
 <tr>
 <td>\todo</td>
diff --git a/Doc/Manual/Extending.html b/Doc/Manual/Extending.html
index 7c2a6c66c..5749f37ce 100644
--- a/Doc/Manual/Extending.html
+++ b/Doc/Manual/Extending.html
@@ -3613,7 +3613,7 @@ A target language is given the 'Supported' status when
   Examples must be available and run successfully.
 </li>
 <li>
-  The examples and test-suite must be fully functioning on the Travis Continuous Integration platform.
+  The examples and test-suite must be fully functioning on the Github Actions Continuous Integration platform.
 </li>
 </ul>
 
@@ -3660,9 +3660,9 @@ Some minimum requirements and notes about languages with the 'Experimental' stat
   The number of tests in these lists should be no greater than half of the number of tests in the full test-suite.
 </li>
 <li>
-  The examples and test-suite must also be fully functioning on the Travis Continuous Integration platform.
-  However, experimental languages will be set as 'allow_failures'.
-  This means that pull requests and normal development commits will not break the entire Travis build should an experimental language fail.
+  The examples and test-suite must also be fully functioning on the Github Actions Continuous Integration platform.
+  However, experimental languages will be flagged as 'continue-on-error'.
+  This means that pull requests and normal development commits will not break the entire Github Actions build should an experimental language fail.
 </li>
 <li>
   Any new failed tests will be fixed on a 'best effort' basis by core developers with no promises made.
diff --git a/Doc/Manual/Go.html b/Doc/Manual/Go.html
index 1a5bb08c7..4e230c78b 100644
--- a/Doc/Manual/Go.html
+++ b/Doc/Manual/Go.html
@@ -71,6 +71,7 @@ code.  SWIG fills this gap.
 There are (at least) two different Go compilers.  The first is the gc compiler
 of the <a href="https://golang.org/doc/install">Go distribution</a>, normally
 invoked via the <a href="https://golang.org/cmd/go/">go tool</a>.
+SWIG supports the gc compiler version 1.2 or later.
 The second Go compiler is the <a href="https://golang.org/doc/install/gccgo">
 gccgo compiler</a>, which is a frontend to the GCC compiler suite.
 The interface to C/C++ code is completely different for the two Go compilers.
@@ -142,44 +143,6 @@ You will now have a Go package that you can import from other Go packages as
 usual.
 </p>
 
-<p>
-SWIG can be used without cgo, via the <tt>-no-cgo</tt> option, but
-more steps are required.  This only works with Go versions before 1.5.
-When using Go version 1.2 or later, or when using gccgo, the code
-generated by SWIG can be linked directly into the Go program.  A
-typical command sequence when using the Go compiler of the Go
-distribution would look like this:
-</p>
-
-<div class="code"><pre>
-% swig -go -no-cgo example.i
-% gcc -c code.c    # The C library being wrapped.
-% gcc -c example_wrap.c
-% go tool 6g example.go
-% go tool 6c example_gc.c
-% go tool pack grc example.a example.6 example_gc.6 code.o example_wrap.o
-% go tool 6g main.go
-% go tool 6l main.6
-</pre></div>
-
-<p>
-You can also put the wrapped code into a shared library, and when using the Go
-versions before 1.2 this is the only supported option.  A typical command
-sequence for this approach would look like this:
-</p>
-
-<div class="code"><pre>
-% swig -go -no-cgo -use-shlib example.i
-% gcc -c -fpic example.c
-% gcc -c -fpic example_wrap.c
-% gcc -shared example.o example_wrap.o -o example.so
-% go tool 6g example.go
-% go tool 6c example_gc.c
-% go tool pack grc example.a example.6 example_gc.6
-% go tool 6g main.go  # your code, not generated by SWIG
-% go tool 6l main.6
-</pre></div>
-
 
 <H3><a name="Go_commandline">25.3.1 Go-specific Commandline Options</a></H3>
 
@@ -206,9 +169,7 @@ swig -go -help
 
 <tr>
 <td>-no-cgo</td>
-<td>Generate files that can be used directly, rather than via the Go
-  cgo tool.  This option does not work with Go 1.5 or later.  It is
-  required for versions of Go before 1.2.</td>
+<td>This option is no longer supported.</td>
 </tr>
 
 <tr>
@@ -279,13 +240,10 @@ swig -go -help
 <H3><a name="Go_outputs">25.3.2 Generated Wrapper Files</a></H3>
 
 
-<p>There are two different approaches to generating wrapper files,
-  controlled by SWIG's <tt>-no-cgo</tt> option.  The <tt>-no-cgo</tt>
-  option only works with version of Go before 1.5.  It is required
-  when using versions of Go before 1.2.</p>
-
-<p>With or without the <tt>-no-cgo</tt> option, SWIG will generate the
-  following files when generating wrapper code:</p>
+<p>
+SWIG will generate the following files when generating wrapper
+code:
+</p>
 
 <ul>
 <li>
@@ -308,17 +266,6 @@ or C++ compiler.
 </li>
 </ul>
 
-<p>When the <tt>-no-cgo</tt> option is used, and the <tt>-gccgo</tt>
-  option is not used, SWIG will also generate an additional file:</p>
-
-<ul>
-<li>
-MODULE_gc.c will contain C code which should be compiled with the C
-compiler distributed as part of the gc compiler.  It should then be
-combined with the compiled MODULE.go using go tool pack.
-</li>
-</ul>
-
 
 <H2><a name="Go_basic_tour">25.4 A tour of basic C/C++ wrapping</a></H2>
 
diff --git a/Doc/Manual/Java.html b/Doc/Manual/Java.html
index 3b24c5ba8..03e3c9124 100644
--- a/Doc/Manual/Java.html
+++ b/Doc/Manual/Java.html
@@ -9068,6 +9068,11 @@ Here the default typemaps work for <tt>int</tt> and <tt>char *</tt>.
 </p>
 
 <p>
+Note that if you're wanting to effectively <b>replace</b> the JNI code generated for a C/C++ function then you'll need to use <tt>%ignore</tt> as well
+to tell SWIG not to automatically generate a JNI wrapper for it.
+</p>
+
+<p>
 In summary the <tt>%native</tt> directive is telling SWIG to generate the Java code to access the JNI C code, but not the JNI C function itself.
 This directive is only really useful if you want to mix your own hand crafted JNI code and the SWIG generated code into one Java class or package.
 </p>
@@ -9100,7 +9105,7 @@ This method normally calls the C++ destructor or <tt>free()</tt> for C code.
 <p>
 The generated code can be debugged using both a Java debugger and a C++ debugger using the usual debugging techniques.
 Breakpoints can be set in either Java or C++ code and so both can be debugged simultaneously.
-Most debuggers do not understand both Java and C++, with one noteable exception of Sun Studio, 
+Most debuggers do not understand both Java and C++, with one notable exception of Sun Studio, 
 where it is possible to step from Java code into a JNI method within one environment.
 </p>
 
diff --git a/Doc/Manual/Javascript.html b/Doc/Manual/Javascript.html
index 54bd68521..ab8657510 100644
--- a/Doc/Manual/Javascript.html
+++ b/Doc/Manual/Javascript.html
@@ -89,24 +89,10 @@ $ swig -javascript -jsc example.i</pre>
 <pre>
 $ swig -c++ -javascript -jsc example.i</pre>
 </div>
-<p>The V8 code that SWIG generates should work with most versions from 3.11.10.
-However, the only early version that receives some testing is 3.14.5, which is
-still shipped with Ubuntu for some reason. Other than that it's probably safer
-to assume that versions earlier than 5.0 are no longer supported. Keep in mind
-that these are V8 versions, not Node.js. To give some perspective, Node.js v6.0
+<p>The V8 code that SWIG generates requires at least V8 5.0. Keep in mind
+that this is theV8 version, not Node.js. To give some perspective, Node.js v6.0
 uses V8 5.0, v12.0 - 7.4, v14.0 - 8.1...</p>
-<p>The API headers for V8 &gt;= 4.3.10 define constants which SWIG can use to
-determine the V8 version it is compiling for.  For versions &lt; 4.3.10, you
-need to specify the V8 version when running SWIG.  This is specified as a hex
-constant, but the constant is read as pairs of decimal digits, so for V8
-3.25.30 use constant 0x032530.  This scheme can't represent components &gt; 99,
-but this constant is only useful for V8 &lt; 4.3.10, and no V8 versions from
-that era had a component &gt; 99.  For example:</p>
-<div class="shell">
-<pre>
-$ swig -c++ -javascript -v8 -DV8_VERSION=0x032530 example.i</pre>
-</div>
-<p>If you're targeting V8 &gt;= 4.3.10, you would just run swig like so:</p>
+<p>To generate code for V8, you would run swig like so:</p>
 <div class="shell">
 <pre>
 $ swig -c++ -javascript -v8 example.i</pre>
diff --git a/Doc/Manual/Ocaml.html b/Doc/Manual/Ocaml.html
index 4ae07e969..9b59eec61 100644
--- a/Doc/Manual/Ocaml.html
+++ b/Doc/Manual/Ocaml.html
@@ -720,7 +720,6 @@ Here's a simple example using Trolltech's Qt Library:
 class QApplication {
 public:
   QApplication( int argc, char **argv );
-  void setMainWidget( QWidget *widget );
   void exec();
 };
 
@@ -736,16 +735,15 @@ public:
 
 
 <div class="code"><pre>
-bash-2.05a$ QTPATH=/your/qt/path
-bash-2.05a$ for file in swig.mli swig.ml swigp4.ml ; do swig -ocaml -co $file ; done
-bash-2.05a$ ocamlc -c swig.mli ; ocamlc -c swig.ml
-bash-2.05a$ ocamlc -I `camlp4 -where` -pp "camlp4o pa_extend.cmo q_MLast.cmo" -c swigp4.ml
-bash-2.05a$ swig -ocaml -c++ -I$QTPATH/include qt.i
-bash-2.05a$ mv qt_wrap.cxx qt_wrap.c
-bash-2.05a$ ocamlc -c -ccopt -xc++ -ccopt -g -g -ccopt -I$QTPATH/include qt_wrap.c
-bash-2.05a$ ocamlc -c qt.mli
-bash-2.05a$ ocamlc -c qt.ml
-bash-2.05a$ ocamlmktop -custom swig.cmo -I `camlp4 -where` \
+$ QTPATH=/your/qt/path
+$ for file in swig.mli swig.ml swigp4.ml ; do swig -ocaml -co $file ; done
+$ ocamlc -c swig.mli ; ocamlc -c swig.ml
+$ ocamlc -I `camlp4 -where` -pp "camlp4o pa_extend.cmo q_MLast.cmo" -c swigp4.ml
+$ swig -ocaml -c++ -o qt_wrap.c qt.i
+$ ocamlc -c -ccopt -xc++ -ccopt -g -g -ccopt -I$QTPATH/include qt_wrap.c
+$ ocamlc -c qt.mli
+$ ocamlc -c qt.ml
+$ ocamlmktop -custom swig.cmo -I `camlp4 -where` \
   camlp4o.cma swigp4.cmo qt_wrap.o qt.cmo -o qt_top -cclib \
   -L$QTPATH/lib -cclib -lqt
 </pre></div>
diff --git a/Doc/Manual/Octave.html b/Doc/Manual/Octave.html
index bdef5db7c..151957cff 100644
--- a/Doc/Manual/Octave.html
+++ b/Doc/Manual/Octave.html
@@ -570,13 +570,13 @@ __mul__        a * b
 __div__        a / b
 __pow__        a ^ b
 __ldiv__       a \ b
-__lshift__     a << b
-__rshift__     a >> b
-__lt__         a < b
-__le__         a <= b
+__lshift__     a &lt;&lt; b
+__rshift__     a &gt;&gt; b
+__lt__         a &lt; b
+__le__         a &lt;= b
 __eq__         a == b
-__ge__         a >= b
-__gt__         a > b
+__ge__         a &gt;= b
+__gt__         a &gt; b
 __ne__         a != b
 __el_mul__     a .* b
 __el_div__     a ./ b
@@ -598,16 +598,16 @@ On the C++ side, the default mappings are as follows:
 %rename(__mul__)       *::operator*;
 %rename(__div__)       *::operator/;
 %rename(__mod__)       *::operator%;
-%rename(__lshift__)    *::operator<<;
-%rename(__rshift__)    *::operator>>;
+%rename(__lshift__)    *::operator&lt;&lt;;
+%rename(__rshift__)    *::operator&gt;&gt;;
 %rename(__el_and__)    *::operator&amp;&amp;;
 %rename(__el_or__)     *::operator||;
 %rename(__xor__)       *::operator^;
 %rename(__invert__)    *::operator~;
-%rename(__lt__)        *::operator<;
-%rename(__le__)        *::operator<=;
-%rename(__gt__)        *::operator>;
-%rename(__ge__)        *::operator>=;
+%rename(__lt__)        *::operator&lt;;
+%rename(__le__)        *::operator&lt;=;
+%rename(__gt__)        *::operator&gt;;
+%rename(__ge__)        *::operator&gt;=;
 %rename(__eq__)        *::operator==;
 %rename(__ne__)        *::operator!=;
 %rename(__not__)       *::operator!;
@@ -634,7 +634,7 @@ You can use it to define special behavior, like for example defining Octave oper
 %extend A {
 string __str__() {
   stringstream sout;
-  sout&lt;&lt;$self->value;
+  sout&lt;&lt;$self-&gt;value;
   return sout.str();
 }
 }
diff --git a/Doc/Manual/Perl5.html b/Doc/Manual/Perl5.html
index 85c2545cf..03dcfe6bb 100644
--- a/Doc/Manual/Perl5.html
+++ b/Doc/Manual/Perl5.html
@@ -91,10 +91,10 @@
 <p>
 This chapter describes SWIG's support of Perl5. Although the Perl5
 module is one of the earliest SWIG modules, it has continued to evolve
-and has been improved greatly with the help of SWIG users. For the
-best results, it is recommended that SWIG be used with Perl 5.8 or
-later. We're no longer testing regularly with older versions, but
-Perl 5.6 seems to mostly work, while older versions don't.
+and has been improved greatly with the help of SWIG users. As of SWIG
+4.1.0, the minimum version of Perl we aim to support is Perl 5.8.0.
+We can no longer easily test with older versions, and they no longer
+seem to be in active use.
 </p>
 
 <H2><a name="Perl5_nn2">31.1 Overview</a></H2>
@@ -680,7 +680,6 @@ files(s) field".
 installation under "Additional include directories".
 
 <li>Define the symbols WIN32 and MSWIN32 under preprocessor options.
-If using the ActiveWare port, also define the symbol PERL_OBJECT.
 Note that all extensions to the ActiveWare port must be compiled with
 the C++ compiler since Perl has been encapsulated in a C++ class.
 
@@ -2651,8 +2650,8 @@ constructors and destructors for the package and are always named
 "new" and "DESTROY".  The constructor always returns a tied hash
 table.  This hash table is used to access the member variables of a
 structure in addition to being able to invoke member functions.  The
-<tt>%OWNER</tt> and <tt>%BLESSEDMEMBERS</tt> hash tables are used
-internally and described shortly.
+<tt>%OWNER</tt> and <tt>%BLESSEDMEMBERS</tt> hash tables are
+implementation details used internally and described shortly.
 </p>
 
 <p>
@@ -2740,8 +2739,15 @@ to a C function that remembers the object, and then destroy the
 corresponding Perl object (this situation turns out to come up
 frequently when constructing objects like linked lists and trees).
 When C takes possession of an object, you can change Perl's ownership
-by simply deleting the object from the <tt>%OWNER</tt> hash.  This is
-done using the <tt>DISOWN</tt> method.
+by calling the <tt>DISOWN</tt> method (which will delete the object
+from the internal <tt>%OWNER</tt> hash).
+</p>
+
+<p>
+The <tt>%OWNER</tt> hash is an implementation detail, discussed here
+only to help clarify the operation of <tt>ACQUIRE</tt> and <tt>DISOWN</tt>.
+You should not access <tt>%OWNER</tt> directly - the details of how it
+works (and possibly even its existence) may chance in future SWIG versions.
 </p>
 
 <div class="targetlang"><pre>
diff --git a/Doc/Manual/Php.html b/Doc/Manual/Php.html
index 5aea878b2..8963a6c8d 100644
--- a/Doc/Manual/Php.html
+++ b/Doc/Manual/Php.html
@@ -50,18 +50,19 @@
 
 
 <p>
-In this chapter, we discuss SWIG's support of PHP.  SWIG currently supports
-generating wrappers for PHP7 and PHP8.  Support for PHP5 was removed in SWIG
-4.0.0 and support for PHP4 was removed in SWIG 1.3.37.
+In this chapter, we discuss SWIG's support of PHP.  Currently any PHP7 or PHP8
+release should work.
 </p>
 
 <p>
-Currently any PHP7 or PHP8 release should work.
+Support for PHP7 was added in SWIG 3.0.11 and for PHP8 in 4.1.0.
+Support for PHP5 was removed in SWIG 4.0.0 and support for PHP4 was removed in
+SWIG 1.3.37.  There never was a PHP6 release.
 </p>
 
 <p>
 In order to use this module, you will need to have a copy of the PHP
-include files to compile the SWIG generated files.  If you installed
+include files to compile the SWIG generated C/C++ sources.  If you installed
 PHP from a binary package, you may need to install a "php-dev" or "php-devel"
 package for these to be installed.  You can find out where these files are
 by running <tt>php-config --includes</tt>.  To use the built PHP module you
@@ -161,7 +162,7 @@ default extension directory, you also need to specify the path, for example:
 </p>
 
 <div class="code"><pre>
-	extension=/path/to/modulename.so
+        extension=/path/to/modulename.so
 </pre></div>
 
 <p>
@@ -343,6 +344,80 @@ $c = bar(3.5);  # Use default argument for 2nd parameter
 
 </pre></div>
 
+<p>
+SWIG generates PHP type declarations for function parameters and return
+types for PHP 8 and later (we don't try to support PHP 7's more limited type
+declarations and the generated wrappers compiled for PHP 7 will not have any
+type declarations).
+</p>
+
+<p>
+You can control the generation of PHP type declarations using
+the "php:type" %feature.  This has three settings:
+</p>
+
+<ul>
+    <li> <p>If unset or set to "0" then no type declarations are generated, e.g.: <tt>%feature("php:type", "0");</tt>
+      </p>
+    </li>
+    <li> <p>If set to "1" then type declarations are generated for both parameters and return types, e.g.: <tt>%feature("php:type", "1");</tt>
+      </p></li>
+      <li> <p>The default setting is "compat", which is the same as "1" except no
+      return type declarations are generated for virtual methods for which
+      directors are enabled.  This provides better compatibility for PHP
+      subclasses of wrapped virtual methods in existing SWIG-generated bindings, e.g.: <tt>%feature("php:type", "compat");</tt>
+      </p></li>
+</ul>
+
+<p>
+If you have an existing PHP interface and are upgrading to SWIG &gt;= 4.1.0
+then the default "compat" setting should work well.
+</p>
+
+<p>
+If you're writing a new set of bindings and <b>only targetting PHP8 or newer</b>
+then enabling type declarations everywhere probably makes sense.  It will
+only actually make a difference if you enable directors and are wrapping C++
+classes with virtual methods, but doing it anyway means you won't forget to if
+the code you are wrapping later evolves to have such classes and methods.
+</p>
+
+<p>
+The type declaration information will make the generated source code and
+compiler extension module larger, so you might want to turn off type
+declarations if keeping these small is important to you.  If you find you
+need to turn off type declarations to fix a problem, please let us know
+via our github issue tracker.
+</p>
+
+<p>
+Note that being a SWIG feature this can be specified globally (like above) or
+per class, per method, etc.  See the <a
+href="Customization.html#Customization_features">%feature directives</a>
+section for full details of how to control at a fine-grained level.
+</p>
+
+<p>
+The PHP type information is specified via a "phptype" attribute on "in" and
+"out" typemaps, and these have been added for all the typemaps we supply for
+PHP.  We don't currently support this for "argout" templates, but probably
+will in a future version.
+</p>
+
+<p>
+If you have written custom SWIG typemaps for PHP and want to add PHP type
+declarations, then the syntax is very like how you'd specify the type in
+PHP code, e.g. <tt>%typemap(in, phptype="int|string|Foo")</tt> means the
+typemap accepts a PHP int or string or an object of class Foo,
+<tt>%typemap(in, phptype="?int")</tt> means a PHP int or NULL, etc.
+As well as the standard PHP type declaration types, SWIG also understands the
+special type "SWIGTYPE" as an entry in phptype, which means the PHP type
+corresponding to the type that this typemap matched on - for a object this
+will give you the PHP class for the object, and for a pointer to a non-class
+type it will give you the name of the PHP class SWIG created for that
+pointer type.
+</p>
+
 <!-- This isn't correct for 1.3.30 and needs rewriting to reflect reality
 <p>
 Because PHP is a dynamically typed language, the default typemaps
@@ -426,6 +501,7 @@ taking the integer argument.
 
 <H3><a name="Php_nn2_5">32.2.5 Pointers and References</a></H3>
 
+
 <p>
 Since SWIG 4.1.0, SWIG wraps C/C++ classes directly with PHP objects.
 Pointers to other types are also wrapped as PHP objects - mostly this is an
@@ -742,7 +818,10 @@ class Ko {
 };
 </pre></div>
 
-would be executed in PHP as,
+<p>
+would be executed in PHP as
+</p>
+
 <div class="code"><pre>
 Ko::threats();
 </pre></div>
@@ -1158,7 +1237,7 @@ should suffice in most cases:
 </div>
 
 <p>
-If you only need to support SWIG >= 4.1.0, you can just use the
+If you only need to support SWIG &gt;= 4.1.0, you can just use the
 <tt>($error != NULL)</tt> condition.
 </p>
 
diff --git a/Doc/Manual/Preface.html b/Doc/Manual/Preface.html
index 36a99bd1f..41f21d48d 100644
--- a/Doc/Manual/Preface.html
+++ b/Doc/Manual/Preface.html
@@ -281,12 +281,12 @@ You must use <a href="http://www.gnu.org/software/make/">GNU make</a> to build a
 </p>
 
 <p>
-<a href="http://www.pcre.org/">PCRE</a>
+<a href="http://www.pcre.org/">PCRE2</a>
 needs to be installed on your system to build SWIG, in particular
-pcre-config must be available. If you have PCRE headers and libraries but not
-pcre-config itself or, alternatively, wish to override the compiler or linker
-flags returned by pcre-config, you may set PCRE_LIBS and PCRE_CFLAGS variables
-to be used instead. And if you don't have PCRE at all, the configure script
+pcre2-config must be available. If you have PCRE2 headers and libraries but not
+pcre2-config itself or, alternatively, wish to override the compiler or linker
+flags returned by pcre2-config, you may set PCRE2_LIBS and PCRE2_CFLAGS variables
+to be used instead. And if you don't have PCRE2 at all, the configure script
 will provide instructions for obtaining it.
 </p>
 
diff --git a/Doc/Manual/Python.html b/Doc/Manual/Python.html
index c132afc8a..2d78c4707 100644
--- a/Doc/Manual/Python.html
+++ b/Doc/Manual/Python.html
@@ -1608,7 +1608,7 @@ public:
 </div>
 
 <p>
-In Python, the static member can be access in three different ways:
+In Python, the static member can be accessed in three different ways:
 </p>
 
 <div class="targetlang">
@@ -1616,7 +1616,7 @@ In Python, the static member can be access in three different ways:
 &gt;&gt;&gt; example.Spam_foo()    # Spam::foo()
 &gt;&gt;&gt; s = example.Spam()
 &gt;&gt;&gt; s.foo()               # Spam::foo() via an instance
-&gt;&gt;&gt; example.Spam.foo()    # Spam::foo(). Python-2.2 only
+&gt;&gt;&gt; example.Spam.foo()    # Spam::foo() using Python-2.2 and later
 </pre>
 </div>
 
@@ -1627,16 +1627,31 @@ last technique is only available in Python-2.2 and later versions.
 
 <p>
 Static member variables are currently accessed as global variables.  This means,
-they are accessed through <tt>cvar</tt> like this:
+they are accessed through <tt>cvar</tt> or via an instance property:
 </p>
 
 <div class="targetlang">
 <pre>
-&gt;&gt;&gt; print example.cvar.Spam_bar
+&gt;&gt;&gt; example.cvar.Spam_bar # Spam::bar
+7
+&gt;&gt;&gt; s = example.Spam()
+&gt;&gt;&gt; s.bar                 # Spam::bar via an instance property
+7
+</pre>
+</div>
+
+<p>
+The <tt>-builtin</tt> option uses a metaclass to additionally provide access as follows:
+</p>
+
+<div class="targetlang">
+<pre>
+&gt;&gt;&gt; example.Spam.bar      # Spam::bar using -builtin option only
 7
 </pre>
 </div>
 
+
 <H3><a name="Python_nn21">33.3.8 C++ inheritance</a></H3>
 
 
@@ -4939,7 +4954,6 @@ object to be used as a <tt>char **</tt> object.
       if (PyString_Check(o)) {
         $1[i] = PyString_AsString(PyList_GetItem($input, i));
       } else {
-        free($1);
         PyErr_SetString(PyExc_TypeError, "list must contain strings");
         SWIG_fail;
       }
@@ -5038,7 +5052,6 @@ previous example:
       if (PyString_Check(o)) {
         $2[i] = PyString_AsString(PyList_GetItem($input, i));
       } else {
-        free($2);
         PyErr_SetString(PyExc_TypeError, "list must contain strings");
         SWIG_fail;
       }
diff --git a/Doc/Manual/R.html b/Doc/Manual/R.html
index e44fe432c..9b05922fd 100644
--- a/Doc/Manual/R.html
+++ b/Doc/Manual/R.html
@@ -196,7 +196,7 @@ slices)
 <p>
 Wrapping of C++ classes for R works quite well. R has a special
 type, known as an external reference, that can be used as a pointer
-to arbitary things, including C++ classes. The proxy layers generated
+to arbitrary things, including C++ classes. The proxy layers generated
 for other classes are not required.
 </p>
 
@@ -265,7 +265,7 @@ v2$Axles
 [1] 4
 v1$Available
 [1] FALSE
-# Set availabilty
+# Set availability
 v1$Available &lt;- TRUE
 v1$Available
 [1] TRUE
diff --git a/Doc/Manual/SWIG.html b/Doc/Manual/SWIG.html
index 876c0ac17..f310fe237 100644
--- a/Doc/Manual/SWIG.html
+++ b/Doc/Manual/SWIG.html
@@ -47,6 +47,7 @@
 <li><a href="#SWIG_rename_ignore">Renaming and ignoring declarations</a>
 <ul>
 <li><a href="#SWIG_nn29">Simple renaming of specific identifiers</a>
+<li><a href="#SWIG_ignore">Ignoring identifiers</a>
 <li><a href="#SWIG_advanced_renaming">Advanced renaming support</a>
 <li><a href="#SWIG_limiting_renaming">Limiting global renaming rules</a>
 <li><a href="#SWIG_chosen_unignore">Ignoring everything then wrapping a few selected symbols</a>
@@ -208,7 +209,7 @@ General Options
      -oh &lt;headfile&gt;  - Set name of C++ output header file for directors to &lt;headfile&gt;
      -outcurrentdir  - Set default output dir to current dir instead of input file's path
      -outdir &lt;dir&gt;   - Set language specific files output directory to &lt;dir&gt;
-     -pcreversion    - Display PCRE version information
+     -pcreversion    - Display PCRE2 version information
      -small          - Compile in virtual elimination and compact mode
      -swiglib        - Report location of SWIG library and exit
      -templatereduce - Reduce all the typedefs in templates
@@ -1469,14 +1470,14 @@ SWIG generates the following code:
 <pre>
 /* C mode */
 void foo_set(char *value) {
-  if (foo) free(foo);
+  free(foo);
   foo = (char *) malloc(strlen(value)+1);
   strcpy(foo, value);
 }
 
 /* C++ mode.  When -c++ option is used */
 void foo_set(char *value) {
-  if (foo) delete [] foo;
+  delete [] foo;
   foo = new char[strlen(value)+1];
   strcpy(foo, value);
 }
@@ -1842,6 +1843,25 @@ all to `output' by specifying :</p>
 </pre></div>
 
 <p>
+A new <tt>%rename</tt> for the same name will replace the current
+<tt>%rename</tt> for all uses after it in the file, and setting the
+new name to "" will remove the rename.  So, for instance, if you
+wanted to rename some things in one file and not in another, you could
+do:
+</p>
+
+<div class="code">
+<pre>
+  %rename(print1) print;
+  %include "header1.h" //Anything "print" in here will become "print1"
+  %rename(print2) print;
+  %include "header2.h" //Anything "print" in here will become "print2"
+  %rename("") print;
+  %include "header3.h" //Anything "print" in here will remain "print"
+</pre>
+</div>
+
+<p>
 SWIG does not normally perform any checks to see if the functions it wraps are
 already defined in the target scripting language. However, if you are
 careful about namespaces and your use of modules, you can usually
@@ -1857,6 +1877,9 @@ If you are using the <tt>%rename</tt> directive and C++, make sure you read the
 for method overloading and default arguments.
 </p>
 
+<H4><a name="SWIG_ignore">5.4.7.2 Ignoring identifiers</a></H4>
+
+
 <p>
 Closely related to <tt>%rename</tt> is the <tt>%ignore</tt> directive.  <tt>%ignore</tt> instructs SWIG
 to ignore declarations that match a given identifier.  For example:
@@ -1896,7 +1919,7 @@ This directive is still supported, but it is deprecated and should probably be a
 directive is more powerful and better supports wrapping of raw header file information.
 </p>
 
-<H4><a name="SWIG_advanced_renaming">5.4.7.2 Advanced renaming support</a></H4>
+<H4><a name="SWIG_advanced_renaming">5.4.7.3 Advanced renaming support</a></H4>
 
 
 <p>
@@ -2022,8 +2045,8 @@ and a more descriptive one, but the two functions are otherwise equivalent:
     <td>String after (Perl-like) regex substitution operation. This function
     allows applying arbitrary regular expressions to the identifier names. The
     <i>pattern</i> part is a regular expression in Perl syntax (as supported
-    by the <a href="http://www.pcre.org/">Perl Compatible Regular Expressions (PCRE)</a>)
-    library and the <i>subst</i> string
+    by the <a href="http://www.pcre.org/">Perl Compatible Regular Expressions</a>)
+    (PCRE2 library) and the <i>subst</i> string
     can contain back-references of the form <tt>\N</tt> where <tt>N</tt> is a digit
     from 0 to 9, or one of the following escape sequences: <tt>\l</tt>, <tt>\L</tt>,
     <tt>\u</tt>, <tt>\U</tt> or <tt>\E</tt>. The back-references are replaced with the
@@ -2105,7 +2128,7 @@ are exactly equivalent and <tt>%rename</tt> can be used to selectively ignore
 multiple declarations using the previously described matching possibilities.
 </p>
 
-<H4><a name="SWIG_limiting_renaming">5.4.7.3 Limiting global renaming rules</a></H4>
+<H4><a name="SWIG_limiting_renaming">5.4.7.4 Limiting global renaming rules</a></H4>
 
 
 <p>
@@ -2203,7 +2226,7 @@ wrap C++ overloaded functions and methods or C++ methods which use default argum
 </p>
 
 
-<H4><a name="SWIG_chosen_unignore">5.4.7.4 Ignoring everything then wrapping a few selected symbols</a></H4>
+<H4><a name="SWIG_chosen_unignore">5.4.7.5 Ignoring everything then wrapping a few selected symbols</a></H4>
 
 
 <p>
@@ -2227,6 +2250,23 @@ the following approach could be taken:
 %rename("%s") Star::shine; // named method
 
 %include "myheader.h"
+
+%rename("%s") ""; // Undo the %ignore
+</pre>
+</div>
+
+<p>
+If <tt>Star</tt> was in the <tt>Galaxy</tt> namespace, you would need
+to unignore the namespace, too, and add the namespace to all the
+renames:
+</p>
+
+<div class="code">
+<pre>
+%rename("%s") Galaxy;
+%rename("%s") Galaxy::Star;
+%rename("%s") Galaxy::Star::Star;
+...
 </pre>
 </div>
 
@@ -2241,6 +2281,7 @@ members of the class, so when the chosen class is unignored, all of its methods
 %rename($ignore, %$isclass) ""; // Only ignore all classes
 %rename("%s") Star; // Unignore 'Star'
 %include "myheader.h"
+%rename("%s", %$isclass) ""; // Stop ignoring all classes
 </pre>
 </div>
 
@@ -2594,8 +2635,7 @@ char *Foo_name_get(Foo *obj) {
 }
 
 char *Foo_name_set(Foo *obj, char *c) {
-  if (obj-&gt;name)
-    free(obj-&gt;name);
+  free(obj-&gt;name);
   obj-&gt;name = (char *) malloc(strlen(c)+1);
   strcpy(obj-&gt;name, c);
   return obj-&gt;name;
@@ -2977,6 +3017,11 @@ typedef struct Vector {
 </div>
 
 <p>
+You'll also need to use these names if you want to directly call methods added
+using <tt>%extend</tt> from other C/C++ code.
+</p>
+
+<p>
 The name used for %extend should be the name of the struct and not the name of any typedef to the struct.
 For example:
 </p>
diff --git a/Doc/Manual/SWIGPlus.html b/Doc/Manual/SWIGPlus.html
index 0c259e393..d480f61f3 100644
--- a/Doc/Manual/SWIGPlus.html
+++ b/Doc/Manual/SWIGPlus.html
@@ -48,6 +48,9 @@
 </ul>
 <li><a href="#SWIGPlus_nn28">Overloaded operators</a>
 <li><a href="#SWIGPlus_class_extension">Class extension</a>
+<ul>
+<li><a href="#SWIGPlus_replacing_methods">Replacing class methods</a>
+</ul>
 <li><a href="#SWIGPlus_nn30">Templates</a>
 <ul>
 <li><a href="#SWIGPlus_template_directive">The %template directive</a>
@@ -2944,6 +2947,59 @@ be used to extend a structure with more than just methods, a more suitable
 directive name has been chosen.
 </p>
 
+<H3><a name="SWIGPlus_replacing_methods">6.17.1 Replacing class methods</a></H3>
+
+
+<p>
+Suppose there is a method in a class that you need to replace and keep the method name the same.
+This can be achieved combining the <tt>%extend</tt> and <tt>%ignore</tt> directives covered earlier.
+Here is an example to replace the <tt>MyClass::mymethod()</tt>:
+
+<div class="code">
+<pre>
+%extend MyClass {
+  void mymethod() {
+    std::cout &lt;&lt; "swig mymethod" &lt;&lt; std::endl;
+  }
+}
+
+%ignore MyClass::mymethod;
+
+%inline %{
+class MyClass {
+public:
+  void mymethod() {
+    std::cout &lt;&lt; "class mymethod" &lt;&lt; std::endl;
+  }
+};
+%}
+</pre>
+</div>
+
+<p>
+Or if your code organization makes more sense to put
+the <tt>%extend</tt> after the class definition, you would need the following:
+</p>
+
+<div class="code">
+<pre>
+%rename("") MyClass::mymethod; // unignores the method
+</pre>
+</div>
+
+<p>
+before the <tt>%extend</tt> or SWIG will continue to ignore
+<tt>mymethod()</tt>, even in an <tt>%extend</tt>.
+</p>
+
+<p>
+Note that you can call the class method from the method
+in <tt>%extend</tt>, just use <tt>self-&gt;mymethod()</tt> and it will call
+the class method, not the one in <tt>%extend</tt>.
+</p>
+
+
+
 <H2><a name="SWIGPlus_nn30">6.18 Templates</a></H2>
 
 
@@ -3632,7 +3688,7 @@ Alternatively, you could expand the constructor template in selected instantiati
 
 // Create default and conversion constructors 
 %extend pair&lt;double, double&gt; {
-  %template(paird) pair&lt;double, dobule&gt;;   // Default constructor
+  %template(paird) pair&lt;double, double&gt;;   // Default constructor
   %template(pairc) pair&lt;int, int&gt;;         // Conversion constructor
 };
 </pre>
@@ -3647,7 +3703,7 @@ instead:
 <pre>
 // Create default and conversion constructors 
 %extend pair&lt;double, double&gt; {
-  %template(pair) pair&lt;double, dobule&gt;;   // Default constructor
+  %template(pair) pair&lt;double, double&gt;;   // Default constructor
   %template(pair) pair&lt;int, int&gt;;         // Conversion constructor
 };
 </pre>
diff --git a/Doc/Manual/Tcl.html b/Doc/Manual/Tcl.html
index 0a22afb18..4535edeb3 100644
--- a/Doc/Manual/Tcl.html
+++ b/Doc/Manual/Tcl.html
@@ -1227,7 +1227,15 @@ _108fea88_p_Bar
 
 <p>
 Finally, to destroy objects created from Tcl, you can either let the object
-name go out of scope or you can explicitly delete the object.  For example:
+name go out of scope or you can explicitly delete the object as shown below.
+Objects won't get automatically destroyed when the Tcl program exits, so if
+it's important that the C++ destructor is called for a class you'll need to
+make sure that you explicitly do this for objects of that class before program
+exit.
+</p>
+
+<p>
+For example:
 </p>
 
 <div class="code">
@@ -2811,9 +2819,7 @@ used as a <tt>char **</tt> object.
 
 // This gives SWIG some cleanup code that will get called after the function call
 %typemap(freearg) char ** {
-  if ($1) {
-    free($1);
-  }
+  free($1);
 }
 
 // Now a test functions
diff --git a/Doc/Manual/Typemaps.html b/Doc/Manual/Typemaps.html
index a12ede553..220af4398 100644
--- a/Doc/Manual/Typemaps.html
+++ b/Doc/Manual/Typemaps.html
@@ -3103,7 +3103,7 @@ as shown.   To work with heap allocated data, the following technique can be use
   }
 }
 %typemap(freearg) float value[ANY] {
-  if ($1) free($1);
+  free($1);
 }
 </pre>
 </div>
@@ -3556,7 +3556,7 @@ maps perform the conversion described for the above example:
 }
 
 %typemap(freearg) (int argc, char *argv[]) {
-  if ($2) free($2);
+  free($2);
 }
 
 /* Required for C++ method overloading */
diff --git a/Doc/Manual/Warnings.html b/Doc/Manual/Warnings.html
index 02197f1cb..5d4d3773b 100644
--- a/Doc/Manual/Warnings.html
+++ b/Doc/Manual/Warnings.html
@@ -428,6 +428,7 @@ example.i(4) : Syntax error in input(1).
 <li>324. Named nested template instantiations not supported. Processing as if no name was given to %template().
 <li>325. Nested <em>kind</em> not currently supported (<em>name</em> ignored).
 <li>326. Deprecated %extend name used - the <em>kind</em> name '<em>name</em>' should be used instead of the typedef name '<em>name</em>'.
+<li>327. Extern template ignored.
 <li>350. operator new ignored.
 <li>351. operator delete ignored.
 <li>352. operator+ ignored.
diff --git a/Doc/Manual/Windows.html b/Doc/Manual/Windows.html
index 9365070e9..7a39e88f3 100644
--- a/Doc/Manual/Windows.html
+++ b/Doc/Manual/Windows.html
@@ -1,4 +1,4 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
 <html>
 <head>
 <title>Getting started on Windows</title>
@@ -29,17 +29,16 @@
 </ul>
 <li><a href="#Windows_other_compilers">Instructions for using the Examples with other compilers</a>
 </ul>
-<li><a href="#Windows_cygwin_mingw">SWIG on Cygwin and MinGW</a>
-<ul>
 <li><a href="#Windows_swig_exe">Building swig.exe on Windows</a>
 <ul>
 <li><a href="#Windows_cmake">Building swig.exe using CMake</a>
-<li><a href="#Windows_mingw_msys">Building swig.exe using MSYS2</a>
+<li><a href="#Windows_msys2">Building swig.exe using MSYS2</a>
 <li><a href="#Windows_mingw_msys">Building swig.exe using MinGW and MSYS</a>
 <li><a href="#Windows_cygwin">Building swig.exe using Cygwin</a>
-</ul>
+<ul>
 <li><a href="#Windows_examples_cygwin">Running the examples on Windows using Cygwin</a>
 </ul>
+</ul>
 <li><a href="#Windows_interface_file">Microsoft extensions and other Windows quirks</a>
 </ul>
 </div>
@@ -210,94 +209,97 @@ RUBY_LIB: D:\ruby\lib\mswin32-ruby16.lib<br>
 If you do not have access to Visual C++ you will have to set up project files / Makefiles for your chosen compiler. There is a section in each of the language modules detailing what needs setting up using Visual C++ which may be of some guidance. Alternatively you may want to use Cygwin as described in the following section.
 </p>
 
-<H2><a name="Windows_cygwin_mingw">3.3 SWIG on Cygwin and MinGW</a></H2>
+<H2><a name="Windows_swig_exe">3.3 Building swig.exe on Windows</a></H2>
 
 
 <p>
-SWIG can also be compiled and run using <a href="http://www.cygwin.com">Cygwin</a> or <a href="http://www.mingw.org">MinGW</a> which provides a Unix like front end to Windows and comes free with gcc, an ISO C/C++ compiler. However, this is not a recommended approach as the prebuilt executable is supplied. 
+The SWIG distribution provides a pre-built swig.exe and so it is not necessary for users to build the SWIG executable.
+However, this section is provided for those that want to modify the SWIG source code in a Windows environment. 
+Normally this is not needed, so most people will want to ignore this section.
 </p>
 
-<H3><a name="Windows_swig_exe">3.3.1 Building swig.exe on Windows</a></H3>
-
-
 <p>
-If you want to replicate the build of swig.exe that comes with the download, follow the MinGW instructions below.
-This is not necessary to use the supplied swig.exe. 
-This information is provided for those that want to modify the SWIG source code in a Windows environment. 
-Normally this is not needed, so most people will want to ignore this section. 
+There are various ways to build the SWIG executable including <a href="https://cmake.org/">CMake</a> which is able to generate project files for building with Visual Studio.
+SWIG can also be compiled and run using <a href="https://www.msys2.org/">MSYS2</a>, <a href="http://www.cygwin.com">Cygwin</a> or <a href="http://www.mingw.org">MinGW</a>, all of which provide a Unix like front end to Windows and comes free with the gcc C/C++ compiler.
 </p>
 
-<H4><a name="Windows_cmake">3.3.1.1 Building swig.exe using CMake</a></H4>
+
+<H3><a name="Windows_cmake">3.3.1 Building swig.exe using CMake</a></H3>
 
 
 <p>
-SWIG can also be built using <a href="https://cmake.org/">CMake</a> and Visual Studio rather than autotools. As with the other approaches to 
+SWIG can be built using <a href="https://cmake.org/">CMake</a> and Visual Studio rather than autotools. As with the other approaches to 
 building SWIG the dependencies need to be installed. The steps below are one of a number of ways of installing the dependencies without requiring Cygwin or MinGW.
-For fully working build steps always check the Continuous Integration setups currently detailed in the <a href="https://github.com/swig/swig/blob/master/appveyor.yml">Appveyor YAML file</a>.
+For fully working build steps always check the Continuous Integration (CI) setups currently detailed in the <a href="https://github.com/swig/swig/blob/master/appveyor.yml">Appveyor YAML file</a>.
 </p>
 
 <ol>
     <li>
-        Install Nuget from <a href="https://www.nuget.org/downloads">https://www.nuget.org/downloads</a> (v5.8.1 is used in this example, and installed to C:\Tools). Nuget is the package manager
-        for .NET, but allows us to easily install <a href="https://www.pcre.org/">PCRE</a> and other dependencies required by SWIG.
+        Install Nuget from <a href="https://www.nuget.org/downloads">https://www.nuget.org/downloads</a> (v6.0.0 is used in this example, and installed to <tt>C:\Tools</tt>). Nuget is the package manager
+        for .NET, but allows us to easily install <a href="https://cmake.org/">CMake</a> and other dependencies required by SWIG.
     </li>
     <li>
-        Install CMake using the following command: <pre>C:\Tools\nuget install CMake-win64 -Version 3.15.5 -OutputDirectory C:\Tools\CMake</pre>
+        Install <a href="https://www.nuget.org/packages/CMake-win64/">CMake-win64 Nuget package</a> using the following command: <pre>C:\Tools\nuget install CMake-win64 -Version 3.15.5 -OutputDirectory C:\Tools\CMake</pre>
         Alternatively you can download CMake from <a href="https://cmake.org/download/">https://cmake.org/download/</a>.
     </li>
     <li>
-        Install Bison using the following command: <pre>C:\Tools\nuget install bison-win32 -Version 2.4.1.1 -OutputDirectory C:\Tools\bison</pre>
-        Alternatively download Bison from <a href="https://sourceforge.net/projects/gnuwin32/files/bison/">https://sourceforge.net/projects/gnuwin32/files/bison/</a> (2.4.1 is used in this example)
-        and save to a folder e.g. C:\Tools\Bison
+        Install the <a href="https://www.nuget.org/packages/bison/">Bison Nuget package</a> using the following command: <pre>C:\Tools\nuget install Bison -Version 3.7.4 -OutputDirectory C:\Tools\bison</pre>
+        Alternatively download Bison from <a href="https://sourceforge.net/projects/winflexbison/files/">https://sourceforge.net/projects/winflexbison/files/</a> (Bison 3.7.4 is used in this example)
+        and save to a folder e.g. <tt>C:\Tools\Bison</tt>
     </li>
     <li>
-        Install PCRE using Nuget using the following command: <pre>C:\Tools\nuget install pcre -Version 8.33.0.1 -OutputDirectory C:\Tools\pcre</pre>
+        Unfortunately, PCRE2 is not yet available on Nuget. Instead we will use CMake to build and install <a href="https://www.pcre.org/">PCRE2</a> to <tt>C:\Tools\pcre2</tt> using the following commands:
+        <div class="shell"><pre>
+cd C:\
+SET PATH=C:\Tools\CMake\CMake-win64.3.15.5\bin;%PATH%
+git clone https://github.com/PhilipHazel/pcre2.git
+cd pcre2
+cmake -G "Visual Studio 16 2019" -A x64 -DCMAKE_INSTALL_PREFIX=C:/Tools/pcre2 -S . -B build
+cmake --build build --config Release --target install
+        </pre></div>
+        Alternatively, set <tt>WITH_PCRE=OFF</tt> to disable PCRE2 support if you are sure you do not require it.
     </li>
     <li>
         We will also need the SWIG source code. Either download a zipped archive from GitHub, or if git is installed clone the latest codebase
         using <pre>git clone https://github.com/swig/swig.git</pre>
-        In this example we are assuming the source code is available at C:\swig
+        In this example we are assuming the source code is available at <tt>C:\swig</tt>
     </li>
-</ol>
-
-<p>
-    We are assuming Visual Studio 2017 is installed. For other versions of Visual Studio change <i>"Visual Studio 15 2017 Win64"</i> to the relevant
-    <a href="https://cmake.org/cmake/help/latest/manual/cmake-generators.7.html#visual-studio-generators">Visual Studio Generator</a>.
-    Now we have all the required dependencies we can build SWIG using the commands below. We add the required build tools to the system PATH, and then
-    build a Release version of SWIG. If all runs successfully a new swig.exe should be generated in a /Release folder.
-</p>
-
-<div class="shell">
-    <pre>
+    <li>
+    <p>
+        Now we have all the required dependencies we can build SWIG using the commands below. We are assuming Visual Studio 2019 is installed. For other versions of Visual Studio change <tt>"Visual Studio 16 2019 -A x64"</tt> to the relevant
+        <a href="https://cmake.org/cmake/help/latest/manual/cmake-generators.7.html#visual-studio-generators">Visual Studio Generator</a> and
+        architecture. We add the required build tools to the system PATH, and then
+        build a Release version of SWIG. If all runs successfully a new swig.exe should be generated in the <tt>C:/swig/install2/bin</tt> folder.
+    </p>
+    <div class="shell"> <pre>
 cd C:\swig
-SET PATH=C:\Tools\CMake\CMake-win64.3.15.5\bin;C:\Tools\bison\bison-win32.2.4.1.1\tools\native\bin;%PATH%
-SET PCRE_ROOT=C:\Tools\pcre\pcre.8.33.0.1\build\native
+SET PATH=C:\Tools\CMake\CMake-win64.3.15.5\bin;C:\Tools\bison\Bison.3.7.4\bin;%PATH%
+SET PCRE_ROOT=C:/Tools/pcre2
 SET PCRE_PLATFORM=x64
-cmake -G "Visual Studio 15 2017 Win64" -DCMAKE_INSTALL_PREFIX="%CD:\=/%/install2" -DCMAKE_C_FLAGS="/DPCRE_STATIC" ^
-  -DPCRE_INCLUDE_DIR=%PCRE_ROOT%/include -DPCRE_LIBRARY=%PCRE_ROOT%/lib/v110/%PCRE_PLATFORM%/Release/static/utf8/pcre8.lib .
-cmake --build . --config Release
+cmake -G "Visual Studio 16 2019" -A x64 -DCMAKE_INSTALL_PREFIX="%CD:\=/%/install2" -DCMAKE_C_FLAGS="/DPCRE2_STATIC" ^
+-DCMAKE_CXX_FLAGS="/DPCRE2_STATIC" -DPCRE2_INCLUDE_DIR=%PCRE_ROOT%/include -DPCRE2_LIBRARY=%PCRE_ROOT%/lib/pcre2-8-static.lib -S . -B build
+cmake --build build --config Release --target install
 
 REM to test the exe
-cd /Release
+cd install2/bin
 swig.exe -help
-</pre>
-</div>
-
+    </pre></div>
+    </li>
+</ol>
 <p>
     In addition to Release builds you can create a Debug build using:
 </p>
 <div class="shell">
-    <pre>cmake --build . --config Debug</pre>
+    <pre>cmake --build build --config Debug</pre>
 </div>
 <p>
-    A Visual Studio solution file should be generated named swig.sln. This can be opened and debugged by running the swig project and setting the
-    Debugging Command Arguments. For example to debug one of the test-suite .i files included with the SWIG source use the following:
+    A Visual Studio solution file should be generated named swig.sln. This can be opened and debugged by running the swig project and setting <tt>Properties &gt; Debugging &gt; Command Arguments</tt>. For example to debug one of the test-suite .i files included with the SWIG source use the following:
 </p>
 <div class="shell">
     <pre>-python -c++ -o C:\Temp\doxygen_parsing.cpp C:\swig\Examples\test-suite\doxygen_parsing.i</pre>
 </div>
 
-<H4><a name="Windows_mingw_msys">3.3.1.2 Building swig.exe using MSYS2</a></H4>
+<H3><a name="Windows_msys2">3.3.2 Building swig.exe using MSYS2</a></H3>
 
 
 <p>
@@ -310,7 +312,7 @@ Install the packages needed to build swig:<br>
 
 <div class="shell">
 <pre>
-pacman -S git autoconf automake bison gcc make pcre-devel
+pacman -S git autoconf automake bison gcc make pcre2-devel
 </pre>
 </div>
 
@@ -349,7 +351,7 @@ make install
 </pre>
 </div>
 
-<H4><a name="Windows_mingw_msys">3.3.1.3 Building swig.exe using MinGW and MSYS</a></H4>
+<H3><a name="Windows_mingw_msys">3.3.3 Building swig.exe using MinGW and MSYS</a></H3>
 
 
 <p>
@@ -444,10 +446,10 @@ the autotools will fail miserably on those.
   </li>
 
   <li>
-The PCRE third party library needs to be built next. 
-Download the latest PCRE source tarball, such as <tt>pcre-8.10.tar.bz2</tt>, from 
-<a href=http://www.pcre.org>PCRE</a> and place in the <tt>/usr/src/swig</tt> directory.
-Build PCRE as a static library using the Tools/pcre-build.sh script as follows:
+The PCRE2 third party library needs to be built next.
+Download the latest PCRE2 source tarball, such as <tt>pcre2-10.39.tar.bz2</tt>, from
+<a href=http://www.pcre.org>www.pcre.org</a> and place in the <tt>/usr/src/swig</tt> directory.
+Build PCRE2 as a static library using the Tools/pcre-build.sh script as follows:
 
 <div class="shell"><pre>
 cd /usr/src/swig
@@ -467,7 +469,7 @@ make
 </ol>
 
 
-<H4><a name="Windows_cygwin">3.3.1.4 Building swig.exe using Cygwin</a></H4>
+<H3><a name="Windows_cygwin">3.3.4 Building swig.exe using Cygwin</a></H3>
 
 
 <p>
@@ -479,7 +481,7 @@ These files are generated using the <tt>autogen.sh</tt> script and will only nee
 </p>
 
 
-<H3><a name="Windows_examples_cygwin">3.3.2 Running the examples on Windows using Cygwin</a></H3>
+<H4><a name="Windows_examples_cygwin">3.3.4.1 Running the examples on Windows using Cygwin</a></H4>
 
 
 <p>