Previously, these were unseen because the wrapper script would swallow
them. This fixes the following types of warnings:
- methods being declared more than once
- swig complained about ignoring operator=, so I just removed it
llvm-svn: 373069
Summary:
This patch converts FileSystem::Open from this prototype:
Status
Open(File &File, const FileSpec &file_spec, ...);
to this one:
llvm::Expected<std::unique_ptr<File>>
Open(const FileSpec &file_spec, ...);
This is beneficial on its own, as llvm::Expected is a more modern
and recommended error type than Status. It is also a necessary step
towards https://reviews.llvm.org/D67891, and further developments
for lldb_private::File.
Reviewers: JDevlieghere, jasonmolenda, labath
Reviewed By: labath
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67996
llvm-svn: 373003
Fix installing Python modules on systems that use /usr/lib for Python
while installing other libraries in /usr/lib64. Rewrite CMake logic
to query correct directories from Python, similarly to how
prepare_binding_Python.py does it. Furthermore, change the regex used
in get_relative_lib_dir.py to allow 'lib' without suffix.
I think that the code can be further improved but I'd like to take
this enterprise in smaller steps in case one of them breaks something.
Differential Revision: https://reviews.llvm.org/D67890
llvm-svn: 372835
When swig fails, all the errors are squished onto one line with \n
quoting. It's very hard to read. This will print them out in a more
reasonable format.
Patch by: Lawrence D'Anna
Differential revision: https://reviews.llvm.org/D67790
llvm-svn: 372442
The test was expecting the value of "lldb.frame" to be None, because it
is cleared after each python interpreter session. However, this is not
true in the very first session, because lldb.py sets these values to
invalid objects (lldb.SBFrame(), etc.).
I have not investigated why is it that this test passes on darwin, but
my guess is that this is because we do extra work on darwin (loading the
objc runtime, etc), which causes us to enter the python interpreter
sooner.
This patch changes lldb.py to also initialize these values to None, as
that seems to make more sense. I also fixed some typos in the test while
I was in there.
llvm-svn: 372222
Summary:
The path defined in CMakeLists.txt doesn't match the path generated in
our python script. This change fixes that.
LLVM_LIBRARY_OUTPUT_INTDIR is defined as:
${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/lib${LLVM_LIBDIR_SUFFIX})
On the other hand, the path of site-package is generaged in
get_framework_python_dir_windows() in finishSwigPythonLLDB.py as:
(Dispite its name, the function is used for everything other than xcode)
prefix/cmakeBuildConfiguration/distutils.sysconfig.get_python_lib()
From lldb/CMakeLists.txt, we can see that:
prefix=${CMAKE_BINARY_DIR},
cmakeBuildConfiguration=${CMAKE_CFG_INTDIR}
And from python source code, we can see get_python_lib() always returns
lib/pythonx.y/site-packages for posix, or Lib/site-packages for windows:
https://github.com/python/cpython/blob/3.8/Lib/distutils/sysconfig.py#L128
We should make them match each other.
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67583
llvm-svn: 372047
Python 3 iteration calls the next() method instead of next() and
value_iter only implemented the Python 2 version.
Differential revision: https://reviews.llvm.org/D67184
llvm-svn: 370954
Python 3 calls __bool__() instead of __len__() and lldb.value only
implemented the __len__ method. This adds the __bool__() implementation.
Differential revision: https://reviews.llvm.org/D67183
llvm-svn: 370953
Summary: Since D65109 removed the manually maintained Xcode project, there's a few things we don't need anymore. Anything here we should keep or anything more to remove?
Reviewers: JDevlieghere, jasonmolenda, clayborg, jingham, lanza, teemperor
Subscribers: mgorny, lldb-commits, #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D65155
llvm-svn: 366879
Finally, after a lot of hard work from a bunch of people, we're in a
state where we can unify LLDB's build system.
This patch removes the hand-maintained Xcode project in favor of using
CMake in combination with the Xcode generator. Going forward, we want to
focus our efforts on improving the generated Xcode project.
Differential revision: https://reviews.llvm.org/D65109
llvm-svn: 366739
r366471 added "-features autodoc" without a trailing comment, leading to `Unrecognized option -features autodoc-threads` due to implicit string concatenation. Add a comma to fix that.
Also separate into "-features" and "autodoc", otherwise it gets parsed as a single "-features autodoc" flag which is also not recognized (it must be two separate CLI args).
llvm-svn: 366478
The last swig 1.x release dates from 2009, now 10 years ago. Recently, I
fixed an issue that prevented us from using swig 4 (r364974), which
turned out to be not backward compatible with swig 1.x (r365718).
This patch deprecates this (really old) version of swig and makes swig 2
the minimum supported version in LLDB . This should be fine for the
build bots, which are all running swig 3 or later.
Differential revision: https://reviews.llvm.org/D64782
llvm-svn: 366213
Apparently, when using swig 1.3.40, properties to set values do not work
without the `__swig_setmethods__` workaround. I conditionally added this
back for SBTypeCategory, as it's causing a test failure on GreenDragon,
while I investigate this further.
llvm-svn: 365718
There are pre-made utilities doing this. If somebody finds an
use for it and wants to resurrect, I would recommend to revise
the error messages.
llvm-svn: 365677
As of SWIG 4.0, __swig_getmethods__ and __swig_setmethods__ are no
longer defined. It appears that there's no need to mess with these
internals, we can simplify define the corresponding properties inline.
Originally I wanted to use the swig extension %attribute and
%attributeref to define properties. However, I couldn't find a way to
add documentation to these attributes. Since we already had the
properties defined inline, we might as well keep them.
Differential revision: https://reviews.llvm.org/D63530
llvm-svn: 364974
As of SWIG 4.0, __swig_getmethods__ and __swig_setmethods__ are no
longer defined. The solution is to stop using these internal swig
dictionaries and use %attribute and %attributeref instead. I plan on
doing this incrementally, with this differential serving as an example.
Differential revision: https://reviews.llvm.org/D63530
llvm-svn: 364946
Summary:
After the last round of cleanups, this script was almost a no-op. The
only piece of functionality that remained was the one which tried to
make the swig-generated function signatures more pythonic.
The "tried" part is important here, as it wasn't doing a really good job
and the end result was not valid python nor c (e.g.,
SetExecutable(SBAttachInfo self, str const * path)).
Doing these transformations another way is not possible, as these
signatures are generated by swig, and not present in source. However,
given that this is the only reason why we need a swig post-process step,
and that the current implementation is pretty sub-optimal, this patch
simply abandons the signature fixup idea, and chooses to simplify our
build process instead.
Reviewers: amccarth, jingham, clayborg
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D61000
llvm-svn: 359092
The strings have been already cleaned up in r358683, so this code is not
doing anything anymore.
While comparing the outputs before and after removing the formatting
code, I've found a couple of docstrings that managed to escape my perl
script in r358683, so I format them manually with this patch.
llvm-svn: 358846
Summary:
This patch removes the "//----" frames and "///" leading lines from
docstring comments. We already have code doing transformations like this in
modify-python-lldb.py, but that's a script I'd like to remove. Instead
of running these transformations everytime we run swig, we can just
perform equivalent on its input once.
This patch can be reproduced (e.g. for downstream merges) with the
following "sweet" perl command:
perl -i -p -e 'BEGIN{ $/ = undef;} s:(" *\n) *//-----*\n:\1:gs; s:^( *)/// ?:\1:gsm; s:^ *//------*\n( *\n)?( *"):\2:gsm; s: *$::gsm; s:\n *"\):"):gsm' scripts/interface/*.i
This command produces nearly equivalent python files to those produced
by the relevant code in modify-python-lldb.py. The only difference I
noticed is that here I am slightly more agressive in removing trailing
newlines from docstring comments (the python script seems to leave
newlines in class-level docstrings).
Reviewers: amccarth, clayborg, jingham, aprantl
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D60498
llvm-svn: 358683
Summary:
Some of these were present in files which should never be read by swig
(and we also had one in the interface file, which is only read by swig).
They are probably leftovers from the time when we were running swig over
lldb headers directly.
While writing this patch, I noticed that some of the #ifdefs were
guarding public functions that were operating on lldb_private data
types. While it wasn't strictly necessary for this patch, I made these
private, as nobody should really be accessing them. This can potentially
break existing code if it happened to use these methods, though it will
only break at build time -- if someone builds against an old header, he
should still be able to link to a new lldb library, since the functions
are still there.
We could keep these public for backward compatbility, but I would argue
that if anyone was actually using these functions for anything, his code
is already broken.
Reviewers: JDevlieghere, clayborg, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D60400
llvm-svn: 357984
There are no patterns like that in the generated swig files (there
probably were some back in the days when we were running swig over the
header files directly), so this is dead code and has no effect on the
generated file.
llvm-svn: 357890
This is the last functional change to the generated python module being
done by modify-python-lldb.py. The remaining code just deals with
reformatting of comments.
llvm-svn: 357755
Summary:
This patch moves the modify-python-lldb code for adding new functions to
the SBModule class into the SBModule interface file. As this is the last
class using this functionality, I also remove all support for this kind
of modifications from modify-python-lldb.py.
Reviewers: amccarth, clayborg, jingham
Subscribers: zturner, lldb-commits
Differential Revision: https://reviews.llvm.org/D60195
llvm-svn: 357680
Summary:
Instead of modifying the swig-generated code, just add the appropriate
methods to the interface files in order to get the swig to do the
generation for us.
This is a straight-forward move from the python script to the interface
files. The single class which has nontrivial handling in the script
(SBModule) has been left for a separate patch.
For the cases where I did not find any tests exercising the
iteration/length methods (i.e., no tests failed after I stopped emitting
them), I tried to add basic tests for that functionality.
Reviewers: zturner, jingham, amccarth
Subscribers: jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D60119
llvm-svn: 357572
Summary:
modify-python-lldb.py had code to insert python equality operators to
some classes. Some of those classes already had c++ equality operators,
and some didn't.
This makes the situation more consistent, by removing all equality
handilng from modify-python-lldb. Instead, I add c++ operators to
classes where they were missing, and expose them in the swig interface
files so that they are available to python too.
The only tricky case was the SBAddress class, which had an operator==
defined as a free function, which is not handled by swig. This function
cannot be removed without breaking ABI, and we cannot add an extra
operator== member, as that would make equality comparisons ambiguous.
For this class, I define a python __eq__ function by hand and have it
delegate to the operator!=, which I have defined as a member function.
This isn't fully NFC, as the semantics of some equality functions in
python changes slightly, but I believe it changes for the better (e.g.,
previously SBBreakpoint.__eq__ would consider two breakpoints with the
same ID as equal, even if they belonged to different targets; now they
are only equal if they belong to the same target).
Reviewers: jingham, clayborg, zturner
Subscribers: jdoerfert, JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D59819
llvm-svn: 357463
FindPythonInterp and FindPythonLibs do two things, they set some
variables (PYTHON_LIBRARIES, PYTHON_INCLUDE_DIRS) and update the cached
variables (PYTHON_LIBRARY, PYTHON_INCLUDE_DIR) which are also used to
specify a custom python installation.
I believe the canonical way to do this is to use the PYTHON_LIBRARIES
and PYTHON_INCLUDE_DIRS variables instead of the cached ones. However,
since the cached variables are accessible from the cache and GUI, this
is a lot less confusing when you're trying to debug why a variable did
or didn't get the value you expected. Furthermore, as far as I can tell,
the implementation uses the cached variables to set their LIBRARIES/DIRS
counterparts. This is also the reason this works today even though we
mix-and-match.
Differential revision: https://reviews.llvm.org/D59968
llvm-svn: 357282
Todd added this empty readline module to workaround an issue with an old
version of Python on Ubuntu in 2014 (18841). In the meantime, libedit
seems to have fixed the underlying issue, and indeed, I wasn't able to
reproduce this.
Differential revision: https://reviews.llvm.org/D59972
llvm-svn: 357277
It was making a list of a certain size but not always filling in that
many elements, which would lead to a crash iterating over the list.
Differential Revision: https://reviews.llvm.org/D59913
llvm-svn: 357207
When the output of map is not used, using a list comprehension or an explicit
call to list looks awkward.
Differential Revision: https://reviews.llvm.org/D59587
llvm-svn: 356672
Summary:
In my next step at cleaning up modify-python-lldb.py, I started focusing
on equality comparison. To my surprise, I found out that both python and
c++ versions of the SBType class implement equality comparison, but each
one does it differently. While the python version was implemented in
terms of type name equality, the C++ one used a deep comparison on the
underlying objects.
Removing the python version caused one test to fail (TestTypeList). This
happened because the c++ version of operator== boiled down to
TypePair::operator==, which contains two items: the compiler_type and
type_sp. In this case, the compiler_type was identical, but one of the
objects had the type_sp field unset.
I tried fixing the code so that both objects keep their type_sp member,
but it wasn't easy, because there are so many operations which just work
with the CompilerType types, and so any operation on the SBType (the
test in question was doing GetPointeeType on the type of one variable
and expecting it to match the type of another variable), cause that
second member to be lost.
So instead, here I relax the equality comparison on the TypePair
class. Now, this class ignores the type_sp for the purposes of
comparison, and uses the CompilerType only. This seems reasonable, as
each TypeSP is able to convert itself to a CompilerType.
Reviewers: clayborg, aprantl, serge-sans-paille
Subscribers: jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D59217
llvm-svn: 356048
Summary:
Our python version of the SB API has (the python equivalent of)
operator bool, but the C++ version doesn't.
This is because our python operators are added by modify-python-lldb.py,
which performs postprocessing on the swig-generated interface files.
In this patch, I add the "operator bool" to all SB classes which have an
IsValid method (which is the same logic used by modify-python-lldb.py).
This way, we make the two interfaces more constent, and it allows us to
rely on swig's automatic syntesis of python __nonzero__ methods instead
of doing manual fixups.
Reviewers: zturner, jingham, clayborg, jfb, serge-sans-paille
Subscribers: jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D58792
llvm-svn: 355824
Summary:
The current install-clang-headers target installs clang's resource
directory headers. This is different from the install-llvm-headers
target, which installs LLVM's API headers. We want to introduce the
corresponding target to clang, and the natural name for that new target
would be install-clang-headers. Rename the existing target to
install-clang-resource-headers to free up the install-clang-headers name
for the new target, following the discussion on cfe-dev [1].
I didn't find any bots on zorg referencing install-clang-headers. I'll
send out another PSA to cfe-dev to accompany this rename.
[1] http://lists.llvm.org/pipermail/cfe-dev/2019-February/061365.html
Reviewers: beanz, phosek, tstellar, rnk, dim, serge-sans-paille
Subscribers: mgorny, javed.absar, jdoerfert, #sanitizers, openmp-commits, lldb-commits, cfe-commits, llvm-commits
Tags: #clang, #sanitizers, #lldb, #openmp, #llvm
Differential Revision: https://reviews.llvm.org/D58791
llvm-svn: 355340
Summary:
Swig is perfectly capable of inserting blocks of python code into its
output (and we use those fascilities already), so there's no need for
this to be done in a post-process step.
lldb_iter is a general-purpose utility used from many classes, so I add
it to the main swig file. The other two blocks are tied to a specific
class, so I add it to the interface file of that class.
Reviewers: zturner, jingham, serge-sans-paille
Subscribers: jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D58350
llvm-svn: 354975
As per the discussion on the mailing list:
http://lists.llvm.org/pipermail/lldb-commits/Week-of-Mon-20190218/048007.html
This commit implements option (3):
> Go back to initializing the reproducer before the rest of the debugger.
> The method wouldn't be instrumented and guarantee no other SB methods are
> called or SB objects are constructed. The initialization then becomes part
> of the replay.
Differential revision: https://reviews.llvm.org/D58410
llvm-svn: 354631
Jim Ingham