Page MenuHomePhabricator

xiaobai (Alex Langford)
uwu

Projects

User does not belong to any projects.

User Details

User Since
Mar 21 2017, 11:50 AM (121 w, 5 d)

Recent Activity

Fri, Jul 19

xiaobai abandoned D65025: [Symbol] Improve TypeSystemMap mutex safety.

Actually from the looks of it, I completely misunderstood what's going on here. It looks like AddToMap should only be called by things that hold the mutex, meaning that this change isn't actually necessary. I do think that makes this code kind of frustrating to understand though. Closing.

Fri, Jul 19, 4:04 PM
xiaobai added a comment to D64042: [Symbol] Improve Variable::GetLanguage.

ping

Fri, Jul 19, 3:34 PM
xiaobai created D65025: [Symbol] Improve TypeSystemMap mutex safety.
Fri, Jul 19, 3:30 PM
xiaobai accepted D64994: [CMake] Align debugserver with lldb-server on Darwin.

Excellent, thanks for taking care of this! :)

Fri, Jul 19, 10:57 AM · Restricted Project, Restricted Project

Thu, Jul 18

xiaobai added a comment to D64964: [API] Remove use of ClangASTContext from SBTarget.

All uses of this new function drop the error on the ground. Does that mean it doesn't matter? If it does, should we return an expected instead? Should we stop on the first error, or is it fine to overwrite when iterating over languages_for_expressions? It seems like the error handling needs some more work here.

Thu, Jul 18, 10:48 PM
xiaobai committed rGbb0896970afa: [NFC] Remove instances of unused ClangASTContext header (authored by xiaobai).
[NFC] Remove instances of unused ClangASTContext header
Thu, Jul 18, 5:40 PM
xiaobai committed rL366519: [NFC] Remove instances of unused ClangASTContext header.
[NFC] Remove instances of unused ClangASTContext header
Thu, Jul 18, 5:39 PM
xiaobai committed rG3e4a13a7f0b0: [Commands] Remove unused header from CommandObjectFrame (authored by xiaobai).
[Commands] Remove unused header from CommandObjectFrame
Thu, Jul 18, 5:27 PM
xiaobai committed rL366517: [Commands] Remove unused header from CommandObjectFrame.
[Commands] Remove unused header from CommandObjectFrame
Thu, Jul 18, 5:26 PM
xiaobai created D64964: [API] Remove use of ClangASTContext from SBTarget.
Thu, Jul 18, 5:11 PM
xiaobai added inline comments to D64806: [CMake] Always build debugserver on Darwin and allow tests to use the system's one.
Thu, Jul 18, 5:07 PM · Restricted Project, Restricted Project
xiaobai accepted D64959: [cmake] Update NATIVE build variables to account for standalone changes.

LGTM

Thu, Jul 18, 4:37 PM · Restricted Project
xiaobai committed rG79976b379001: [Breakpoint] Replace use of ClangASTContext with TypeSystem (authored by xiaobai).
[Breakpoint] Replace use of ClangASTContext with TypeSystem
Thu, Jul 18, 1:59 PM
xiaobai committed rL366495: [Breakpoint] Replace use of ClangASTContext with TypeSystem.
[Breakpoint] Replace use of ClangASTContext with TypeSystem
Thu, Jul 18, 1:58 PM

Wed, Jul 17

xiaobai added a comment to D64844: [Target] Remove Target::GetScratchClangASTContext.

Yes, I agree that replacing ClangASTContext uses with TypeSystem would be the right thing to do, and it's what I plan on doing next. There are instances where you really do want a ClangASTContext (e.g. in plugins related to clang expression parsing and objc), and so having a convenience function like this means you don't have to cast the result of every call. This is similar to ObjCLanguageRuntime::Get. I don't mind abandoning this patch though.

Wed, Jul 17, 12:50 PM
xiaobai added a comment to D64844: [Target] Remove Target::GetScratchClangASTContext.

This seems partly wrong to me. The point is that the Target holds scratch AST contexts for all the languages it supports. They are the central repository for the accumulation of effects of expressions evaluated while that target is alive. For instance, all the user defined types and variables go there. The Target also manages its lifecycle. For instance, in the swift case if there's a module that we can't import, we have to fall back to making an AST Context for each module we can successfully import and dispatching expressions to the appropriate one of those.

So all the Scratch AST Contexts are properly owned by the target.

This move doesn't keep all the clients from knowing they are getting their hands on a ClangASTContext, so it doesn't seem like it achieves much hiding. All it does is conceal the ownership of the scratch AST context for C-family languages.

Wed, Jul 17, 11:28 AM
xiaobai accepted D64583: [lldb][test_suite] Fix skipIfTargetAndroid decorator.

LGTM

Wed, Jul 17, 11:13 AM · Restricted Project
xiaobai added inline comments to D64823: [CMake] Use LLVM_DIR and Clang_DIR for standalone builds..
Wed, Jul 17, 11:10 AM · Restricted Project, Restricted Project
xiaobai accepted D64847: Only build lldb-tblgen if it's not a current target.

