Page MenuHomePhabricator

friss (Frederic Riss)
User

Projects

User does not belong to any projects.

User Details

User Since
Sep 4 2014, 1:00 AM (291 w, 5 d)

Recent Activity

Yesterday

friss updated the diff for D77153: [lldb/DataFormatters] Display null C++ pointers as nullptr.

Remove the now useless code in TypeSummary.cpp, and change the C++
implementation of IsNilReference() to return true soemtimes. This
breaks other tests though...

Mon, Apr 6, 9:16 PM · Restricted Project
friss added a comment to D77153: [lldb/DataFormatters] Display null C++ pointers as nullptr.

This looks like what I'd like to implement, but unfortunately it breaks other tests. Some C tests start printing null pointers as nullptr too. I suppose this is because the expression evaluator is always in C++ mode. Is there a way to get the origin type/language of a variable through a ValueObject?

Mon, Apr 6, 9:16 PM · Restricted Project
friss committed rG06ea05a3fbc6: [lldb/test] Fix TestDSYMSourcePathRemapping in the presence of symlnks (authored by friss).
[lldb/test] Fix TestDSYMSourcePathRemapping in the presence of symlnks
Mon, Apr 6, 8:11 PM
friss updated the diff for D77153: [lldb/DataFormatters] Display null C++ pointers as nullptr.

Implement null C++ printing at the ValueObjectPrinter level

Mon, Apr 6, 8:10 PM · Restricted Project

Wed, Apr 1

friss added a comment to D77153: [lldb/DataFormatters] Display null C++ pointers as nullptr.

I was checking whether there is a way to catch null pointer before a type summary is even chosen. And found out that such logic exists, but only for Objective-C. Languages have a IsNilReference() virtual method that can tell whether a ValueObject is a nil reference. It's only implemented for ObjectiveC and value objects that test positive for this method are displayed as "nil" is the generic code of ValueObjectPrinter.cpp. I can see a few options:

  • I can rework the patch to affect only the libc++ string formatter which was the issue I was trying to solve in the first place
  • I can implement IsNilReference() for C++ and change ValueObjectPrinter to print C++ "nil references" as "nullptr".
  • I do the above and add another customization point in the Language plugins which tells ValueObjectPrinter out to display "nil" references, so that there's no Language specific code in ValueObjectPrinter.
Wed, Apr 1, 3:45 PM · Restricted Project
friss added a comment to D77153: [lldb/DataFormatters] Display null C++ pointers as nullptr.

It might be worth mentioning though that the title of the patch is somewhat misleading -- I believe the CXX in CXXFunctionSummaryFormat refers to the language the formatter is implemented in, not the language of the type itself. So this patch affects all types whose formatters are implemented as c++ functions, not all c++ pointers in the target program.

Wed, Apr 1, 3:12 PM · Restricted Project

Tue, Mar 31

friss created D77153: [lldb/DataFormatters] Display null C++ pointers as nullptr.
Tue, Mar 31, 10:52 AM · Restricted Project
friss added a comment to D77153: [lldb/DataFormatters] Display null C++ pointers as nullptr.

I haven't tested the libstdc++ part, would be great if someone could confirm this works.

Tue, Mar 31, 10:52 AM · Restricted Project
friss accepted D77123: [lldb] Inherit host environment when running shell commands.

I agree host shell command should run with the host environment.

Tue, Mar 31, 8:16 AM · Restricted Project

Fri, Mar 27

friss added a comment to D76955: [lldb/Test] Decode stdout and stderr in case it contains UTF-8.

I think this won't work with Python3, were out and err will be already "decoded" str objects

Fri, Mar 27, 4:00 PM

Thu, Mar 26

friss added a comment to D76835: [lldb] Fix TestSettings.test_pass_host_env_vars on windows.

Thanks for fixing this Pavel!

Thu, Mar 26, 9:11 AM · Restricted Project

Mon, Mar 23

