Page MenuHomePhabricator

ddcc (Dominic Chen)
User

Projects

User does not belong to any projects.

User Details

User Since
Jun 17 2016, 7:04 PM (156 w, 1 d)

Recent Activity

Mar 25 2019

ddcc accepted D59796: New methods to check for under-/overflow in the SMT API.
Mar 25 2019, 9:26 PM · Restricted Project

Mar 23 2019

ddcc added a comment to D54978: Move the SMT API to LLVM.

To fix that, I changed the script slightly: we first try to dinamically get the Z3's version, if we fail and we are cross compiling, then we try to parse the headers. Right now, it should just work but I'd like to add a message to warn the user that we found the lib but we don't know if it'll link.

Mar 23 2019, 12:52 AM · Restricted Project, Restricted Project

Mar 18 2019

ddcc added inline comments to D54978: Move the SMT API to LLVM.
Mar 18 2019, 1:11 PM · Restricted Project, Restricted Project

Mar 16 2019

ddcc added a comment to D54978: Move the SMT API to LLVM.

Would one of you be able to file a bug against Z3 to fix this? I am no longer in a position to contribute to Z3 so I can't do this.

Mar 16 2019, 11:34 AM · Restricted Project, Restricted Project
ddcc added a comment to D54978: Move the SMT API to LLVM.
  1. Instead of parsing Z3_FULL_VERSION, we can parse Z3_MAJOR_VERSION, Z3_MINOR_VERSION and Z3_BUILD_NUMBER which are also available in the same header.
Mar 16 2019, 2:23 AM · Restricted Project, Restricted Project

Mar 15 2019

ddcc added a comment to D54978: Move the SMT API to LLVM.

The only relevant commit that I can find is https://github.com/Z3Prover/z3/commit/2cb4223979cc94e2ebc4e49a9e83adbdcd2b6979 , but it first landed in z3 4.6.0. It looks like it's specific to CMake though, so is it different if you use the python build? I haven't tried the CMake build.

Mar 15 2019, 7:40 PM · Restricted Project, Restricted Project
ddcc added a comment to D54978: Move the SMT API to LLVM.

Sorry for the massive delay, but I just updated the FindZ3 script to retrieve the version from the lib. I changed it to use try_run instead of try_compile so we can get the version number.

I tried to use @brzycki code to get the version from the header, however, it's not working for Z3 4.8.4. In Z3 4.8.3 the FULL_VERSION is a nice "Z3 4.8.3.0" but in version 4.8.4 it's "Z3 4.8.4.10272 d6df51951f4c master z3-4.8.4" and cmake fails with the following message:

Mar 15 2019, 7:34 PM · Restricted Project, Restricted Project

Feb 13 2019

ddcc added a comment to D54978: Move the SMT API to LLVM.

I just sent the first prototype of the solution. All the magic happens inside the CHECK_CXX_SOURCE_RUNS call.

Feb 13 2019, 3:36 PM · Restricted Project, Restricted Project
ddcc added a comment to D54978: Move the SMT API to LLVM.

That is almost exactly what I was thinking about this morning. I'd prefer the following since it's more robust for older versions:

Feb 13 2019, 12:34 PM · Restricted Project, Restricted Project

Feb 12 2019

ddcc added a comment to D54978: Move the SMT API to LLVM.

This works for everything I could throw at it. If you think it's reasonable I can open another ticket and have the code reviewed as a separate fix.

Feb 12 2019, 8:06 PM · Restricted Project, Restricted Project
ddcc added a comment to D54978: Move the SMT API to LLVM.

I think I found why others are struggling to recreate this issue. I did not have the package z3/bionic installed. This provides the /usr/bin/z3 executable which llvm/cmake/modules/FindZ3.cmake relies upon to determine the correct Z3_VERSION_STRING.

Feb 12 2019, 12:32 PM · Restricted Project, Restricted Project

Feb 11 2019

ddcc updated subscribers of D54978: Move the SMT API to LLVM.

