Page MenuHomePhabricator
Feed Advanced Search

Jul 12 2019

xiaobai committed rL365939: [Core] Generalize ValueObject::MaybeCalculateCompleteType.
[Core] Generalize ValueObject::MaybeCalculateCompleteType
Jul 12 2019, 11:36 AM
xiaobai closed D64159: [Core] Generalize ValueObject::MaybeCalculateCompleteType.
Jul 12 2019, 11:36 AM · Restricted Project

Jul 11 2019

xiaobai committed rGbab7e3d78b01: [Expression] Move IRDynamicChecks to ClangExpressionParser (authored by xiaobai).
[Expression] Move IRDynamicChecks to ClangExpressionParser
Jul 11 2019, 5:59 PM
xiaobai committed rL365853: [Expression] Move IRDynamicChecks to ClangExpressionParser.
[Expression] Move IRDynamicChecks to ClangExpressionParser
Jul 11 2019, 5:58 PM
xiaobai closed D64591: [Expression] Move IRDynamicChecks to ClangExpressionParser.
Jul 11 2019, 5:58 PM · Restricted Project
xiaobai added a comment to D64591: [Expression] Move IRDynamicChecks to ClangExpressionParser.

That would be cleaner.

OTOH, the original reason for these checkers was to help people understand crashes in their expressions more clearly. Supposedly, modern languages "don't have pointers" and can't have bad objects, so the kind of crashes this instrumentation was supposed to help with "can't happen" and checkers for such languages wouldn't be all that helpful...

So while cleaner, maybe generalizing this more fully isn't a high priority change? In which case, just getting them out of generic code seems fine as a stopping point. Your choice.

Jul 11 2019, 5:05 PM · Restricted Project
xiaobai committed rG2c3c045dcbfe: [Target] Replace Plugin headers with non-plugin headers (authored by xiaobai).
[Target] Replace Plugin headers with non-plugin headers
Jul 11 2019, 4:46 PM
xiaobai committed rL365843: [Target] Replace Plugin headers with non-plugin headers.
[Target] Replace Plugin headers with non-plugin headers
Jul 11 2019, 4:46 PM
xiaobai added a comment to D64591: [Expression] Move IRDynamicChecks to ClangExpressionParser.

Then the IRDynamicCheck part would go with LLVMUserExpression, and the C-specific checks in Clang...

Jul 11 2019, 4:07 PM · Restricted Project
xiaobai added a comment to D64591: [Expression] Move IRDynamicChecks to ClangExpressionParser.

This is a little unclear to me. LLVMUserExpression is the class that represents "anything that uses LLVM at its back end." Both the Swift & Clang user expressions are instances of this. Running through IR and inserting little callouts is an LLVMUserExpression type thing. So it seems like this move is in the right direction, but to be really clean needs to represent LLVMUserExpression in the Plugin Hierarchy.

Jul 11 2019, 4:00 PM · Restricted Project
xiaobai added a comment to D64599: [LanguageRuntime] Move CPPLanguageRuntime into a plugin.

Anyway, if you can make all the generic parts of lldb not depend on the language specific - but still abstract - part of the plugin, that would be fine. Then just LanguageRuntime.h would live in Target, and CPPLanguageRuntime would live in Plugins/Language

Jul 11 2019, 3:50 PM · Restricted Project
xiaobai added a comment to D64599: [LanguageRuntime] Move CPPLanguageRuntime into a plugin.

My model for this was that there was a CPPLanguageRuntime.cpp that contains everything you can implement about the CPP runtime that is independent of any particular implementation of the CPP language runtime, and then a plugin instance (in this case the ItaniumABILanguageRuntime) that contains all the bits that are specific to a particular implementation. Then putting the CPPLanguageRuntime.cpp in Target lets you know that this has to only contain the generic parts of the runtime behavior. That still seems to me a useful distinction.

I think that's fine, but it does not conflict the idea of the generic parts of a cpp language runtime being a plugin also. This way the generic parts of lldb would be truly language agnostic. Then if anything wants to work with a c++ runtime, but it does not care which one, it can use CPPLanguageRuntime. And if you need a very specific runtime, you go for the Itanium thingy.