This is a pretty interesting use case to say the least. I don't see an issue with it though, so go for it.

Wed, Jul 17, 11:04 AM
xiaobai added a comment to D64806: [CMake] Always build debugserver on Darwin and allow tests to use the system's one.

I think that this is a good change overall to do but the name LLDB_USE_SYSTEM_DEBUGSERVER is kind of a confusing to me. The name itself doesn't really convey to me that the system debugserver is going to be used for just testing. Before this change, that flag indicated that the system debugserver was going to be used for everything. Maybe you could change it to something like LLDB_TEST_WITH_SYSTEM_DEBUGSERVER?

Wed, Jul 17, 11:01 AM · Restricted Project, Restricted Project
xiaobai committed rGfc1c8f5d7d47: [Target][NFCI] Remove commented out code (authored by xiaobai).
[Target][NFCI] Remove commented out code
Wed, Jul 17, 12:14 AM
xiaobai committed rL366295: [Target][NFCI] Remove commented out code.
[Target][NFCI] Remove commented out code
Wed, Jul 17, 12:13 AM
xiaobai committed rGe574f8b3d891: [Target][NFCI] Rename variable (authored by xiaobai).
[Target][NFCI] Rename variable
Wed, Jul 17, 12:04 AM
xiaobai committed rL366292: [Target][NFCI] Rename variable.
[Target][NFCI] Rename variable
Wed, Jul 17, 12:03 AM

Tue, Jul 16

xiaobai updated the diff for D64844: [Target] Remove Target::GetScratchClangASTContext.

Remove ClangASTContext header from Target.cpp

Tue, Jul 16, 6:37 PM
xiaobai created D64844: [Target] Remove Target::GetScratchClangASTContext.
Tue, Jul 16, 6:33 PM
xiaobai accepted D64822: Don't require python exe and lib versions to match while crosscompiling.
Tue, Jul 16, 4:51 PM · Restricted Project
xiaobai committed rG0e534de4fef8: [Symbol] Remove unused fields from ClangASTContext (authored by xiaobai).
[Symbol] Remove unused fields from ClangASTContext
Tue, Jul 16, 2:06 PM
xiaobai committed rL366261: [Symbol] Remove unused fields from ClangASTContext.
[Symbol] Remove unused fields from ClangASTContext
Tue, Jul 16, 2:05 PM
xiaobai accepted D64812: [CMake] Fail when Python interpreter doesn't match Python libraries version .

This definitely caused me some pain a few months ago. Thanks for adding this!

Tue, Jul 16, 11:20 AM · Restricted Project, Restricted Project

Mon, Jul 15

xiaobai committed rG0d121273181f: [Target] Remove unused method Target::GetDefaultClangModuleSearchPaths (authored by xiaobai).
[Target] Remove unused method Target::GetDefaultClangModuleSearchPaths
Mon, Jul 15, 6:03 PM
xiaobai committed rL366161: [Target] Remove unused method Target::GetDefaultClangModuleSearchPaths.
[Target] Remove unused method Target::GetDefaultClangModuleSearchPaths
Mon, Jul 15, 6:03 PM
xiaobai committed rGb5701710a429: [LanguageRuntime] Move ObjCLanguageRuntime into a plugin (authored by xiaobai).
[LanguageRuntime] Move ObjCLanguageRuntime into a plugin
Mon, Jul 15, 3:57 PM
xiaobai committed rL366148: [LanguageRuntime] Move ObjCLanguageRuntime into a plugin.
[LanguageRuntime] Move ObjCLanguageRuntime into a plugin
Mon, Jul 15, 3:56 PM
xiaobai closed D64763: [LanguageRuntime] Move ObjCLanguageRuntime into a plugin.
Mon, Jul 15, 3:56 PM · Restricted Project
xiaobai created D64763: [LanguageRuntime] Move ObjCLanguageRuntime into a plugin.
Mon, Jul 15, 11:22 AM · Restricted Project

Fri, Jul 12

xiaobai committed rGe0678ca5473d: [LanguageRuntime] Move CPPLanguageRuntime into a plugin (authored by xiaobai).
[LanguageRuntime] Move CPPLanguageRuntime into a plugin
Fri, Jul 12, 1:11 PM
xiaobai committed rL365951: [LanguageRuntime] Move CPPLanguageRuntime into a plugin.
[LanguageRuntime] Move CPPLanguageRuntime into a plugin
Fri, Jul 12, 1:11 PM
xiaobai closed D64599: [LanguageRuntime] Move CPPLanguageRuntime into a plugin.
Fri, Jul 12, 1:10 PM · Restricted Project
xiaobai accepted D64661: [ObjectContainerBSDArchive] Simplify a few things (NFC).

LGTM

