zturner updated this revision to Diff 51705.
zturner added a comment.
Rebased against ToT
http://reviews.llvm.org/D18381
Files:
include/lldb/Symbol/ClangASTContext.h
include/lldb/Symbol/ClangASTImporter.h
include/lldb/Symbol/ClangUtil.h
include/lldb/Symbol/TypeSystem.h
source/Plugins/
Author: spyffe
Date: Fri Mar 25 19:37:55 2016
New Revision: 264485
URL: http://llvm.org/viewvc/llvm-project?rev=264485&view=rev
Log:
When we import the definition for a Tagdecl, propagate its completeness too.
The ASTImporter completes the full definiton for a TagDecl in several places,
including
Author: spyffe
Date: Fri Mar 25 19:30:40 2016
New Revision: 264483
URL: http://llvm.org/viewvc/llvm-project?rev=264483&view=rev
Log:
Record all translation units with more than one function in them (e.g., blocks).
Blocks and lambdas have their implementation functions stored in the IR for an
expr
Did you get a chance to test this today?
On Fri, Mar 25, 2016 at 9:32 AM Greg Clayton wrote:
> Will do.
> > On Mar 24, 2016, at 3:30 PM, Zachary Turner wrote:
> >
> > Is there any way you could try it out for me? It still doesn't build
> successfully from the IDE with those steps.
> >
> > The
> On Mar 25, 2016, at 4:54 PM, Zachary Turner wrote:
>
> Ahh, I didn't notice that our C++ Language Runtime is already called the
> Itanium ABI Runtime. Kind of unfortunate.
Not necessarily. The demangling is - indeed - ABI independent (or, rather,
Mangled.cpp can demangle both MSVC and Itan
Author: spyffe
Date: Fri Mar 25 18:51:25 2016
New Revision: 264478
URL: http://llvm.org/viewvc/llvm-project?rev=264478&view=rev
Log:
Removed LoggingDiagnosticConsumer, an unused class.
Modified:
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
Modified:
lldb/trunk/
Ahh, I didn't notice that our C++ Language Runtime is already called the
Itanium ABI Runtime. Kind of unfortunate.
I wonder how it would work if a process had modules loaded with different
languages. Right now we seem to assume 1 language runtime per process, but
really it's more like 1 per modu
Author: lhames
Date: Fri Mar 25 14:27:24 2016
New Revision: 264449
URL: http://llvm.org/viewvc/llvm-project?rev=264449&view=rev
Log:
Fix now-ambiguous references to Error.
Modified:
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
Modified:
lldb/trunk/source/Plugin
> On Mar 25, 2016, at 4:39 PM, Zachary Turner wrote:
>
> Any particular reason this has the word Itanium baked into the name of the
> class
The name of the C++ language runtime is ItaniumABI
I don’t think we have a language runtime for the C++ MSVC ABI
We can revisit where this command lives a
fjricci abandoned this revision.
fjricci added a comment.
Committed.
http://reviews.llvm.org/D16488
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
fjricci abandoned this revision.
fjricci added a comment.
Committed.
http://reviews.llvm.org/D18459
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
sas added a comment.
Committed as r264476.
http://reviews.llvm.org/D18459
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: sas
Date: Fri Mar 25 18:40:32 2016
New Revision: 264476
URL: http://llvm.org/viewvc/llvm-project?rev=264476&view=rev
Log:
Fix FILE * leak in Python API
Summary:
This fixes a leak introduced by some of these changes:
r257644
r250530
r250525
The changes made in these patches result in leak
Any particular reason this has the word Itanium baked into the name of the
class and description? MSVC doesn't use the Itanium ABI, but but AFAICT
from looking at this code, it should work for MSVC's abi as well.
Sicne this command isn't actually Itanium ABI specific, I don't think it
should make
clayborg accepted this revision.
clayborg added a comment.
Looks good. Thanks for taking the time to get this working right.
http://reviews.llvm.org/D18459
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailm
fjricci updated this revision to Diff 51699.
fjricci added a comment.
Fix whitespace
http://reviews.llvm.org/D18459
Files:
include/lldb/API/SBCommandReturnObject.h
scripts/interface/SBCommandReturnObject.i
source/API/SBCommandReturnObject.cpp
Index: source/API/SBCommandReturnObject.cpp
=
fjricci updated this revision to Diff 51698.
fjricci added a comment.
Use function overloading
http://reviews.llvm.org/D18459
Files:
include/lldb/API/SBCommandReturnObject.h
scripts/interface/SBCommandReturnObject.i
source/API/SBCommandReturnObject.cpp
Index: source/API/SBCommandReturnOb
Author: enrico
Date: Fri Mar 25 18:14:24 2016
New Revision: 264474
URL: http://llvm.org/viewvc/llvm-project?rev=264474&view=rev
Log:
Add a 'language cplusplus demangle' command. This can be useful to provide a
low-friction reproduction for issues with the LLDB demangling of C++ symbols
Modified:
ted created this revision.
ted added a reviewer: zturner.
ted added a subscriber: lldb-commits.
On Windows we require both debug and release python executable/libraries; this
change requires debug for a debug build and release for other builds.
If CMAKE_BUILD_TYPE is not specified, the llvm CMak
Author: enrico
Date: Fri Mar 25 16:59:06 2016
New Revision: 264468
URL: http://llvm.org/viewvc/llvm-project?rev=264468&view=rev
Log:
Fix an issue with nested aliases where the help system wouldn't correctly track
the fact that an alias is an alias to a dash-dash alias
(and I hope I typed the word
chying added a comment.
In http://reviews.llvm.org/D18481#383718, @zturner wrote:
> Couldn't we have a way to say in the Makefile "never use these flags", then
> the test suite could check the environment and remove them if they are
> present. This woudl allow the test to run.
>
> architecture
clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.
I would prefer to do this with overloading if possible. See inlined comments.
Comment at: include/lldb/API/SBCommandReturnObject.h:87-91
@@ -86,7 +86,7 @@
zturner added a comment.
I'll still wait and see what Pavel and/or Tamas say, but if we are going to go
this route, I would rather the argument be called `cflags` and now `env_flags`.
Xfailing a test based on an arbitrary environment variable just seems like
something we shouldn't be doing. I
zturner added a comment.
Couldn't we have a way to say in the Makefile "never use these flags", then the
test suite could check the environment and remove them if they are present.
This woudl allow the test to run.
architecture, compiler, etc are things we don't really have control over. If a
chaoren added a comment.
In http://reviews.llvm.org/D18481#383694, @zturner wrote:
> This seems very strange to me. What if someone specifies those flags on the
> command line in the makefile instead of via some environment variables?
I don't think there's anything we can do about that unless
zturner added reviewers: labath, tberghammer.
zturner added a comment.
This seems very strange to me. What if someone specifies those flags on the
command line in the makefile instead of via some environment variables?
It also seems like a very specialized argument that we might use once or twi
fjricci updated this revision to Diff 51680.
fjricci added a comment.
Correct whitespace change
http://reviews.llvm.org/D18459
Files:
include/lldb/API/SBCommandReturnObject.h
scripts/interface/SBCommandReturnObject.i
source/API/SBCommandReturnObject.cpp
Index: source/API/SBCommandReturnO
chying created this revision.
chying added reviewers: chaoren, zturner.
chying added a subscriber: lldb-commits.
Herald added subscribers: danalbert, tberghammer, rengolin, aemerson.
xfail TestCallUserAnonTypedef.test for -mthumb,
TestReturnValue.test_with_python for hard fp,
TestLldbGdbServer.s
fjricci updated this revision to Diff 51678.
fjricci added a comment.
Extend SBCommandReturnObject API to allow for taking file ownership
http://reviews.llvm.org/D18459
Files:
include/lldb/API/SBCommandReturnObject.h
scripts/interface/SBCommandReturnObject.i
source/API/SBCommandReturnObje
clayborg added a comment.
We don't necessarily need to expose this new API to swig. We get to pick and
choose what we expose to Python in the SBCommandReturnObject.i file. So leave
the .i file as is and use %rename to specify "transfer_ownership = true". Will
that work?
http://reviews.llvm.or
Quoting from the original submission notes below:
> This feature is controlled by an expression command option, a target property
> and the
> > SBExpressionOptions setting.
To be more explicit, if you don't want this behavior, put:
settings set target.auto-apply-fixits no
in your .lldbinit, or
fjricci added a comment.
Actually, I think this may open a new can of worms. Adding that flag to the API
doesn't necessarily achieve what we want. The current bug is that we take a
Python file (owned by the Python caller), and we know that the Python caller
does not want to transfer ownership o
fjricci added a comment.
I think that would be sufficient to solve the problem.
I could use a `%rename` to rename the `SetImmediateOutputFile (FILE *fh)` call
to a private function in `%extend`, which will then call
`SetImmediateOutputFile (FILE *fh, transfer_ownership=true)` instead.
Does tha
Will do.
> On Mar 24, 2016, at 3:30 PM, Zachary Turner wrote:
>
> Is there any way you could try it out for me? It still doesn't build
> successfully from the IDE with those steps.
>
> The patch should apply cleanly at tip. Later this week I can try to nuke my
> whole lldb directory and s
clayborg requested changes to this revision.
clayborg added a comment.
Seems like we need to just add the following to the API:
void
SetImmediateOutputFile (FILE *fh, bool transfer_ownership);
void
SetImmediateErrorFile (FILE *fh, bool transfer_ownership);
This should solve our proble
fjricci added a comment.
It appears that `%extend` directives only have access to public class members.
So my idea won't work. I'll try to overload with a fd call, presumably that
call can be exposed in the API? Or is it better if it isn't?
The difficulty with overloading is that, for overloade
As long as it only changes the private API and not the public it's probably
fine, if you think that will work feel free to give it a try and upload a
new patch
On Fri, Mar 25, 2016 at 9:12 AM Francis Ricci wrote:
> fjricci added a comment.
>
> Would we want this overloaded method taking an int (f
fjricci added a comment.
Would we want this overloaded method taking an int (fd) instead of a FILE* to
be present in the API? Or hidden somehow? I'm new to swig, but it looks like
python-extensions.swig includes some private extensions to the
CommandReturnObject class already.
Overloading with
38 matches
Mail list logo
