Merge master and C++11 strongly typed enum support

Merging from master:
* 'master' of github.com:/swig/swig:
  Add more docs about _global_ prefix in typemap temporary variables
  Add clarification on _global_ prefix.
  fix for nested template defined out of class (issue #265)
  using an unknown constant emits a notice, not a warning
  Fix typo
  Consistently put whitespace outside of <tt>...</tt> and not inside
  wording tweak
  Go: Document memory management of C++ classes allocated in Go.  Fixes #266.
  revert unrelated file
  Fix #224
  Fixes for clang -fsanitize=undefined-trap -fsanitize-undefined-trap-on-error
  delete unmeaningful macro
  Go: fix overload functions with polymorphic issue
  del tmp files
  GoLang:fix overload functions with polymorphic issue

Doc/Manual/Contents.html

@@ -854,6 +854,7 @@
 <li><a href="Go.html#Go_enumerations">Go Enumerations</a>
 <li><a href="Go.html#Go_classes">Go Classes</a>
 <ul>
+<li><a href="Go.html#Go_class_memory">Go Class Memory Management</a>
 <li><a href="Go.html#Go_class_inheritance">Go Class Inheritance</a>
 </ul>
 <li><a href="Go.html#Go_templates">Go Templates</a>

Doc/Manual/Customization.html

@@ -547,7 +547,7 @@ Below shows the expansions for the 1st of the overloaded <tt>something</tt> wrap
 The <tt>exception.i</tt> library file provides support for creating
 language independent exceptions in your interfaces.  To use it, simply
 put an "<tt>%include exception.i</tt>" in your interface file.  This
-creates a function<tt> SWIG_exception()</tt> that can be used to raise
+provides a function <tt>SWIG_exception()</tt> that can be used to raise
 common scripting language exceptions in a portable manner.  For example :</p>
 
 <div class="code"><pre>

Doc/Manual/Go.html

@@ -23,6 +23,7 @@
 <li><a href="#Go_enumerations">Go Enumerations</a>
 <li><a href="#Go_classes">Go Classes</a>
 <ul>
+<li><a href="#Go_class_memory">Go Class Memory Management</a>
 <li><a href="#Go_class_inheritance">Go Class Inheritance</a>
 </ul>
 <li><a href="#Go_templates">Go Templates</a>
@@ -375,7 +376,40 @@ 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_inheritance"></a>23.3.5.1 Go Class Inheritance</H4>
+<H4><a name="Go_class_memory"></a>23.3.5.1 Go Class Memory Management</H4>
+
+
+<p>
+Calling <tt>NewClassName</tt> for some C++ class <tt>ClassName</tt>
+will allocate memory using the C++ memory allocator.  This memory will
+not be automatically freed by Go's garbage collector.  When you are
+done with the C++ object you must free it using <tt>DeleteClassName</tt>.
+</p>
+
+<p>
+A common technique is to store the C++ object into a Go object, and
+use the Go function <tt>runtime.SetFinalizer</tt> to free the C++
+object when the Go object is freed.  For example, if the SWIG package
+is imported as "wrap":
+</p>
+<div class="code">
+<pre>
+type GoClassName struct {
+	w wrap.ClassName
+}
+
+func NewGoClassName() *GoClassName {
+	r := &amp;GoClassName{wrap.NewClassName()}
+	runtime.SetFinalizer(r,
+		func(r *GoClassName) {
+			wrap.DeleteClassName(r.w)
+		})
+	return r
+}
+</pre>
+</div>
+
+<H4><a name="Go_class_inheritance"></a>23.3.5.2 Go Class Inheritance</H4>
 
 
 <p>

Doc/Manual/Java.html

@@ -358,7 +358,7 @@ more aggressive from gcc-4.0 onwards and will result in code that fails with str
 <p>
 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>
+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"></a>25.2.5 Using your module</H3>
 
@@ -2441,7 +2441,7 @@ It also contains all the methods in the C++ class it is proxying plus getters an
 member variables. These functions call the native methods in the intermediary JNI class. 
 The advantage of having this extra layer is the type safety that the proxy class functions offer. 
 It adds static type checking which leads to fewer surprises at runtime. 
-For example, you can see that if you attempt to use the <tt> spam() </tt> 
+For example, you can see that if you attempt to use the <tt>spam()</tt>
 function it will only compile when the parameters passed are an <tt>int</tt> and a <tt>Foo</tt>. 
 From a user's point of view, it makes the class work as if it were a Java class:
 </p>
@@ -4173,8 +4173,8 @@ void *malloc(size_t nbytes);
 
 <p>
 If no declaration name is given to <tt>%exception</tt>, it is applied to all wrapper functions.
-The <tt> $action </tt> is a SWIG special variable and is replaced by the C/C++ function call being wrapped.
-The <tt> return $null; </tt> handles all native method return types, namely those that have a void return and those that do not. 
+The <tt>$action</tt> is a SWIG special variable and is replaced by the C/C++ function call being wrapped.
+The <tt>return $null;</tt> handles all native method return types, namely those that have a void return and those that do not.
 This is useful for typemaps that will be used in native method returning all return types. 
 See the section on
 <a href="#Java_special_variables">Java special variables</a> for further explanation.
@@ -5579,7 +5579,7 @@ This special variable is usually used for making calls to a function in the inte
 </p>
 
 <p>
-<b><tt>$null </tt></b><br>
+<b><tt>$null</tt></b><br>
 Used in input typemaps to return early from JNI functions that have either void or a non-void return type. Example:
 </p>
 

Doc/Manual/Php.html

@@ -136,14 +136,14 @@ least work for Linux though):
 </p>
 
 <div class="code"><pre>