Fri, Jul 12, 1:04 PM · Restricted Project, Restricted Project
xiaobai committed rG24604ec799e0: [Core] Generalize ValueObject::MaybeCalculateCompleteType (authored by xiaobai).
[Core] Generalize ValueObject::MaybeCalculateCompleteType
Fri, Jul 12, 11:36 AM
xiaobai committed rL365939: [Core] Generalize ValueObject::MaybeCalculateCompleteType.
[Core] Generalize ValueObject::MaybeCalculateCompleteType
Fri, Jul 12, 11:36 AM
xiaobai closed D64159: [Core] Generalize ValueObject::MaybeCalculateCompleteType.
Fri, Jul 12, 11:36 AM · Restricted Project

Thu, Jul 11

xiaobai committed rGbab7e3d78b01: [Expression] Move IRDynamicChecks to ClangExpressionParser (authored by xiaobai).
[Expression] Move IRDynamicChecks to ClangExpressionParser
Thu, Jul 11, 5:59 PM
xiaobai committed rL365853: [Expression] Move IRDynamicChecks to ClangExpressionParser.
[Expression] Move IRDynamicChecks to ClangExpressionParser
Thu, Jul 11, 5:58 PM
xiaobai closed D64591: [Expression] Move IRDynamicChecks to ClangExpressionParser.
Thu, Jul 11, 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.

Thu, Jul 11, 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
Thu, Jul 11, 4:46 PM
xiaobai committed rL365843: [Target] Replace Plugin headers with non-plugin headers.
[Target] Replace Plugin headers with non-plugin headers
Thu, Jul 11, 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...

Thu, Jul 11, 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.

Thu, Jul 11, 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

Thu, Jul 11, 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.

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

Remove documentation boilerplate

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

Reflow comment
Remove newline

Thu, Jul 11, 2:23 PM · Restricted Project
xiaobai created D64599: [LanguageRuntime] Move CPPLanguageRuntime into a plugin.
Thu, Jul 11, 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.

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

Wed, Jul 10

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

Tue, Jul 9

xiaobai added inline comments to D64159: [Core] Generalize ValueObject::MaybeCalculateCompleteType.
Tue, Jul 9, 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

Tue, Jul 9, 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
Tue, Jul 9, 3:26 PM
xiaobai committed rL365567: [lldb] Quick Fix: IRExecutionUnit check pointer before access it.
[lldb] Quick Fix: IRExecutionUnit check pointer before access it
Tue, Jul 9, 3:24 PM
xiaobai closed D64434: [lldb] Quick Fix: IRExecutionUnit check pointer before access it.
Tue, Jul 9, 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
Tue, Jul 9, 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
Tue, Jul 9, 2:39 PM
xiaobai closed D64118: [lldb_test_suite] Fix lldb test suite targeting remote Android.
Tue, Jul 9, 2:39 PM · Restricted Project, Restricted Project
xiaobai accepted D64434: [lldb] Quick Fix: IRExecutionUnit check pointer before access it.
Tue, Jul 9, 12:52 PM · Restricted Project, Restricted Project
xiaobai accepted D64397: [CMake] Remove extra lldb-framework target.

Thanks for cleaning this up!

Tue, Jul 9, 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

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

Mon, Jul 8

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. :)

Mon, Jul 8, 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?

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

ping

Mon, Jul 8, 2:17 PM

Wed, Jul 3

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

Thanks for doing this! :D

Wed, Jul 3, 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

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

Tue, Jul 2

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

Mon, Jul 1

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

Pavel's suggestion

Mon, Jul 1, 3:45 PM · Restricted Project
xiaobai created D64042: [Symbol] Improve Variable::GetLanguage.
Mon, Jul 1, 3:35 PM
xiaobai committed rGd7fcee62f114: [Core] Generalize ValueObject::IsRuntimeSupportValue (authored by xiaobai).
[Core] Generalize ValueObject::IsRuntimeSupportValue
Mon, Jul 1, 1:37 PM
xiaobai committed rL364845: [Core] Generalize ValueObject::IsRuntimeSupportValue.
[Core] Generalize ValueObject::IsRuntimeSupportValue
Mon, Jul 1, 1:36 PM
xiaobai closed D63240: [Core] Generalize ValueObject::IsRuntimeSupportValue.
Mon, Jul 1, 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.

Mon, Jul 1, 11:01 AM · Restricted Project

Thu, Jun 27

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
Thu, Jun 27, 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...

Thu, Jun 27, 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?

Thu, Jun 27, 2:46 PM · Restricted Project

Wed, Jun 26

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.

Wed, Jun 26, 5:13 PM · Restricted Project
xiaobai created D63853: [Symbol] Add DeclVendor::FindTypes.
Wed, Jun 26, 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.

Wed, Jun 26, 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.

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

Tue, Jun 25

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

Address feedback

Tue, Jun 25, 12:35 PM · Restricted Project

Mon, Jun 24

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)...

Mon, Jun 24, 11:47 PM · Restricted Project, Restricted Project