Jul 11 2019, 3:13 PM · Restricted Project
xiaobai updated the diff for D64591: [Expression] Move IRDynamicChecks to ClangExpressionParser.

Remove documentation boilerplate

Jul 11 2019, 3:04 PM · Restricted Project
xiaobai added inline comments to D64599: [LanguageRuntime] Move CPPLanguageRuntime into a plugin.
Jul 11 2019, 2:26 PM · Restricted Project
xiaobai added inline comments to D64591: [Expression] Move IRDynamicChecks to ClangExpressionParser.
Jul 11 2019, 2:25 PM · Restricted Project
xiaobai updated the diff for D64591: [Expression] Move IRDynamicChecks to ClangExpressionParser.

Reflow comment
Remove newline

Jul 11 2019, 2:23 PM · Restricted Project
xiaobai created D64599: [LanguageRuntime] Move CPPLanguageRuntime into a plugin.
Jul 11 2019, 2:16 PM · Restricted Project
xiaobai added a comment to D64583: [lldb][test_suite] Fix skipIfTargetAndroid decorator.

Can you add more context to this diff? I can't see the code surrounding the changes. You can get the whole context with something like git show -U9999.

Jul 11 2019, 1:52 PM · Restricted Project, Restricted Project
xiaobai created D64591: [Expression] Move IRDynamicChecks to ClangExpressionParser.
Jul 11 2019, 1:51 PM · Restricted Project

Jul 10 2019

xiaobai committed rG461a9d98d704: [Expression] IR Instrumenters should have a UtilityFunction (authored by xiaobai).
[Expression] IR Instrumenters should have a UtilityFunction
Jul 10 2019, 1:43 PM
xiaobai committed rL365696: [Expression] IR Instrumenters should have a UtilityFunction.
[Expression] IR Instrumenters should have a UtilityFunction
Jul 10 2019, 1:43 PM

Jul 9 2019

xiaobai added inline comments to D64159: [Core] Generalize ValueObject::MaybeCalculateCompleteType.
Jul 9 2019, 4:54 PM · Restricted Project
xiaobai updated the diff for D64159: [Core] Generalize ValueObject::MaybeCalculateCompleteType.

Switch to using llvm::Optional<CompilerType> for the return type
Rename method from CalculateCompleteType to GetRuntimeType

Jul 9 2019, 4:50 PM · Restricted Project
xiaobai committed rG269b9f940ff9: [lldb] Quick Fix: IRExecutionUnit check pointer before access it (authored by xiaobai).
[lldb] Quick Fix: IRExecutionUnit check pointer before access it
Jul 9 2019, 3:26 PM
xiaobai committed rL365567: [lldb] Quick Fix: IRExecutionUnit check pointer before access it.
[lldb] Quick Fix: IRExecutionUnit check pointer before access it
Jul 9 2019, 3:24 PM
xiaobai closed D64434: [lldb] Quick Fix: IRExecutionUnit check pointer before access it.
Jul 9 2019, 3:24 PM · Restricted Project, Restricted Project
xiaobai committed rG695f7821e2d9: [lldb_test_suite] Fix lldb test suite targeting remote Android (authored by xiaobai).
[lldb_test_suite] Fix lldb test suite targeting remote Android
Jul 9 2019, 2:39 PM
xiaobai committed rL365561: [lldb_test_suite] Fix lldb test suite targeting remote Android.
[lldb_test_suite] Fix lldb test suite targeting remote Android
Jul 9 2019, 2:39 PM
xiaobai closed D64118: [lldb_test_suite] Fix lldb test suite targeting remote Android.
Jul 9 2019, 2:39 PM · Restricted Project, Restricted Project
xiaobai accepted D64434: [lldb] Quick Fix: IRExecutionUnit check pointer before access it.
Jul 9 2019, 12:52 PM · Restricted Project, Restricted Project
xiaobai accepted D64397: [CMake] Remove extra lldb-framework target.

Thanks for cleaning this up!