friss committed rGb6ae8937e031: [lldb/PlatformDarwin] Always delete destination file first in PutFile (authored by friss).
[lldb/PlatformDarwin] Always delete destination file first in PutFile
Mon, Mar 23, 2:44 PM
friss closed D76450: [lldb/PlatformDarwin] Always delete destination file first in PutFile.
Mon, Mar 23, 2:44 PM · Restricted Project
friss committed rG7e10581e8c15: [lldb/testsuite] Skip part of TestSettings.py on windows (authored by friss).
[lldb/testsuite] Skip part of TestSettings.py on windows
Mon, Mar 23, 9:17 AM
friss committed rGb4a6e63ea123: [lldb/Target] Rework the way the inferior environment is created (authored by friss).
[lldb/Target] Rework the way the inferior environment is created
Mon, Mar 23, 8:10 AM
friss closed D76470: [lldb/Target] Rework the way the inferior environment is created.
Mon, Mar 23, 8:09 AM · Restricted Project
friss committed rGcd7b45057ca9: [lldb/API] Make Launch(Simple) use args and env from target properties (authored by friss).
[lldb/API] Make Launch(Simple) use args and env from target properties
Mon, Mar 23, 8:09 AM
friss committed rG9228a9efc6c5: [lldb/Target] Initialize new targets environment variables from target.env-vars (authored by friss).
[lldb/Target] Initialize new targets environment variables from target.env-vars
Mon, Mar 23, 8:09 AM
friss closed D76045: [lldb/API] Make Launch(Simple) use args and env from target properties.
Mon, Mar 23, 8:09 AM · Restricted Project
friss closed D76009: [lldb/Target] Initialize new targets environment variables from target.env-vars.
Mon, Mar 23, 8:09 AM · Restricted Project

Fri, Mar 20

friss updated the diff for D76470: [lldb/Target] Rework the way the inferior environment is created.

Simplify command definition

Fri, Mar 20, 6:59 PM · Restricted Project
friss added a comment to D76470: [lldb/Target] Rework the way the inferior environment is created.

Is there any command-based way to see the entire environment that a process will get when it launches? By populating target.env-vars with the inherited environment there was a way to mostly do that, but I don't see that anymore. It seems a shame not to be able to see that...

No, there is no way to do this, but it's not really a regression. If you do settings show target.env-vars today before running then you won't see what is going to be passed. Only after the first run will it be populated. This was a surprise to me and I find it highly inconsistent. Maybe I can add another property that would get updated with the computed environment. Do we have anything like read-only properties?

No, but I don't think I'd do this with a property anyway. You are asking the target to compute the result of the various settings that affect the environment of a process it might launch. That sounds more like the result of a command ("target show-environment" or something like that.) If we knew how to get the environment from a running process, the same command could show the current environment in a running process, which would sometimes be handy.

I agree the behavior before was pretty unhelpful, so I don't think you need to add a new command to access this in this change set. But we should put it on our list of things to do.

Fri, Mar 20, 4:18 PM · Restricted Project
friss updated the diff for D76470: [lldb/Target] Rework the way the inferior environment is created.

Add a new target command to dump the launch environment
Make env-vars override unset-env-vars

Fri, Mar 20, 4:18 PM · Restricted Project
friss added a comment to D76470: [lldb/Target] Rework the way the inferior environment is created.

Is there any command-based way to see the entire environment that a process will get when it launches? By populating target.env-vars with the inherited environment there was a way to mostly do that, but I don't see that anymore. It seems a shame not to be able to see that...

Fri, Mar 20, 11:23 AM · Restricted Project
friss updated the diff for D76009: [lldb/Target] Initialize new targets environment variables from target.env-vars.

Make helper function name more descriptive.

Fri, Mar 20, 9:44 AM · Restricted Project
friss added a comment to D76470: [lldb/Target] Rework the way the inferior environment is created.

I think this is a good change, and is in line with what we have discussed previously. I have just one question about the exact variable interactions here.

Since the raison d'être of the new setting is to be able to "un-inherit" a particular environment variable, I'm wondering if it should only take effect if inherit-env is true (as otherwise you can achieve the same effect by deleting stuff from env-vars)? So instead of the current flow, the sequence would be:

Fri, Mar 20, 9:44 AM · Restricted Project
friss updated the diff for D76470: [lldb/Target] Rework the way the inferior environment is created.

Add tests and update m_launch_info when undet-vars change.
Improve docs.

Fri, Mar 20, 9:44 AM · Restricted Project

Thu, Mar 19

friss created D76470: [lldb/Target] Rework the way the inferior environment is created.
Thu, Mar 19, 6:39 PM · Restricted Project
friss added a comment to D76470: [lldb/Target] Rework the way the inferior environment is created.

This needs some tests, but I wanted to put it out there for comments.

