Hi,
I've tagged 10.0.1-final. Testers, please begin uploading your binaries.
Thanks,
Tom
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
BTW, Adrian already did something along these lines for the dynamic types of
swift “frame variable” values. In that case, the dynamic type is quite likely
from some entirely unrelated module. Swift makes a lot of use of protocols, so
code is going to pass through your module that shares no act
It seems like you are having to work hard in the ValueObject system because you
don’t want to use single AST Type for the ValueObject’s type. Seems like it be
much simpler if you could cons up a complete type in the ScratchASTContext, and
then use the underlying TypeSystem to do the layout comp
Thanks for the write up!
I agree that the existing APIs are useful for exploring the types as they
appear (and are completed within) in the module they came from. Now we are
asking more complex questions from them. As with all software, things started
out simple and have gotten quite a bit more
Hello all,
With the expression evaluation part of -flimit-debug-info nearly
completed, I started looking at doing the same for the "frame variable"
command.
I have thought this would be simpler than the expression evaluator,
since we control most of that code. However, I have hit one snag, hence