Jul 9 2019, 10:53 AM · Restricted Project, Restricted Project
xiaobai accepted D64408: [CMake] `install-distribution` for LLDB on Darwin.

I like the idea a lot and the implementation looks alright. LGTM

Jul 9 2019, 10:53 AM · Restricted Project, Restricted Project
xiaobai accepted D64399: [CMake] Distribution builds for LLDB standalone.
Jul 9 2019, 10:47 AM · Restricted Project, Restricted Project

Jul 8 2019

xiaobai added a comment to D64365: [lldb] Let table gen create command option initializers..

This is awesome, thanks for doing this! I was also thinking about doing something like this at some point as well. :)

Jul 8 2019, 3:01 PM · Restricted Project, Restricted Project
xiaobai added a comment to D64042: [Symbol] Improve Variable::GetLanguage.

Why did you make this a function of Variable, rather than SymbolContextScope?

Jul 8 2019, 2:54 PM · Restricted Project
xiaobai added inline comments to D64159: [Core] Generalize ValueObject::MaybeCalculateCompleteType.
Jul 8 2019, 2:33 PM · Restricted Project
xiaobai added a comment to D64042: [Symbol] Improve Variable::GetLanguage.

ping

Jul 8 2019, 2:17 PM · Restricted Project

Jul 3 2019

xiaobai created D64159: [Core] Generalize ValueObject::MaybeCalculateCompleteType.
Jul 3 2019, 1:47 PM · Restricted Project
xiaobai added a comment to D64154: [Docs] Unify build instructions .

Thanks for doing this! :D

Jul 3 2019, 1:26 PM · Restricted Project
xiaobai added a reviewer for D64118: [lldb_test_suite] Fix lldb test suite targeting remote Android: labath.

This patch looks fine to me overall. I'm unsure if LLDB has a guarantee about which NDK version its compatible with, but I'm alright with staying up to date with the latest release

Jul 3 2019, 9:59 AM · Restricted Project, Restricted Project

Jul 2 2019

xiaobai committed rG8055cbc44909: [Symbol] Add DeclVendor::FindTypes (authored by xiaobai).
[Symbol] Add DeclVendor::FindTypes
Jul 2 2019, 12:56 PM
xiaobai committed rL364962: [Symbol] Add DeclVendor::FindTypes.
[Symbol] Add DeclVendor::FindTypes
Jul 2 2019, 12:56 PM
xiaobai closed D63853: [Symbol] Add DeclVendor::FindTypes.
Jul 2 2019, 12:56 PM · Restricted Project

Jul 1 2019

xiaobai updated the diff for D63853: [Symbol] Add DeclVendor::FindTypes.

Pavel's suggestion

Jul 1 2019, 3:45 PM · Restricted Project
xiaobai created D64042: [Symbol] Improve Variable::GetLanguage.
Jul 1 2019, 3:35 PM · Restricted Project
xiaobai committed rGd7fcee62f114: [Core] Generalize ValueObject::IsRuntimeSupportValue (authored by xiaobai).
[Core] Generalize ValueObject::IsRuntimeSupportValue
Jul 1 2019, 1:37 PM
xiaobai committed rL364845: [Core] Generalize ValueObject::IsRuntimeSupportValue.
[Core] Generalize ValueObject::IsRuntimeSupportValue
Jul 1 2019, 1:36 PM
xiaobai closed D63240: [Core] Generalize ValueObject::IsRuntimeSupportValue.
Jul 1 2019, 1:36 PM · Restricted Project
xiaobai added a comment to D63240: [Core] Generalize ValueObject::IsRuntimeSupportValue.

Centralizing it means changing the classes that inherit from SymbolContextScope, so I will refactor that in a seaparate change and stack this change on top of that one.

Jul 1 2019, 11:01 AM · Restricted Project

Jun 27 2019

xiaobai updated the diff for D63240: [Core] Generalize ValueObject::IsRuntimeSupportValue.
  • Implement @jingham's suggestion
  • Change Function::GetLanguage to first guess the language from the name of the function you're in.
  • Fix a bug in DWARFASTParserClang::ParseFunctionFromDWARF that qualifies ObjC methods as if they were C++ methods when parsing a function from an ObjC++ CU
