Fix TestTargetAPI.py test for users who use Swig 3.0.5 or greater.

[amccarth]

Summary

How Swig handles varargs functions changed between 3.0.2 and 3.0.5, which causes one of our tests to fail. This fix adds a Swig directive to the SBError::SetErrorSTringWithFormat method and extends a test to call it with various numbers of arguments.

I've tested this fix with Swig 3.0.2, 3.0.5, and 3.0.7.

In Python, there are only two calls to this method, both in the sb_error.py test, and one of those is the failing line. It's unclear how many external scripts may be affected.

The caveat here is that, when calling from Python, all of the arguments must be strings. From the Swig documentation, "Doing anything more advanced than this is likely to involve a serious world of pain. In order to use a library like libffi, you will need to know the underlying calling conventions and details of the C++ ABI."

Background:

The message SBError::SetErrorStringWithFormat is a varargs function. In the Swig interface file, it's:

int
SetErrorStringWithFormat (const char *format, ...);

With 3.0.2, this creates a Python wrapper with this signature:

def SetErrorStringWithFormat(self, *args):
    """SetErrorStringWithFormat(SBError self, str const * format) -> int"""
    return _lldb.SBError_SetErrorStringWithFormat(self, *args)

But in 3.0.5 (and later), it comes up with:

def SetErrorStringWithFormat(self, format):
    """SetErrorStringWithFormat(SBError self, str const * format) -> int"""
    return _lldb.SBError_SetErrorStringWithFormat(self, format)

Note that it no longer takes a variable number of arguments. This causes a test failure when the Python code attempts to invoke the method with more than a format string.

======================================================================
ERROR: test_SBError (TestDefaultConstructorForAPIObjects.APIDefaultConstructorTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\src\llvm\llvm\tools\lldb\test\lldbtest.py", line 480, in wrapper
    return func(self, *args, **kwargs)
  File "D:\src\llvm\llvm\tools\lldb\test\lldbtest.py", line 521, in wrapper
    return func(self, *args, **kwargs)
  File "D:\src\llvm\llvm\tools\lldb\test\python_api\default-constructor\TestDefaultConstructorForAPIObjects.py", line 131, in test_SBError
    sb_error.fuzz_obj(obj)
  File "D:\src\llvm\llvm\tools\lldb\test\python_api\default-constructor\sb_error.py", line 19, in fuzz_obj
    obj.SetErrorStringWithFormat("%s!", "error")
TypeError: SetErrorStringWithFormat() takes exactly 2 arguments (3 given)
Config=i686-D:\src\llvm\build\ninja\bin\clang.exe
----------------------------------------------------------------------

This is consistent with the Swig documentation on varargs functions. See: http://www.swig.org/Doc3.0/Varargs.html#Varargs

[zturner]

Prior to this patch, what was the behavior of using SetErrorStringWithFormat with an argument that was not a string?

Can you add a test to fuzz_obj that calls SetErrorStringWithFormat("%d", 10) and run it against SWIG 3.0.2 and see what happens?

[amccarth]

With Swig 3.0.2, non-string arguments work. I'm not sure why. Even the
Swig 1.x documentation says that what we're doing shouldn't work.

[amccarth]

Adding Greg Clayton for advice on how to proceed.

Swig documentation talked about the peril of varargs methods: http://www.swig.org/Doc3.0/Varargs.html#Varargs

The fact that it appears to work with 3.0.2 seems to be a bug in 3.0.2.

My proposal is in this patch. An alternate idea would be to remove SetErrorStringWithFormat from the SB API, but I know we don't like to remove things from the API.

[Eugene.Zelenko]

Committed in r250188.

scripts/interface/SBError.i

And (from test/python_api/event/TestEvent.py),
         # Now launch the process, and do not stop at entry point.
         error = lldb.SBError()
         process = target.Launch(listener, None, None, None, None, None, None, 0, False, error)
         self.assertTrue(error.Success() and process, PROCESS_IS_VALID)
 
 checks that after calling the target.Launch() method there's no error
 condition and we get back a void process object.
 ") SBError;
+
 class SBError {
 public:
     SBError ();
 
     SBError (const lldb::SBError &rhs);
 
     ~SBError();
 
public:
     SetErrorToErrno ();
 
     void
     SetErrorToGenericError ();
 
     void
     SetErrorString (const char *err_str);
 
+    %varargs(3, char *str = NULL) SetErrorStringWithFormat;
     int
     SetErrorStringWithFormat (const char *format, ...);
 
     bool
     IsValid () const;
 
     bool
     GetDescription (lldb::SBStream &description);

test/python_api/default-constructor/sb_error.py

def fuzz_obj(obj):
     obj.GetType()
     obj.SetError(5, lldb.eErrorTypeGeneric)
     obj.SetErrorToErrno()
     obj.SetErrorToGenericError()
     obj.SetErrorString("xyz")
     obj.SetErrorString(None)
     obj.SetErrorStringWithFormat("%s!", "error")
     obj.SetErrorStringWithFormat(None)
+    obj.SetErrorStringWithFormat("error")
+    obj.SetErrorStringWithFormat("%s %s", "warning", "danger")
+    obj.SetErrorStringWithFormat("%s %s %s", "danger", "will", "robinson")
     obj.GetDescription(lldb.SBStream())
     obj.Clear()