Prevent double import of _lldb module

[vadimcn]

Summary

This fixes llvm.org/pr39054

The fix itself is pretty simple:

1. Register _lldb as a built-in module during initialization of script interpreter.
2. Reverse the order of imports in __init__.py: first try to import by absolute name, which will find the built-in module in the context of lldb (and other hosts that embed liblldb), then try relative import, in case the module is being imported from Python interpreter.

[vadimcn]

Changing title as it looks like this is not a Windows-only problem: https://github.com/rust-lang/rust/issues/54126.

The above illustrates why I think this needs to be fixed: Right now LLDB cannot be installed correctly unless the installer can preserve symlinks. Merely making a copy of LLDB files will break it, unless one is extra careful to use symlink-preserving copy, and I am not even sure what tool could be used on Windows to copy it correctly.

[labath]

Sorry for the delay. I *think* this should be fine, but with these things its hard to tell whether it won't break someone's build/release setup. However, it does solve a real problem (I've hit this issue myself a couple of times on windows), so I think we should give it a try.

It might be good to note that this will only ever make a difference if one is using swig>=3.0.11.

[vadimcn]

Thanks,
What changed in SWIG 3.0.11?

[labath]

In D52404#1257347, @vadimcn wrote:

Thanks,
What changed in SWIG 3.0.11?

That's the version which added support for the moduleimport attribute. Before that, the modules were imported using a fixed algorithm (I am not sure whether that algorithm was compatible or not with what you're doing here.)

lldb/trunk/scripts/lldb.swig

 a way that is incompatible with our usage of the python module as __init__.py
 (See swig bug #769).  Fortunately, since version 3.0.11, swig provides a way for
 us to override the module import logic to suit our needs. This does that.
 
 Older swig versions will simply ignore this setting.
 */
 %define MODULEIMPORT
 "try:
-    # Try a relative import first
-    from . import $module
+    # Try an absolute import first.  If we're being loaded from lldb,
+    # _lldb should be a built-in module.
+    import $module
 except ImportError:
-    # Maybe absolute import will work (if we're being loaded from lldb, it
-    # should).
-    import $module"
+    # Relative import should work if we are being loaded by Python.
+    from . import $module"
 %enddef
 // These versions will not generate working python modules, so error out early.
 #if SWIG_VERSION >= 0x030009 && SWIG_VERSION < 0x030011
 #error Swig versions 3.0.9 and 3.0.10 are incompatible with lldb.
 #endif
 
 // The name of the module to be created.
 %module(docstring=DOCSTRING, moduleimport=MODULEIMPORT) lldb

lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp

public:
   InitializePythonRAII()
       : m_gil_state(PyGILState_UNLOCKED), m_was_already_initialized(false) {
     // Python will muck with STDIN terminal state, so save off any current TTY
     // settings so we can restore them.
     m_stdin_tty_state.Save(STDIN_FILENO, false);
 
     InitializePythonHome();
 
+    // Register _lldb as a built-in module.
+    PyImport_AppendInittab("_lldb", g_swig_init_callback);
+
 // Python < 3.2 and Python >= 3.2 reversed the ordering requirements for
 // calling `Py_Initialize` and `PyEval_InitThreads`.  < 3.2 requires that you
 // call `PyEval_InitThreads` first, and >= 3.2 requires that you call it last.
 #if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 2) || (PY_MAJOR_VERSION > 3)
     Py_InitializeEx(0);
     InitializeThreadsPrivate();
 #else
     InitializeThreadsPrivate();