Thu, Mar 19, 6:39 PM · Restricted Project
friss created D76450: [lldb/PlatformDarwin] Always delete destination file first in PutFile.
Thu, Mar 19, 1:42 PM · Restricted Project
friss committed rG76a5451a524c: [lldb/testsuite] un-XFail TestInlineStepping.py on linux and windows (authored by friss).
[lldb/testsuite] un-XFail TestInlineStepping.py on linux and windows
Thu, Mar 19, 9:48 AM
friss committed rGecc6c426977f: [lldb/testsuite] Fix TestInlineStepping on arm64 with newer compilers (authored by friss).
[lldb/testsuite] Fix TestInlineStepping on arm64 with newer compilers
Thu, Mar 19, 8:38 AM
friss committed rG8758d02074be: [lldb/testsuite] Skip part of TestProcessCrashInfo.py on Darwin embedded (authored by friss).
[lldb/testsuite] Skip part of TestProcessCrashInfo.py on Darwin embedded
Thu, Mar 19, 8:38 AM
friss committed rGe154cbb124a6: [lldb/testsuite] XFail TestBuiltinTrap.py not only on linux (authored by friss).
[lldb/testsuite] XFail TestBuiltinTrap.py not only on linux
Thu, Mar 19, 8:38 AM
friss closed D76406: [lldb/testsuite] Fix TestInlineStepping on arm64 with newer compilers.
Thu, Mar 19, 8:38 AM · Restricted Project
friss closed D76408: [lldb/testsuite] XFail TestBuiltinTrap.py not only on linux.
Thu, Mar 19, 8:38 AM · Restricted Project
friss abandoned D76407: [lldb/testsuite] Remove "healthy process" test from TestProcessCrashInfo.py.

I skipped the test for embedded in 8758d02074be7b80b804fad19e8b7de6ebd43c31. I'll abandon this for now

Thu, Mar 19, 8:37 AM · Restricted Project
friss added a comment to D76407: [lldb/testsuite] Remove "healthy process" test from TestProcessCrashInfo.py.

Could the inferior manually wipe the crash annotation?

Thu, Mar 19, 7:31 AM · Restricted Project

Wed, Mar 18

friss created D76408: [lldb/testsuite] XFail TestBuiltinTrap.py not only on linux.
Wed, Mar 18, 9:42 PM · Restricted Project
friss created D76407: [lldb/testsuite] Remove "healthy process" test from TestProcessCrashInfo.py.
Wed, Mar 18, 9:42 PM · Restricted Project
friss created D76406: [lldb/testsuite] Fix TestInlineStepping on arm64 with newer compilers.
Wed, Mar 18, 9:10 PM · Restricted Project
friss committed rGacd641c19d68: [lldb/testsuite] Slightly rework TestHiddenIvars.py (authored by friss).
[lldb/testsuite] Slightly rework TestHiddenIvars.py
Wed, Mar 18, 9:09 PM
friss committed rG59918d3793a1: [lldb/testsuite] Make TestObjCIvarStripped.py working with codesigning (authored by friss).
[lldb/testsuite] Make TestObjCIvarStripped.py working with codesigning
Wed, Mar 18, 9:09 PM
friss committed rG71db787c4583: [lldb/testsuite] Rewrite TestThreadLocal.py (authored by friss).
[lldb/testsuite] Rewrite TestThreadLocal.py
Wed, Mar 18, 9:09 PM
friss committed rG127b9d9d774d: [lldb/testsuite] Apply @skipIfDarwinEmbedded to part of TestHWBreakMultiThread (authored by friss).
[lldb/testsuite] Apply @skipIfDarwinEmbedded to part of TestHWBreakMultiThread
Wed, Mar 18, 9:09 PM
friss committed rG52b2bae777f2: [lldb/testsuite] Skip TestEmptyStdModule.py if using a remote platform (authored by friss).
[lldb/testsuite] Skip TestEmptyStdModule.py if using a remote platform
Wed, Mar 18, 9:09 PM
friss committed rGc182be211a4d: [lldb/testsuite] Tweak TestBreakpointLocations.py to pass for arm64 (authored by friss).
[lldb/testsuite] Tweak TestBreakpointLocations.py to pass for arm64
Wed, Mar 18, 9:09 PM
friss committed rGb40ee7ff1b16: [lldb/MemoryHistoryAsan] Fix address resolution for recorded backtraces (authored by friss).
[lldb/MemoryHistoryAsan] Fix address resolution for recorded backtraces
Wed, Mar 18, 1:35 PM
friss closed D76341: [lldb/MemoryHistoryAsan] Fix address resolution for recorded backtraces.
Wed, Mar 18, 1:35 PM · Restricted Project