The likely reason for this versioning problem is that the current versioning implementation in FindZ3.cmake is best-effort only: among other conditions, if the z3 binary is available, it will execute it and parse out the version number from standard output, otherwise, it fails silently. This is because upstream Z3 doesn't define the API version in a header file, and uses a homebrew python-based build system that also doesn't export the version. I believe @delcypher 's CMake-based build system for upstream Z3 might solve this problem, but I haven't looked at it in a long time, and it it appears to be stalled ( https://github.com/Z3Prover/z3/issues/986 ).

Feb 11 2019, 12:39 PM · Restricted Project, Restricted Project

Nov 11 2018

ddcc accepted D54391: Fix compatibility with z3-4.8.1.
Nov 11 2018, 1:31 PM · Restricted Project

Aug 20 2018

ddcc added a comment to D50818: [analyzer] Improved cmake configuration for Z3.

@delcypher @ddcc @mikhail.ramalho Actually, I was thinking about another way of configuring Z3 without CMake entirely, and I would like to hear thoughts on how crazy that is.
What if we

  • Remove all CMake checks
  • Define the headers we need in the analyzer
  • When initializing Z3 objects (done when Z3-visitor or Z3-solver is enabled), we would try to open the dylib, check it's version, and fail if the dylib is not found or the version does not match.
Aug 20 2018, 1:53 PM · Restricted Project

Aug 16 2018

ddcc updated subscribers of D50818: [analyzer] Improved cmake configuration for Z3.
Aug 16 2018, 9:43 AM · Restricted Project

Aug 15 2018

ddcc added inline comments to D50818: [analyzer] Improved cmake configuration for Z3.
Aug 15 2018, 7:34 PM · Restricted Project

Jul 13 2018

ddcc accepted D49305: [analyzer] Fix the Z3 backend always generating unsigned APSInt.
Jul 13 2018, 10:23 AM
ddcc added a comment to D49305: [analyzer] Fix the Z3 backend always generating unsigned APSInt.

I recall that this problem extends beyond the Z3ConstraintManager. Have you looked at D28955, specifically the changes to BasicValueFactory.h?

Jul 13 2018, 10:13 AM

Jun 27 2018

ddcc added a comment to D48650: [analyzer] Fix constraint being dropped when analyzing a program without taint tracking enabled.

I don't see any #ifdef for the tests. Do they pass both with and without z3? I recall needing to case out the expected test output before.

Jun 27 2018, 12:56 PM

Jun 20 2018

ddcc added a comment to D48324: [analyzer] Fix wrong comparison generation of the ranges generated by the refutation manager.

Yeah, I think it would be preferable to fix all three bugs here.

Jun 20 2018, 11:09 AM

Jun 19 2018

ddcc added a comment to D48324: [analyzer] Fix wrong comparison generation of the ranges generated by the refutation manager.

I think the correct type should always be ptrdiff_t, regardless of the type of the pointers involved. ASTContext has a method has a getPointerDiffType() so maybe we should you that instead of Ctx.getIntTypeForBitwidth(Ctx.getTypeSize(LTy), true)?

Jun 19 2018, 12:47 PM
ddcc added a comment to D48324: [analyzer] Fix wrong comparison generation of the ranges generated by the refutation manager.

The code already tries to handle ptrdiff_t specially, see the comment right above, but it is only executed if RetTy is non-null. Instead, I think it should be refactored so that e.g. a local isBool is always computed, and this is passed to the final call to Z3Expr::fromBinOp.

Jun 19 2018, 11:45 AM

Jun 16 2018

ddcc accepted D48227: [analyzer] Optimize constraint generation when the range is a concrete value.

LGTM

Jun 16 2018, 11:34 AM

Jun 15 2018

ddcc added a comment to D48227: [analyzer] Optimize constraint generation when the range is a concrete value.

Correct me if I'm wrong, but isn't this function mostly duplicate with assumeSymInclusiveRange? I think it would be preferable to refactor out the constraint generation from both into e.g. getZ3RangeExpr, then modify both addRangeConstraints and assumeSymInclusiveRange to call it instead?

Jun 15 2018, 12:59 PM

Jun 4 2018

ddcc added a comment to D47726: [Analyzer][Z3] Test fixes for Z3 constraint manager.

@ddcc To be completely honest, I see a few design issues with the current implementation of Z3 backend,
the main one being that it checks satisfiability after every single exploded node.
To the best of my knowledge, reasonable scalability would not be achieved with such an approach,
and I'm not sure how feasible would it be to change it without rewriting most of the checkers.

Jun 4 2018, 6:23 PM
ddcc updated subscribers of D47726: [Analyzer][Z3] Test fixes for Z3 constraint manager.
  • Do all tests for Z3 run when LLVM is configured to use Z3? I'm not sure if that's the right thing: do all tests start to take 10x time to run once Z3 is enabled?
Jun 4 2018, 12:53 PM

Jun 1 2018

ddcc added a comment to D47640: Moved RangedConstraintManager header to the StaticAnalyser include dir.

@ddcc any objections?

Jun 1 2018, 1:17 PM
ddcc added a comment to D47617: [Analyzer] Fix Z3ConstraintManager crash (PR37646).

LGTM with a nit on a test name.

Jun 1 2018, 1:09 PM

May 31 2018

ddcc committed rC333704: [analyzer] fix bug with 1-bit APSInt types in Z3ConstraintManager.
[analyzer] fix bug with 1-bit APSInt types in Z3ConstraintManager
May 31 2018, 3:27 PM
ddcc committed rL333704: [analyzer] fix bug with 1-bit APSInt types in Z3ConstraintManager.
[analyzer] fix bug with 1-bit APSInt types in Z3ConstraintManager
May 31 2018, 3:27 PM
ddcc closed D47603: [analyzer] fix bug with 1-bit APSInt types in Z3ConstraintManager.
May 31 2018, 3:27 PM
ddcc updated the summary of D47603: [analyzer] fix bug with 1-bit APSInt types in Z3ConstraintManager.
May 31 2018, 2:15 PM
ddcc updated the diff for D47603: [analyzer] fix bug with 1-bit APSInt types in Z3ConstraintManager.

Add test, address comments

May 31 2018, 2:13 PM
ddcc added a comment to D47603: [analyzer] fix bug with 1-bit APSInt types in Z3ConstraintManager.

Would it be possible to add tests? I know we have very few unit tests, but I assume you could actually use an integration test to exercise this path?

I tested this change and it fixes PR37622. There's a simple crash reproducer included there.

May 31 2018, 1:47 PM
ddcc created D47603: [analyzer] fix bug with 1-bit APSInt types in Z3ConstraintManager.
May 31 2018, 12:55 PM

May 30 2018

ddcc added a comment to D35450: [analyzer] Support generating and reasoning over more symbolic constraint types.

@ddcc Hi, are you still interested in landing the fixes associated with this patch? I can take a look as I'm currently reviewing https://reviews.llvm.org/D45517, but it is likely that the patch would need to be changed substantially before it could land.

May 30 2018, 1:43 PM

May 26 2018

ddcc added a comment to D45517: [analyzer] False positive refutation with Z3.

FYI the fix for the 1-bit APSInt issue is in https://reviews.llvm.org/D35450#change-ifYnQ3IlVso

May 26 2018, 2:10 PM

Sep 1 2017

ddcc added a comment to D28955: [analyzer] Enable support for symbolic extension/truncation.

@NoQ Does the proposal in https://reviews.llvm.org/D28955#652465 satisfy your concern?

Sep 1 2017, 4:02 PM
ddcc added a comment to D28955: [analyzer] Enable support for symbolic extension/truncation.

@dcoughlin No, all three patches are separate. I have been testing them with each applied incrementally onto the previous, in the order trunk, D35450, D28954, then D28955 (this). But since these are a lot of dependencies, I've refactored this patch to apply directly on top of D35450, though the floating-point specific changes will need to be merged into D28954. Also, I think D28954 is waiting for review.

Sep 1 2017, 3:56 PM
ddcc updated the summary of D28955: [analyzer] Enable support for symbolic extension/truncation.
Sep 1 2017, 3:56 PM
ddcc updated the diff for D28955: [analyzer] Enable support for symbolic extension/truncation.

Rebase, factor out floating-point changes, fix Z3 type bug, support general APSInt comparison

Sep 1 2017, 3:56 PM

Aug 31 2017

ddcc updated the summary of D35450: [analyzer] Support generating and reasoning over more symbolic constraint types.
Aug 31 2017, 9:58 PM
ddcc added a comment to D35450: [analyzer] Support generating and reasoning over more symbolic constraint types.

All testcases pass, except the issue with range_casts.c. The cause is still the range intersection discussed in https://reviews.llvm.org/D35450#810469.

Aug 31 2017, 9:35 PM
ddcc updated the diff for D35450: [analyzer] Support generating and reasoning over more symbolic constraint types.

Rebase, make complexity limits configurable

Aug 31 2017, 9:33 PM

Aug 28 2017

ddcc added inline comments to D35450: [analyzer] Support generating and reasoning over more symbolic constraint types.
Aug 28 2017, 10:11 AM

Aug 25 2017

ddcc added inline comments to D35450: [analyzer] Support generating and reasoning over more symbolic constraint types.
Aug 25 2017, 4:28 PM

Aug 18 2017

ddcc committed rL311213: Add release notes for r299463..
Add release notes for r299463.
Aug 18 2017, 5:10 PM

Aug 5 2017

ddcc added a comment to D35450: [analyzer] Support generating and reasoning over more symbolic constraint types.

@NoQ ping

Aug 5 2017, 2:48 PM

Jul 19 2017

ddcc updated the diff for D28954: [analyzer] Add support for symbolic float expressions.

Drop unnecessary code

Jul 19 2017, 6:31 PM
ddcc added a comment to D28954: [analyzer] Add support for symbolic float expressions.

As an aside, I think it'd be good to land D28954 and D28955 first, since they affect accuracy and precision of various analyzer parts that this depends on.

Jul 19 2017, 6:14 PM
ddcc updated the diff for D28954: [analyzer] Add support for symbolic float expressions.

Revise based on feedback

Jul 19 2017, 6:06 PM

Jul 18 2017

ddcc updated the diff for D35450: [analyzer] Support generating and reasoning over more symbolic constraint types.

Minor style fix

Jul 18 2017, 3:19 PM

Jul 17 2017

ddcc added a comment to D35450: [analyzer] Support generating and reasoning over more symbolic constraint types.

As an update, after fixing the typo and updating the tests, the assertion in range_casts.c is no longer triggered and everything seems fine now.

Jul 17 2017, 10:01 AM
ddcc updated the diff for D35450: [analyzer] Support generating and reasoning over more symbolic constraint types.

Fix tests after typo fix

Jul 17 2017, 9:55 AM
ddcc added a comment to D35450: [analyzer] Support generating and reasoning over more symbolic constraint types.

Is diff 1 the original diff from D28953? It was ok to reopen it, but the new revision is also fine.

Jul 17 2017, 8:46 AM
ddcc updated the diff for D35450: [analyzer] Support generating and reasoning over more symbolic constraint types.

Fix typo

Jul 17 2017, 8:46 AM

Jul 15 2017

ddcc added a comment to D35450: [analyzer] Support generating and reasoning over more symbolic constraint types.

Compared with D28953, this revision fixes the test failure with PR3991.m with RangeConstraintManager, and a few other failures with Z3ConstraintManager. However, there's one remaining test failure in range_casts.c that I'm not sure how to resolve. For reference, this is the simplified code snippet from that testcase:

Jul 15 2017, 1:24 AM
ddcc updated the diff for D35450: [analyzer] Support generating and reasoning over more symbolic constraint types.

Modify Z3RangeConstraintManager::fixAPSInt() and add Expr::isCommutativeOp()

Jul 15 2017, 1:21 AM

Jul 14 2017

ddcc created D35450: [analyzer] Support generating and reasoning over more symbolic constraint types.
Jul 14 2017, 11:20 PM

Jul 12 2017

ddcc added a comment to D28953: [analyzer] Eliminate analyzer limitations on symbolic constraint generation.
Jul 12 2017, 2:48 PM
ddcc added a comment to D28953: [analyzer] Eliminate analyzer limitations on symbolic constraint generation.

Reverted in rL307853

Jul 12 2017, 2:48 PM
ddcc committed rL307853: Revert "[analyzer] Support generating and reasoning over more symbolic….
Revert "[analyzer] Support generating and reasoning over more symbolic…
Jul 12 2017, 2:44 PM
ddcc committed rL307833: [analyzer] Support generating and reasoning over more symbolic constraint types.
[analyzer] Support generating and reasoning over more symbolic constraint types
Jul 12 2017, 12:38 PM
ddcc closed D28953: [analyzer] Eliminate analyzer limitations on symbolic constraint generation by committing rL307833: [analyzer] Support generating and reasoning over more symbolic constraint types.
Jul 12 2017, 12:38 PM

Jul 11 2017

ddcc updated the diff for D28953: [analyzer] Eliminate analyzer limitations on symbolic constraint generation.

Split plist-macros.cpp, and update analyzer_test.py to support tests that require not z3

Jul 11 2017, 12:46 PM

Jul 10 2017

ddcc added a comment to D28953: [analyzer] Eliminate analyzer limitations on symbolic constraint generation.

I've also uploaded the results to https://dcddcc.com/csa

Jul 10 2017, 1:45 PM
ddcc added a comment to D28953: [analyzer] Eliminate analyzer limitations on symbolic constraint generation.

I tested the following software, both before and after applying this patch, using RangeConstraintManager.

Jul 10 2017, 1:31 PM
ddcc updated the diff for D28953: [analyzer] Eliminate analyzer limitations on symbolic constraint generation.

Drop duplicate code

Jul 10 2017, 1:31 PM

Jul 5 2017

ddcc added a comment to D28953: [analyzer] Eliminate analyzer limitations on symbolic constraint generation.

ping

Jul 5 2017, 3:06 PM

Jun 20 2017

ddcc added a comment to D28953: [analyzer] Eliminate analyzer limitations on symbolic constraint generation.

I forgot to mention that the only remaining (Z3) test failure is on plist-macros.cpp; there is a Assuming condition is true path note that only appears with the RangeConstraintManager but not with Z3ConstraintManager, and I can't #ifdef it because the annotations are checked by FileCheck.

Jun 20 2017, 11:12 AM
ddcc updated the diff for D28953: [analyzer] Eliminate analyzer limitations on symbolic constraint generation.

Rebase, decrease simplification complexity

Jun 20 2017, 11:09 AM
ddcc added a comment to D28953: [analyzer] Eliminate analyzer limitations on symbolic constraint generation.

Can we drop computing these for some expressions that we know the RangeConstraintManager will not utilize?

Jun 20 2017, 11:08 AM

Jun 15 2017

ddcc added inline comments to D28953: [analyzer] Eliminate analyzer limitations on symbolic constraint generation.
Jun 15 2017, 5:09 PM
ddcc committed rL305480: [analyzer]: Improve test handling with multiple constraint managers.
[analyzer]: Improve test handling with multiple constraint managers
Jun 15 2017, 10:05 AM
ddcc closed D33308: [analyzer]: Improve test handling with multiple constraint managers by committing rL305480: [analyzer]: Improve test handling with multiple constraint managers.
Jun 15 2017, 10:05 AM

Jun 10 2017

ddcc added a comment to D33308: [analyzer]: Improve test handling with multiple constraint managers.

@dcoughlin @zaks.anna @NoQ @xazax.hun Ping, I'd appreciate it if I could get a review for this (D33308), D28955, D28953, and D28954. Rebasing and fixing up these commits is fairly time consuming.

Jun 10 2017, 9:39 PM

May 18 2017

ddcc updated the diff for D28954: [analyzer] Add support for symbolic float expressions.

Rebase, avoid generating floating-point constraints if unsupported by constraint manager

May 18 2017, 10:37 PM
ddcc updated the diff for D28953: [analyzer] Eliminate analyzer limitations on symbolic constraint generation.

Fix typo in SymbolCast simplification

May 18 2017, 10:36 PM

May 17 2017

ddcc created D33308: [analyzer]: Improve test handling with multiple constraint managers.
May 17 2017, 10:27 PM
ddcc added a comment to D28953: [analyzer] Eliminate analyzer limitations on symbolic constraint generation.

I've updated this revision to account for the recent SVal simplification commit by @NoQ, but now there is an exponential blowup problem that prevents testcase PR24184.cpp from terminating, due to an interaction between Simplifier::VisitNonLocSymbolVal() and SValBuilder::makeSymExprValNN() when expanding the loop in case 3. I'm not quite sure what the best way to resolve this is; from some blind testing, I ended up needing to set MaxComp to 10 to force termination in a reasonable amount of time, but this restricts its usefulness for generating other symbolic constraints.

May 17 2017, 10:18 PM
ddcc updated the diff for D28953: [analyzer] Eliminate analyzer limitations on symbolic constraint generation.

Address SVal simplification from D31886

May 17 2017, 10:10 PM
ddcc added a comment to D28952: [analyzer] Add new Z3 constraint manager backend.
In D28952#757375, @iris wrote:

Thank you for helping me build clang with z3.I have already applied the above updating.But now I have another question, when running clang with '-Xanalyzer -analyzer-constraints=z3' there is always be a fatal error and I don't know whether it is right to use a command like 'clang -Xanalyzer -analyzer-constraints=z3 -analyzer-checker=debug.DumpExplodedGraph test.cpp-' to get the ExplodedGraph which is analyzed by z3constraint?Sorry to bother.

May 17 2017, 2:12 PM

May 14 2017

ddcc added a comment to D28954: [analyzer] Add support for symbolic float expressions.
In D28954#714936, @ddcc wrote:

Rebase, update tests, fix bugs

Excuse me,I want to download full codes of this version,but I have no idea how to do it,can you tell me?
And my system is windows, I haven't install anything about Phabricator.
Thank you!

May 14 2017, 8:21 PM

May 10 2017

ddcc updated the diff for D28953: [analyzer] Eliminate analyzer limitations on symbolic constraint generation.

Rebase

May 10 2017, 3:34 PM
ddcc added a comment to D28953: [analyzer] Eliminate analyzer limitations on symbolic constraint generation.

It's been a while since I looked at the code, but I don't believe that all of the new constraints are necessarily unsupported by the current range constraint manager. Rather, they were just not being generated by the SimpleSValBuilder. The changes pass the testsuite for both the Range and Z3 constraint managers, without any special testcase handling that is Z3 specific.

May 10 2017, 3:26 PM
ddcc added a comment to D28952: [analyzer] Add new Z3 constraint manager backend.
In D28952#750558, @iris wrote:

How can I make z3constraintmanager.cpp work in the command line?Or how to make z3 work?

May 10 2017, 1:28 PM

May 5 2017

ddcc added a comment to D28955: [analyzer] Enable support for symbolic extension/truncation.

@dcoughlin : ping

May 5 2017, 8:30 PM

Apr 6 2017

ddcc accepted D31756: [cmake] Support Gentoo install for z3.

Thanks!

Apr 6 2017, 9:49 AM

Apr 4 2017

ddcc committed rL299463: [analyzer] Add new Z3 constraint manager backend.
[analyzer] Add new Z3 constraint manager backend
Apr 4 2017, 1:05 PM
ddcc closed D28952: [analyzer] Add new Z3 constraint manager backend by committing rL299463: [analyzer] Add new Z3 constraint manager backend.
Apr 4 2017, 1:05 PM

Apr 3 2017

ddcc updated the diff for D28952: [analyzer] Add new Z3 constraint manager backend.

Fix support for 128-bit APInt creation, drop pkg-config from CMake module

Apr 3 2017, 4:43 PM

Mar 31 2017

ddcc added inline comments to D28952: [analyzer] Add new Z3 constraint manager backend.
Mar 31 2017, 10:15 AM

Mar 30 2017

ddcc updated the diff for D28955: [analyzer] Enable support for symbolic extension/truncation.

Rebase

Mar 30 2017, 10:38 PM
ddcc updated the diff for D28954: [analyzer] Add support for symbolic float expressions.

Rebase, update tests, fix bugs

Mar 30 2017, 10:37 PM
ddcc updated the diff for D28953: [analyzer] Eliminate analyzer limitations on symbolic constraint generation.

Rebase

Mar 30 2017, 10:37 PM
ddcc updated the diff for D28952: [analyzer] Add new Z3 constraint manager backend.

Fix erroneous comment

Mar 30 2017, 10:34 PM
ddcc added a comment to D28952: [analyzer] Add new Z3 constraint manager backend.

Thanks for the feedback! My main constraint is that the results from the floating-point analysis weren't very interesting (see #652894), so I'm not actively working on further development.

Mar 30 2017, 10:31 PM
ddcc updated the diff for D28952: [analyzer] Add new Z3 constraint manager backend.

Use direct bitcasting instead of string conversion for APFloat casting, add reference counting for Z3_sort, eliminate some duplicate code

Mar 30 2017, 10:31 PM

Mar 21 2017

ddcc added inline comments to D28952: [analyzer] Add new Z3 constraint manager backend.
Mar 21 2017, 1:04 PM

Mar 6 2017

ddcc added a comment to D28952: [analyzer] Add new Z3 constraint manager backend.

Thanks for your help! Let me know when the buildbot is ready for this to land.

Mar 6 2017, 8:42 PM