-	gcc `php-config --includes` -fpic -c example_wrap.c
-	gcc -shared example_wrap.o -o example.so
+	gcc `php-config --includes` -fpic -c example_wrap.c example.c
+	gcc -shared example_wrap.o example.o -o example.so
 </pre></div>
 
 <H3><a name="Php_nn1_3"></a>34.1.2 Using PHP Extensions</H3>
 
 <p>
-To test the extension from a PHP script, you first need to load tell PHP to
+To test the extension from a PHP script, you first need to tell PHP to
 load it.  To do this, add a line like this to the <tt>[PHP]</tt> section of
 <tt>php.ini</tt>:
 </p>
@@ -235,9 +235,9 @@ echo "E = " . E . "\n";
 <p>
 There's one peculiarity of how constants work in PHP which it is useful
 to note (this is not specific to SWIG though) - if you try to use an undeclared
-constant, PHP will issue a warning and then expand the constant to a string
-version of the constant's name.  The warning will often be missed though as
-if you're using PHP in a webserver, it will probably end up in error.log or
+constant, PHP will emit a notice and then expand the constant to a string
+version of the constant's name.  Unfortunately it is easy to miss the notice
+if you're using PHP in a webserver, as it will probably end up in error.log or
 similar.
 </p>
 

Doc/Manual/Python.html

@@ -194,7 +194,7 @@ int fact(int n);
 </div>
 
 <p>
-The <tt> #define SWIG_FILE_WITH_INIT </tt> line inserts a macro that specifies that the
+The <tt>#define SWIG_FILE_WITH_INIT</tt> line inserts a macro that specifies that the
 resulting C file should be built as a python extension, inserting the module
 <tt>init</tt> code. This <tt>.i</tt> file wraps the following simple C file:
 </p>
@@ -395,7 +395,7 @@ of the module prefixed by an underscore</b>.  If the name of your module is "<tt
 name of the corresponding object file should be
 "<tt>_example.so</tt>" or "<tt>_examplemodule.so</tt>".
 The name of the module is specified using the <tt>%module</tt> directive or the 
-<tt> -module</tt> command line option.
+<tt>-module</tt> command line option.
 </p>
 
 <p>