Tue, Mar 17

friss created D76341: [lldb/MemoryHistoryAsan] Fix address resolution for recorded backtraces.
Tue, Mar 17, 8:32 PM · Restricted Project

Sun, Mar 15

friss added inline comments to D76188: [lldb/Target] Support more than 2 symbols in StackFrameRecognizer.
Sun, Mar 15, 10:10 AM · Restricted Project

Sat, Mar 14

friss added inline comments to D76188: [lldb/Target] Support more than 2 symbols in StackFrameRecognizer.
Sat, Mar 14, 8:26 PM · Restricted Project

Thu, Mar 12

friss added a comment to D76105: [lldb/settings] Reset the inferior environment when target.inherit-env is toggled.

If I'm following the logic correctly, if you run a target with inherit-env off, and then do:

env VAR_IN_ENVIRONMENT=NOT_THE_ENVIRONMENTS_VALUE

then turn inherit-env on, we will preserve the value you set it to, not the environment value, because you pass in false for can_replace. That seems right to me. It would be good to test that case explicitly, however.

But if you have inherit-env on and then run the command above, and then turn inherit-env off, your changed value will just get deleted. That seems unexpected. I think you have to compare the values in the else branch and only delete the key if the value is the same as the environment value. Does that sound right?

Thu, Mar 12, 5:23 PM · Restricted Project
friss added a comment to D76045: [lldb/API] Make Launch(Simple) use args and env from target properties.

This is somewhat useless without D76009 because the default LaunchInfo doesn't get populated with the environment without it. I'll wait for a resolution there before landing this.

Thu, Mar 12, 4:18 PM · Restricted Project
friss created D76105: [lldb/settings] Reset the inferior environment when target.inherit-env is toggled.
Thu, Mar 12, 3:45 PM · Restricted Project
friss added a comment to D76009: [lldb/Target] Initialize new targets environment variables from target.env-vars.

I put up a "fix" for the inherit-env issue mentioned here: https://reviews.llvm.org/D76105
It is mostly orthogonal to this patch as Jim showed the behavior today is already broken.

Thu, Mar 12, 3:45 PM · Restricted Project
friss added a comment to D76009: [lldb/Target] Initialize new targets environment variables from target.env-vars.

Actually, hang on.

One existing test had to be modified, because the initialization of
the environment properties now take place at the time the target is
created, not at the first use of the environment (usually launch
time).

Thu, Mar 12, 8:40 AM · Restricted Project

Wed, Mar 11

friss added a parent revision for D76045: [lldb/API] Make Launch(Simple) use args and env from target properties: D76009: [lldb/Target] Initialize new targets environment variables from target.env-vars.
Wed, Mar 11, 10:33 PM · Restricted Project
friss added a child revision for D76009: [lldb/Target] Initialize new targets environment variables from target.env-vars: D76045: [lldb/API] Make Launch(Simple) use args and env from target properties.
Wed, Mar 11, 10:33 PM · Restricted Project
friss removed a reviewer for D76045: [lldb/API] Make Launch(Simple) use args and env from target properties: Restricted Project.
Wed, Mar 11, 10:33 PM · Restricted Project
friss updated the diff for D76045: [lldb/API] Make Launch(Simple) use args and env from target properties.

Remove unrelated change commited by accident

Wed, Mar 11, 10:33 PM · Restricted Project
friss created D76045: [lldb/API] Make Launch(Simple) use args and env from target properties.
Wed, Mar 11, 10:33 PM · Restricted Project
friss created D76009: [lldb/Target] Initialize new targets environment variables from target.env-vars.
Wed, Mar 11, 10:45 AM · Restricted Project

Mar 5 2020

friss added inline comments to D75696: Correctly detect iOS simulator processes..
Mar 5 2020, 6:03 PM · Restricted Project

Mar 2 2020

friss committed rG138c7ac5b60f: [lldb/GDBRemote] Fix obvious typo in error message. (authored by friss).
[lldb/GDBRemote] Fix obvious typo in error message.
Mar 2 2020, 6:04 PM
friss committed rG20ce8affce85: [lldb/API] NFC: Reformat and simplify SBThread::GetStopDescription() (authored by friss).
[lldb/API] NFC: Reformat and simplify SBThread::GetStopDescription()
Mar 2 2020, 5:48 PM
friss closed D74157: [lldb/API] NFC: Reformat SBThread::GetStopDescription().
Mar 2 2020, 5:48 PM · Restricted Project

