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
* alexey-pelykh-cpp11_strongly_typed_enums__direct_inject_in_java:
Enhance cpp11_strongly_typed_enumerations testcase and turn it on
Simplify/improve strongly typed enum implementation for Java
Rewrite some Java director nested class support code for strongly typed enums
Expand director_nested_class test to test more than one level of nesting
Add director_nested_class testcase
Removed useless code (it does not affect output, at least on our testcases)
Java/Fix: swig_connect_director used not-fully-qualified classname (proper)
Java/Fix: swig_connect_director used not-fully-qualified classname
Java: fix generation of ProxyName when JNI descriptor is requested - for inner classes '$' should be used as separator instead of '/'
Java: fix invalid director 'self' variable type name (wasn't fully qualified)
Clean-up test suite and fix issue with nspace, as well as keep the fix for Class::Struct::EnumClass being JNI-referenced as Struct_EnumClass
C++11 strongly-typed enums fix for Java only (proper)
Revert "C++11 strongly-typed enums fix for Java only"
Additional test cases for C++11 strongly-typed enums
C++11 strongly-typed enums fix for Java only
Turns out the issue that led me to push a broken commit in
the first place also caused the build to succeed when I
tested the fix in a rush. I should've just used the GitHub
merge button. Sorry for the noise, hopefully won't happen again.
The original code was ported from the C# module. It looks like it
tried to avoid reading TLS data by using a shared counter. However,
without also synchronizing on the counter check (or using atomics)
the code is racy. While the races might be benign (the thread that
sets the exception also increments the counter, so when there is
actually an exception, the visible value will always be non-zero
even if it is outdated), they are still undefined behavior,
strictly speaking. Additionally, just using TLS isn't expensive
either.