@@ -783,8 +783,8 @@ Building a SWIG extension to Python under Windows is roughly similar to
 the process used with Unix. Using the distutils, it is essentially
 identical. If you have the same version of the MS compiler that Python
 was built with (the python2.4 and python2.5 distributed by python.org
-are built with Visual Studio 2003), the standard <tt> python setup.py
-build </tt> should just work.
+are built with Visual Studio 2003), the standard <tt>python setup.py
+build</tt> should just work.
 </p>
 
 <p>

Doc/Manual/Ruby.html

@@ -685,7 +685,7 @@ For example, this struct declaration: </p>
 </div>
 
 <p> gets wrapped as a <tt>Vector</tt> class, with
-Ruby instance methods <tt>x</tt>, <tt> x=</tt>,
+Ruby instance methods <tt>x</tt>, <tt>x=</tt>,
 <tt>y</tt> and <tt>y=</tt>. These methods can
 be used to access structure data from Ruby as follows: </p>
 
@@ -1313,7 +1313,7 @@ chapter.</p>
 
 <p>Some containers in the STL allow you to modify their default
 behavior by using so called functors or function objects.
-Functors are often just a very simple struct with<tt> operator()</tt>
+Functors are often just a very simple struct with <tt>operator()</tt>
 redefined or an actual C/C++ function. This allows you, for
 example, to always keep the sort order of a STL container to your
 liking.</p>
@@ -1327,7 +1327,7 @@ this includes <tt>std::set</tt>,
 <tt>std::multiset</tt>
 and <tt>std::multimap</tt>.</p>
 
-<p>The functors in swig are called<tt> swig::UnaryFunction</tt>
+<p>The functors in swig are called <tt>swig::UnaryFunction</tt>
 and <tt>swig::BinaryFunction</tt>.
 
 For C++ predicates (ie. functors that must return bool as a result) <tt>swig::UnaryPredicate</tt>
@@ -1380,8 +1380,8 @@ values they point at, while the non-const iterators can both read and
 modify the values.</p>
 
 <p>The Ruby STL wrappings support both type of iterators by using
-a proxy class in-between. This proxy class is <tt>swig::Iterator or
-swig::ConstIterator. </tt> Derived from them are template
+a proxy class in-between. This proxy class is <tt>swig::Iterator</tt> or
+<tt>swig::ConstIterator</tt>. Derived from them are template
 classes that need to be initialized with the actual iterator for the
 container you are wrapping and often times with the beginning and
 ending points of the iteration range.</p>
@@ -1450,7 +1450,7 @@ i
 </pre>
 </div>
 
-<p>If you'd rather have STL classes without any iterators, you should define<tt> -DSWIG_NO_EXPORT_ITERATOR_METHODS </tt>when running swig.</p>
+<p>If you'd rather have STL classes without any iterators, you should define <tt>-DSWIG_NO_EXPORT_ITERATOR_METHODS</tt> when running swig.</p>
 
 <H3><a name="Ruby_nn24"></a>38.3.16 C++ Smart Pointers</H3>
 
@@ -4997,7 +4997,7 @@ object from its underlying C++ object.</p>
 <p>In general, you will only need to use the <tt>SWIG_RubyInstanceFor</tt>,
 which is required for implementing mark functions as shown below.
 However, if you implement your own free functions (see below) you may
-also have to call the<tt> SWIG_RubyRemoveTracking</tt> and <tt>RubyUnlinkObjects</tt>
+also have to call the <tt>SWIG_RubyRemoveTracking</tt> and <tt>RubyUnlinkObjects</tt>
 methods.</p>
 
 <H3><a name="Ruby_nn61"></a>38.10.4 Mark Functions</H3>

Doc/Manual/SWIG.html

@@ -1046,7 +1046,7 @@ def filecopy(source,target):
 </pre></div>
 
 <p>
-In this case <tt>f1</tt>,<tt> f2</tt>, and <tt>buffer</tt> are all
+In this case <tt>f1</tt>, <tt>f2</tt>, and <tt>buffer</tt> are all
 opaque objects containing C pointers. It doesn't matter what value
 they contain--our program works just fine without this knowledge.</p>
 