Feb 26 2020

friss accepted D75196: [dsymutil] Avoid copying swiftinterfaces from the SDK into the dsym bundle.

LGTM

Feb 26 2020, 11:04 AM · Restricted Project

Feb 7 2020

friss added inline comments to D74187: [lldb] Add method Language::IsMangledName.
Feb 7 2020, 5:53 PM · Restricted Project
friss added a comment to D74157: [lldb/API] NFC: Reformat SBThread::GetStopDescription().

I think we're on the same page then.

Feb 7 2020, 11:03 AM · Restricted Project
friss updated the diff for D74157: [lldb/API] NFC: Reformat SBThread::GetStopDescription().

Remove the fallback code and assert that StopInfo returns a non-empty string.

Feb 7 2020, 11:03 AM · Restricted Project
friss accepted D74212: [lldb/Target] Fix `frame recognizer list` crash when registered with nullptr.

LGTM

Feb 7 2020, 8:18 AM · Restricted Project

Feb 6 2020

friss added a comment to D74157: [lldb/API] NFC: Reformat SBThread::GetStopDescription().

Looks better. TBH, I'm not sure why/if we really need the case handling the situation where the thread does not have a stop description. Ideally I'd just move this code there (or delete it).

A thread that stops for no reason will have an empty StopInfoSP. So somebody has to check for that. I also don't want a thread that hasn't stopped for a reason to have a placeholder description like "no reason" because if you are using the API's you'd like to just print whatever the description is, and if you stop one thread at a breakpoint, having all the others say "no reason" is noisy and unhelpful.

Feb 6 2020, 8:15 PM · Restricted Project
friss added inline comments to D74187: [lldb] Add method Language::IsMangledName.
Feb 6 2020, 5:38 PM · Restricted Project
friss created D74157: [lldb/API] NFC: Reformat SBThread::GetStopDescription().
Feb 6 2020, 1:01 PM · Restricted Project

Feb 5 2020

friss added inline comments to D74096: [lldb/API] Fix the dangling pointer issue in SBThread::GetStopDescription.
Feb 5 2020, 3:51 PM · Restricted Project
friss added inline comments to D73303: [lldb/Target] Add Assert StackFrame Recognizer.
Feb 5 2020, 1:21 PM · Restricted Project

Jan 28 2020

friss added a comment to D73303: [lldb/Target] Add Assert StackFrame Recognizer.

This generally looks good. I'm still not fond of registering this in the Target itself. But I don't have a immediately better idea as we don't have a C language runtime.

Jan 28 2020, 10:58 AM · Restricted Project

Jan 24 2020

friss added inline comments to D73303: [lldb/Target] Add Assert StackFrame Recognizer.
Jan 24 2020, 11:12 AM · Restricted Project
friss added inline comments to D73303: [lldb/Target] Add Assert StackFrame Recognizer.
Jan 24 2020, 8:31 AM · Restricted Project

Jan 23 2020

friss added inline comments to D73303: [lldb/Target] Add Assert StackFrame Recognizer.
Jan 23 2020, 9:35 PM · Restricted Project
friss added inline comments to D73225: Handle the new objc direct dispatch accelerator functions for uncommonly overridden methods.
Jan 23 2020, 12:57 PM · Restricted Project

Jan 21 2020

friss committed rG0478eadf73c1: [lldb/DataFormatters] Fix the `$$deference$$` synthetic child (authored by friss).
[lldb/DataFormatters] Fix the `$$deference$$` synthetic child
Jan 21 2020, 1:38 PM
friss closed D73053: [lldb/DataFormatters] Fix the `$$deference$$` synthetic child.
Jan 21 2020, 1:37 PM · Restricted Project

Jan 20 2020

friss updated the diff for D73053: [lldb/DataFormatters] Fix the `$$deference$$` synthetic child.

use python formatting in docs

Jan 20 2020, 12:08 PM · Restricted Project
friss created D73053: [lldb/DataFormatters] Fix the `$$deference$$` synthetic child.
Jan 20 2020, 8:52 AM · Restricted Project

Jan 17 2020

friss committed rG546f8f426463: [lldb/testsuite] Modernize 2 test Makefiles (authored by friss).
[lldb/testsuite] Modernize 2 test Makefiles
Jan 17 2020, 9:07 PM
friss committed rG509b78883d4f: [lldb/Makefile.rules] Force the default target to be 'all' (authored by friss).
[lldb/Makefile.rules] Force the default target to be 'all'
Jan 17 2020, 9:07 PM

