In future releases of Go it will not be possible to pass Go pointers
into C/C++ code. The handle is automatically translated back to the
Go value using a Go map. Since directors must be explicitly deleted,
we can reliably use that call to remove the handle from the map.
* stricter-warnings:
Go changes for wrappers to compile as ISO C90
Scilab typecheck typemaps fix for C90
No error for one Javascript node warning
Warning fix in testcase for Javascript node
nested_extend_c testcase fix when compiled by C++ target languages
Temporarily remove -Werror for Scilab testing
C90 fixes for Javascript JSC
There are a couple of testcases that aren't compliant and supression via pragmas doesn't work for gcc < 4.8
Warning suppression change
Scilab typemap fixes for C89
compiler warning suppression correction in testcase
Suppress pedantic warnings in C# testcases
Suppress pedantic warnings in testcases
Pedantic warning fix in testcase
pedantic warning fix for D wrappers
Travis testing to use testflags.py for setting CFLAGS and CXXFLAGS
Add travis build for error-declaration-after-statement branch
longer as of Go 1.5. In Go 1.5 or later user calls to
_swig_makegostring will fail at link time.
Instead, use goout and godirectorin typemaps to allocate strings in Go
code.
Change the Go typemaps support to ignore empty strings, so that we can
define empty strings for regular types so that %apply will override
the definitions for string types.
Fix the gccgo code to wrap SwigCgoCallback around all godirectorin
typemaps.
Add a few newlines after typemap code so that the typemaps don't have
to include them.
for the one from _swig_makegostring. _swig_goallocate can not work
with the future Go 1.5 release. When using Go 1.5 attempts to call
_swig_goallocate will fail at link time.
Default values are no longer generated as Python code by default.
They must be explicitly turned on using the "python:defaultargs" feature.
Closes#294Closes#296
The problems in these two issues when "python:defaultargs" is turned
on still need to be fixed and should be addressed in separate patches.
The important thing is the default code generation is now fixed.
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.
There might be other cases where this happens when $dclassname
is used for code emitted into the proxy class itself, but so
far, there are none in the test suite or any bug reports.
Fixes unknown preprocessor directive error introduced in #217
commit 255c929c56
These were probably intended as script comments using # when C/C++
comments using // or /* */ should have been used.