Sep 16 2016
Aug 31 2016
Aug 22 2016
@djasper, I don't seem to have commit access to cfe so awould you be willing to commit this on my behalf?
Aug 9 2016
Make print output the same 2-3
Aug 3 2016
Jul 28 2016
My pleasure! We expect to need to do this on the Xcode side since we aren't using cmake like everyone else.
Regarding r277012, I'm a little confused about the message "Also, fixed up typos in RenderScript code that could not possibly compile." Is this code broken somehow? It build for us with GCC, and green dragon seems fine with it. Is there some particular compiler for which this is broken because everything "Works for Me"?
Nope nope you're fine. I tried to quickly fix my comment in follow ups to my commit message emails. I looked too quickly at the filenames and figured the error was introduced from the RenderScript change. It was in fact from Saleem's change. It was in files that he couldn't compile unless he was on Xcode, so the typos came in there.
I've got a fix to make this work in Xcode, but I'm currently stuck behind the missing Condition.cpp from r277011 to verify.
Jul 18 2016
Sorry Chris, I didn't see this one. It appeared while I was posting my last message
LLVM_HOST_TRIPLE is not intended to match the target, and it shouldn't be used in situations where it must match the target. I'm not familiar with how lldb builds the remote server in CMake, but using LLVM_HOST_TRIPLE is not the right answer.
Supporting specifying the triple manually is a completely separate issue from the bug you encountered. I'd prefer to make target detection for windows work correctly and reliably so that we don't need to support setting LLVM_HOST_TRIPLE manually. Other than the bugs in get_host_triple, is there a reason you feel the need to set the host triple manually?
Jul 15 2016
I very much believe you are doing something wrong.
Your description of the problem doesn't match the error message, and I can tell you that the solution *isn't* to make get_host_triple return anything that isn't actually the host triple.
Can you explain why this is necessary when cross-targeting? I kinda feel that the problem is more likely that the LLVM_HOST_TRIPLE is being used in places where a *target* triple should be used.
Jul 14 2016
Jul 7 2016
- Ensure if ANDROID_SERIAL is set, it exists in the list of connected devices (Address feedback from @ovyalov)
- Also add a hint in the error message in case multiple devices are attached and no serial number is available.
Jul 6 2016
Jun 15 2016
committed in http://reviews.llvm.org/rL272800
differential revision: http://reviews.llvm.org/D17027
Jun 3 2016
I'd like to give this another *bump*, and commit this soon assuming positive review.
Sorry for the delay, I wanted to run tests...
May 31 2016
May 20 2016
May 13 2016
rebased on current HEAD
Apr 8 2016
Mar 29 2016
Mar 17 2016
I haven't had a chance to try this out (at EuroLLVM) but looks good.
Mar 15 2016
Overall this patch is great cleanup!
Mar 11 2016
I added a regression test in this diff
Mar 10 2016
Mar 9 2016
Mar 7 2016
Mar 1 2016
Updated diff to show full context
Feb 29 2016
Feb 25 2016
Feb 18 2016
If you have the time, I'd appreciate your comments.
Feb 16 2016
Feb 15 2016
rebased on current HEAD
Feb 10 2016
This patch is on an out of date ClangExpressionParser.cpp. The feature added in http://reviews.llvm.org/rL259644 allows a more generic way of implementing what I believe you're trying to achieve with this patch. It's probably worth a look.
This seems fine as a generic instrumentation point. Obviously, the onus in on the passes, since they could totally ruin the expression evaluation if they don't do their job right... But I'm not sure there's any good way to make this not a sharp tool. But you should wait on Sean to weigh in as well...
Feb 9 2016
Feb 2 2016
I'd like a final review on this patch if one of the code owners can take the time, please?
Jan 28 2016
Jan 25 2016
This differential seems to have introduced a regression on x86_64 Android, where std::bad_alloc is thrown during process attach. I've reverted this locally, and filed a bug, but as this is code I'm not familiar with, I'd appreciate it if @ravitheja were able to take a look at this again.
Jan 21 2016
Address @spyffe's previous suggestions regarding modifying target options in place. This allows for a simpler and more maintainable solution than previously implemented, and requires no extra datatype definitions.
Jan 13 2016
Responding to Sean Callanan's suggestions in previous differential RE accepting an existing set of TargetOptions as the basis to configure a custom set.
Jan 12 2016
I'm a little concerned that LanguageRuntime::GetOverrideExprOptions() appears to generate a new set of options from whole cloth rather than using the existing set as a starting point.
Specifically, since your use case is wanting to override the calling convention, I think it's heavy handed to override all the options. I could conceive of new expression parser features changing some other flags in the future, and it'd be unfortunate if we had to duplicate those features in the ActionScript code just because the options are being overridden.
Jan 7 2016
Jan 5 2016
Dec 24 2015
Updated implementation as per comment on manually set user language: http://reviews.llvm.org/D15527#inline-127860 . This patch adds checking for non eLanguageTypeUnknow expression language before falling back to the language of the current stack frame.
Dec 15 2015
FYI This feature was originally discussed on the ML: http://lists.llvm.org/pipermail/lldb-dev/2015-December/009006.html