Jun 27 2019, 10:05 PM · Restricted Project
xiaobai added a comment to D63240: [Core] Generalize ValueObject::IsRuntimeSupportValue.

@jingham: Okay, so I tried to do what you suggested and that solution doesn't work because of ObjC++. After looking into it, it looks like Variable and Function just ask the CompileUnit for the language type instead of determining it themselves meaning that we determining the Variable's language boils down to asking the CompileUnit for its language. That can probably be improved, but I think that just relying on the SymbolContextScope alone isn't yet sufficient. I think it would be worth it to ask the SymbolContextScope before trying all the loaded language runtimes though. Would you be okay with that solution?

That's unfortunate. For ObjC++ CompUnits we should get the language from the function name: it's either a C++ mangled name (language => , or an ObjC name...

Jun 27 2019, 3:28 PM · Restricted Project
xiaobai added a comment to D63240: [Core] Generalize ValueObject::IsRuntimeSupportValue.

@jingham: Okay, so I tried to do what you suggested and that solution doesn't work because of ObjC++. After looking into it, it looks like Variable and Function just ask the CompileUnit for the language type instead of determining it themselves meaning that we determining the Variable's language boils down to asking the CompileUnit for its language. That can probably be improved, but I think that just relying on the SymbolContextScope alone isn't yet sufficient. I think it would be worth it to ask the SymbolContextScope before trying all the loaded language runtimes though. Would you be okay with that solution?

Jun 27 2019, 2:46 PM · Restricted Project

Jun 26 2019

xiaobai added a comment to D63240: [Core] Generalize ValueObject::IsRuntimeSupportValue.

I was talking specifically about which runtime should be asked the question. It seemed to me most straightforward to invert the order in which the question was asked, but another way to get the same effect without rejiggering the API's at this point is to have ValueObject::IsRuntimeSupportValue do:

SymbolContextScope *sym_ctx_scope = GetSymbolContextScope();
LanguageType languageToAsk = eLanguageTypeUnknown;
if (sym_ctx_scope) {
   Function *func = sym_ctx_scope->CalculateSymbolContextFunction();
   if (func)
    languageToAsk = func->GetLanguage();
  else  //Do something similar for the CU.

Then get the languageRuntime for languageToAsk and ask it. That way you don't have to monkey with the runtime language of the ValueObject, but you are still asking the right actor.

Jun 26 2019, 5:13 PM · Restricted Project
xiaobai created D63853: [Symbol] Add DeclVendor::FindTypes.
Jun 26 2019, 4:58 PM · Restricted Project
xiaobai added a comment to D63240: [Core] Generalize ValueObject::IsRuntimeSupportValue.

To be more precise, "frame" is the wrong word to use, Variables have "scopes"... All Variables have a scope, though not every scope is contained in a Function.

But just to back up a little bit.

We're getting into problems, it seems to me, because we're asking ValueObjects questions that should be asked of their containing scope. For instance, if you are in a Function, and want to list the locals and arguments, you want to know what the rules for the Function are for which artificial variables should and should not be printed, not any of its value objects.

For instance, ObjC could decide that it wants to reserve the word "this" in methods of ObjC classes in ObjC++ files, and use it as a should-be-hidden artificial variable that will always store a pointer to C++ object for some evil purposes. Asking the runtime language of this artificial "this" variable whether the word "this" is runtime whitelisted seems like the wrong thing to do. After all, the Variable has a CompilerType that's clearly a C++ object, so you might reasonably expect its runtime language to be C++. But then you would get the wrong answer. You really need to ask the Function "what are your rules for hiding artificial variables".

Getting to the right actor to ask about "which artificial variables to show" was the reason for suggesting that the runtime language of a Variable should be that of its containing scope. But then you get into the weird situation where a C++ Variable is claiming a runtime language of ObjC++, which seems a little odd. Instead, it makes more sense to get the RuntimeLanguage of the current frame, and then iterate over the variables and ask the frame's runtime whether they should be shown or not.

I'm not sure what to do about global variables. Reasoning by analogy, that's something that the language of the CompileUnit which contains the global variables should answer.

Jun 26 2019, 4:38 PM · Restricted Project
xiaobai added a comment to D63240: [Core] Generalize ValueObject::IsRuntimeSupportValue.

Shouldn't ValueObjectVariables figure out their runtime language from their defining frame, not their CompilerType? For a ValueObject you get from an expression, you probably can't do that. But we're always talking about hiding locals or args here - i.e. they are all ValueObjectVariables. And it seems to me that in that case getting the RuntimeLanguage from the containing frame is much more useful than from the CompilerType.

Jun 26 2019, 3:07 PM · Restricted Project
xiaobai added inline comments to D63240: [Core] Generalize ValueObject::IsRuntimeSupportValue.
Jun 26 2019, 2:33 PM · Restricted Project

Jun 25 2019

xiaobai updated the diff for D63240: [Core] Generalize ValueObject::IsRuntimeSupportValue.

Address feedback

Jun 25 2019, 12:35 PM · Restricted Project

Jun 24 2019

xiaobai added a comment to D63745: [CMake] Check that a certificate for lldb is present at build time..

This code should go to tools/debugserver/source/CMakeLists.txt so that it is next to the code which performs the actual code signing. Doing that will make it easier to keep it in sync with changes to code signing, as well as make it obvious that it is not in sync with them right now (there's a pretty complex interaction of various cmake options (LLDB_CODESIGN_IDENTITY, LLVM_CODESIGNING_IDENTITY, LLDB_USE_SYSTEM_DEBUGSERVER, etc.) which affects code signing, and this code is ignoring all of those)...

Jun 24 2019, 11:47 PM · Restricted Project, Restricted Project
xiaobai added a comment to D63745: [CMake] Check that a certificate for lldb is present at build time..

On second thought, let's check that LLDB_CODESIGN_IDENTITY equals lldb_codesign before doing this check.

Jun 24 2019, 11:46 PM · Restricted Project, Restricted Project
xiaobai updated the diff for D63240: [Core] Generalize ValueObject::IsRuntimeSupportValue.

Address feedback

Jun 24 2019, 6:45 PM · Restricted Project
xiaobai added inline comments to D63240: [Core] Generalize ValueObject::IsRuntimeSupportValue.
Jun 24 2019, 5:44 PM · Restricted Project
xiaobai committed rG11cfa92a1967: [Target] Hoist LanguageRuntime::GetDeclVendor (authored by xiaobai).
[Target] Hoist LanguageRuntime::GetDeclVendor
Jun 24 2019, 1:34 PM
xiaobai committed rL364229: [Target] Hoist LanguageRuntime::GetDeclVendor.
[Target] Hoist LanguageRuntime::GetDeclVendor
Jun 24 2019, 1:34 PM
xiaobai closed D63622: [Target] Hoist LanguageRuntime::GetDeclVendor.
Jun 24 2019, 1:34 PM · Restricted Project
xiaobai committed rG73901961ee1a: [ABI] Remove unused variables in ABIWindows_x86_64 (authored by xiaobai).
[ABI] Remove unused variables in ABIWindows_x86_64
Jun 24 2019, 12:44 PM
xiaobai committed rL364223: [ABI] Remove unused variables in ABIWindows_x86_64.
[ABI] Remove unused variables in ABIWindows_x86_64
Jun 24 2019, 12:43 PM
xiaobai committed rG09ede9d65f13: [ABI] Implement Windows ABI for x86_64 (authored by xiaobai).
[ABI] Implement Windows ABI for x86_64
Jun 24 2019, 11:23 AM
xiaobai committed rL364216: [ABI] Implement Windows ABI for x86_64.
[ABI] Implement Windows ABI for x86_64
Jun 24 2019, 11:23 AM
xiaobai closed D62213: [ABI] Implement Windows ABI for x86_64.
Jun 24 2019, 11:23 AM · Restricted Project, Restricted Project

Jun 21 2019

xiaobai added inline comments to D63622: [Target] Hoist LanguageRuntime::GetDeclVendor.
Jun 21 2019, 2:26 PM · Restricted Project
xiaobai committed rL364098: [Target] Decouple ObjCLanguageRuntime from LanguageRuntime.
[Target] Decouple ObjCLanguageRuntime from LanguageRuntime
Jun 21 2019, 1:49 PM
xiaobai updated the diff for D63622: [Target] Hoist LanguageRuntime::GetDeclVendor.

Add a few autos

Jun 21 2019, 1:04 PM · Restricted Project
xiaobai added inline comments to D63622: [Target] Hoist LanguageRuntime::GetDeclVendor.
Jun 21 2019, 1:04 PM · Restricted Project
xiaobai added a reviewer for D63240: [Core] Generalize ValueObject::IsRuntimeSupportValue: jingham.
Jun 21 2019, 12:48 PM · Restricted Project
xiaobai added inline comments to D63622: [Target] Hoist LanguageRuntime::GetDeclVendor.
Jun 21 2019, 12:43 PM · Restricted Project
xiaobai committed rG7f9c9f226423: [Target] Decouple ObjCLanguageRuntime from LanguageRuntime (authored by xiaobai).
[Target] Decouple ObjCLanguageRuntime from LanguageRuntime
Jun 21 2019, 12:41 PM
xiaobai closed D63181: [Target] Decouple ObjCLanguageRuntime from LanguageRuntime.
Jun 21 2019, 12:41 PM · Restricted Project

Jun 20 2019

xiaobai added a comment to D63582: [LICM & MSSA] Limit unsafe sinking and hoisting..

The test pr42294.ll breaks when running the test suite on a build without asserts. Specifically, opt doesn't know about the option -debug-only. I confirmed that adding a REQUIRES: asserts to the beginning of the test fixes things. I'm not too familiar with this area, so if you have a way to make it work with non-asserts build then that would be great. Otherwise, we can just require that asserts are enabled for this test to run.

Jun 20 2019, 4:52 PM · Restricted Project
xiaobai added a comment to D62504: Avoid calling LoadModules twice when modules change.

ping @labath @clayborg any issues with this one?

Jun 20 2019, 4:25 PM · Restricted Project
xiaobai added a comment to D63622: [Target] Hoist LanguageRuntime::GetDeclVendor.

This change makes it clear that SBTarget::FindFirstType should take a language, but that is orthogonal to this change.

Jun 20 2019, 2:25 PM · Restricted Project
xiaobai added a comment to D63240: [Core] Generalize ValueObject::IsRuntimeSupportValue.

ping

Jun 20 2019, 2:00 PM · Restricted Project
xiaobai created D63622: [Target] Hoist LanguageRuntime::GetDeclVendor.
Jun 20 2019, 1:47 PM · Restricted Project

Jun 19 2019

xiaobai committed rG86df61cc9323: [Process] Remove unused field from HistoryThread (authored by xiaobai).
[Process] Remove unused field from HistoryThread
Jun 19 2019, 2:34 PM
xiaobai committed rL363881: [Process] Remove unused field from HistoryThread.
[Process] Remove unused field from HistoryThread
Jun 19 2019, 2:30 PM
xiaobai closed D63357: [Process] Remove unused field from HistoryThread.
Jun 19 2019, 2:30 PM · Restricted Project

Jun 17 2019

xiaobai added a comment to D63363: [Signals] Create a plugin directory just for signals.
In D63363#1546464, @jfb wrote:

Can you describe what the goal of your plugin architecture is? Maybe you need an RFC by email before moving stuff around.

I want to understand what you're going for because as they are today the signals mostly work, and aren't really tested (because injecting these conditions isn't trivial). Anything you change is likely to break some subtle invariant which will only repro when your change is deployed at scale.

Jun 17 2019, 10:07 AM
xiaobai added a comment to D63363: [Signals] Create a plugin directory just for signals.

Although this is technically correct and pretty consistent with our other "plugins", I can't help but feel that it's incredibly wasteful. Each of the XXXSignals.cpp files is less than a 100 lines long (with the licence header and all bolierplate) and it's unlikely to ever grow beyond that. And essentially, all these files do is define a single enum. The reason they are this long is because the UnixSignals class is already over-engineered (e.g. I don't see why LinuxSignals needs to be a separate class, or why it needs to repeat the descriptions/default stop values for each of the signals). Making this a plugin would just add another chunk of boilerplate on top of that.

I don't know about others, but I'd rather us move in a direction which reduces the amount of boilerplate instead of adding more of it. In my ideal world, each of these signal definitions would just be a bunch of (number, name) pairs. This doesn't have/need to be a class or a plugin; a single constexpr variable would suffice for that. Then we'd just cross-reference this mapping with another one which gives the default stop values and descriptions for each of the signals, and that's it.

I know I am repeating myself, but each time I say this, it's because I find another reason for it: I think we should start a new library which I would roughly define as "utilities for describing and manipulating various low-level aspects of processes, but which is agnostic of any actual process class". The idea would be that we can shove here all classes which are shared between lldb-server liblldb. UnixSignals would be one candidate for it. AuxVector, MemoryRegionInfo are others. Plugins/Process/Utility (where most of the signal classes live) would be a pretty good place for it already, were it not for the "Plugins" part (it would be weird for non-plugin code to depend on something called a "plugin"). However, maybe we could just create a new top-level library called "ProcessUtil" (or whatever name we come up with) and move the relevant stuff there.

Anyway, TL;DR: I think this should be handled differently. However, if others are fine with this approach, then feel free to ignore me.

Jun 17 2019, 9:54 AM

Jun 14 2019

xiaobai added a reviewer for D63370: Specify log level for CMake messages (less stderr): sgraenitz.

Seems alright to me. I'd like to see 1 message changed from a STATUS to a WARNING though.

Jun 14 2019, 5:06 PM · Restricted Project, Restricted Project, Restricted Project
xiaobai updated the diff for D63363: [Signals] Create a plugin directory just for signals.

Fix up include in gtest

Jun 14 2019, 3:19 PM
xiaobai created D63363: [Signals] Create a plugin directory just for signals.
Jun 14 2019, 3:00 PM
xiaobai created D63357: [Process] Remove unused field from HistoryThread.
Jun 14 2019, 1:16 PM · Restricted Project

Jun 13 2019

xiaobai committed rG347ec0faa79a: [NFC] Replace a plugin header with a non-plugin header (authored by xiaobai).
[NFC] Replace a plugin header with a non-plugin header
Jun 13 2019, 4:39 PM
xiaobai committed rL363338: [NFC] Replace a plugin header with a non-plugin header.
[NFC] Replace a plugin header with a non-plugin header
Jun 13 2019, 4:37 PM
xiaobai updated the summary of D63181: [Target] Decouple ObjCLanguageRuntime from LanguageRuntime.
Jun 13 2019, 3:53 PM · Restricted Project
xiaobai updated the diff for D63181: [Target] Decouple ObjCLanguageRuntime from LanguageRuntime.

Implement suggestion
Address feedback

Jun 13 2019, 3:50 PM · Restricted Project
xiaobai updated the diff for D63240: [Core] Generalize ValueObject::IsRuntimeSupportValue.

Simplify ValueObject::IsRuntimeSupportValue

Jun 13 2019, 1:08 PM · Restricted Project
xiaobai added inline comments to D63240: [Core] Generalize ValueObject::IsRuntimeSupportValue.
Jun 13 2019, 11:52 AM · Restricted Project

Jun 12 2019

xiaobai created D63240: [Core] Generalize ValueObject::IsRuntimeSupportValue.
Jun 12 2019, 6:00 PM · Restricted Project
xiaobai committed rG5b99928ba88a: [Expression] Add PersistentExpressionState::GetCompilerTypeFromPersistentDecl (authored by xiaobai).
[Expression] Add PersistentExpressionState::GetCompilerTypeFromPersistentDecl
Jun 12 2019, 10:44 AM