@@ -1711,7 +1711,7 @@ wrapping a header file like this:
 </pre></div>
 
 <p>
-<tt>%rename </tt>applies a renaming operation to all future
+<tt>%rename</tt> applies a renaming operation to all future
 occurrences of a name. The renaming applies to functions, variables,
 class and structure names, member functions, and member data. For
 example, if you had two-dozen C++ classes, all with a member function

Doc/Manual/SWIGPlus.html

@@ -1205,7 +1205,7 @@ SWIG is unable to support kwargs when wrapping overloaded methods, so the defaul
 <p>
  SWIG wraps class members that are public following the C++
  conventions, i.e., by explicit public declaration or by the use of
- the <tt> using</tt> directive. In general, anything specified in a
+ the <tt>using</tt> directive. In general, anything specified in a
  private or protected section will be ignored, although the internal
  code generator sometimes looks at the contents of the private and
  protected sections so that it can properly generate code for default
@@ -2800,7 +2800,7 @@ public:
 </pre></div>
 
 <p>
-This code adds a<tt> __str__</tt> method to our class for producing a
+This code adds a <tt>__str__</tt> method to our class for producing a
 string representation of the object. In Python, such a method would
 allow us to print the value of an object using the <tt>print</tt>
 command.
@@ -2854,7 +2854,7 @@ The <a href="Customization.html#Customization_exception_special_variables">Speci
 </p>
 
 <p>
-The<tt> %extend</tt> directive follows all of the same conventions
+The <tt>%extend</tt> directive follows all of the same conventions
 as its use with C structures. Please refer to the <a href="SWIG.html#SWIG_adding_member_functions">Adding member functions to C structures</a>
 section for further details.
 </p>

Doc/Manual/Tcl.html

@@ -160,7 +160,7 @@ of the module.  If the name of your SWIG module is "<tt>example</tt>", the
 name of the corresponding object file should be
 "<tt>example.so</tt>".
 The name of the module is specified using the <tt>%module</tt> directive or the 
-<tt> -module</tt> command line option.
+ <tt>-module</tt> command line option.
 </p>
 
 <H3><a name="Tcl_nn5"></a>39.1.3 Static linking</H3>
@@ -504,7 +504,7 @@ name, but you can override it using the <tt>-prefix</tt> option.
 </p>
 
 <p>
-When the<tt> -namespace</tt> option is used, objects in the module
+When the <tt>-namespace</tt> option is used, objects in the module
 are always accessed with the namespace name such as <tt>Foo::bar</tt>.
 </p>
 

Doc/Manual/Typemaps.html

@@ -2050,6 +2050,22 @@ wrap_foo() {
 </pre>
 </div>
 
+<p>There is an exception: if the variable name starts with the <tt>_global_</tt> prefix,
+the argument number is not appended. Such variables can be used throughout the generated
+wrapper function. For example, the above typemap could be rewritten to use <tt>_global_temp</tt>
+instead of <tt>temp</tt> and the generated code would then contain a single <tt>_global_temp</tt> variable
+instead of <tt>temp1</tt>, <tt>temp2</tt> and <tt>temp3</tt>:
+</p>
+
+<div class="code">
+<pre>
+%typemap(in) std::string * <b>(std::string _global_temp)</b> {
+ ... as above ...
+}
+</pre>
+</div>
+
+
 <p>
 Some typemaps do not recognize local variables (or they may simply not
 apply). At this time, only typemaps that apply to argument conversion support this (input typemaps such as the "in" typemap).
@@ -3360,7 +3376,7 @@ list of strings like this:
 </div>
 
 <p>
-To do this, you not only need to map a list of strings to <tt> char *argv[]</tt>, but the
+To do this, you not only need to map a list of strings to <tt>char *argv[]</tt>, but the
 value of <tt>int argc</tt> is implicitly determined by the length of the list.   Using only simple
 typemaps, this type of conversion is possible, but extremely painful.
 Multi-argument typemaps help in this situation.