Jan 3 2020

friss accepted D72096: [lldb/Command] Add --force option for `watchpoint delete` command.
Jan 3 2020, 9:27 AM · Restricted Project

Jan 2 2020

friss added inline comments to D72096: [lldb/Command] Add --force option for `watchpoint delete` command.
Jan 2 2020, 11:08 AM · Restricted Project

Dec 17 2019

friss added a comment to D69309: Support template instantiation in the expression evaluator.

Basically, today the debug info will describe an entity named "Foo<int>". The accelerator tables all reference this name. So when Clang asks us if we know "Foo" (which is what happens when instantiating), we fail to find the right instantiations. The consensus of the above discussion was that we should change the debug info to have "Foo" as the name of any instantiation, with a child DIE describing the template arguments. Just doing this in the compiler causes test failures in LLDB, so there's some work to do in LLDB to support this.

Frederic, you say that "doing this in the compiler causes test failures in LLDB", which implies you have tried adding the template in the compiler. Do you have that compiler patch lying around so that we could have a look at what can be done on the lldb side?

I agree that a good long term fix is to have "Foo" as an entity in DWARF, although for backwards compatibility it might be better if the "Foo" template just contained references to the instantiations rather than having them as children.

I am afraid you're overestimating the scope of that idea. I *think* that Fred was referring to simply changing the string that gets put into the DW_AT_name field of the /instantation/ (and, by extension, the accelerator table). The debug info would still describe instantiations only.

Dec 17 2019, 8:03 AM · Restricted Project

Nov 21 2019

friss added a comment to D69309: Support template instantiation in the expression evaluator.

Sorry that I haven't reviewed the patch, but there's something I'd like to point out before anyone invests a lot of time into plugin holes in our current template support code.

It would be great to fix the way templates are represented, because currently the debug info doesn't allow us to answer Clang's requests correctly. There is the beginning of a discussion here: http://lists.llvm.org/pipermail/lldb-commits/Week-of-Mon-20180507/040689.html

Basically, today the debug info will describe an entity named "Foo<int>". The accelerator tables all reference this name. So when Clang asks us if we know "Foo" (which is what happens when instantiating), we fail to find the right instantiations. The consensus of the above discussion was that we should change the debug info to have "Foo" as the name of any instantiation, with a child DIE describing the template arguments. Just doing this in the compiler causes test failures in LLDB, so there's some work to do in LLDB to support this.

Having an entity for the template itself would be great. However, that would require compiler changes, so only the code compiled with new compilers would benefit, no? I am afraid we need a story for older toolchains, too.

Nov 21 2019, 8:07 AM · Restricted Project

Nov 19 2019

friss added a comment to D69309: Support template instantiation in the expression evaluator.

Sorry that I haven't reviewed the patch, but there's something I'd like to point out before anyone invests a lot of time into plugin holes in our current template support code.

Nov 19 2019, 4:32 PM · Restricted Project

Nov 15 2019

friss committed rGa578adc1bc8e: dotest: Add a way for the run_to_* helpers to register dylibs (authored by friss).
dotest: Add a way for the run_to_* helpers to register dylibs
Nov 15 2019, 3:42 PM
friss closed D70134: dotest: Add a way for the run_to_* helpers to register dylibs.
Nov 15 2019, 3:42 PM · Restricted Project

Nov 12 2019

friss created D70134: dotest: Add a way for the run_to_* helpers to register dylibs.
Nov 12 2019, 10:18 AM · Restricted Project

Nov 7 2019

friss committed rGcbdd92be8a57: Modernize TestWeakSymbols Makefile (authored by friss).
Modernize TestWeakSymbols Makefile
Nov 7 2019, 2:55 PM

Nov 6 2019

friss committed rG8243918f43c6: Testuite: Support Asan test with remote testing (authored by friss).
Testuite: Support Asan test with remote testing
Nov 6 2019, 2:31 PM
friss added inline comments to D69913: Re-enable std::function formatter with fixes to improve non-cached lookup performance.
Nov 6 2019, 2:29 PM · Restricted Project
friss added inline comments to D69913: Re-enable std::function formatter with fixes to improve non-cached lookup performance.
Nov 6 2019, 12:31 PM · Restricted Project