Page MenuHomePhabricator

kristina (Kristina Brooks)
Bikeshed Expert

Projects

User does not belong to any projects.

User Details

User Since
Apr 8 2018, 2:18 PM (57 w, 6 d)

Maintainer of an LLVM backend fork for Broadcom VideoCore4, never went upstream as Julian's GCC port turned out to work a lot better and did not require a separate assembler/linker. Expert on Darwin kernel, Mach-O file format, dynamic linking infrastructure on Darwin (dyld, shared caches, codesigning).

Personal GitHub Account: https://github.com/christinaa
Personal Blog: http://crna.cc/
Use notstina (at) gmail (dot) com if you need to email me.

Not representing any organization.

Recent Activity

Thu, May 16

kristina committed rG5652063eff60: [Clang][Docs] Document __FILE_NAME__. NFC (authored by kristina).
[Clang][Docs] Document __FILE_NAME__. NFC
Thu, May 16, 11:45 PM
kristina added 2 commit(s) for D61756: Add a __FILE_NAME__ macro.: rC360994: [Clang][Docs] Document __FILE_NAME__. NFC, rL360994: [Clang][Docs] Document __FILE_NAME__. NFC.
Thu, May 16, 11:45 PM · Restricted Project
kristina added an edge to rC360994: [Clang][Docs] Document __FILE_NAME__. NFC: D61756: Add a __FILE_NAME__ macro..
Thu, May 16, 11:45 PM
kristina added an edge to rL360994: [Clang][Docs] Document __FILE_NAME__. NFC: D61756: Add a __FILE_NAME__ macro..
Thu, May 16, 11:45 PM
kristina committed rL360994: [Clang][Docs] Document __FILE_NAME__. NFC.
[Clang][Docs] Document __FILE_NAME__. NFC
Thu, May 16, 11:44 PM
kristina committed rC360994: [Clang][Docs] Document __FILE_NAME__. NFC.
[Clang][Docs] Document __FILE_NAME__. NFC
Thu, May 16, 11:44 PM
kristina added a comment to D54742: [CodeMetrics] Don't let extends of i1 be free..

My bad, I didn't check well enough, it seems an unrelated patch made certain tests crash due to asserts. Thanks to @craig.topper for pointing that out.

Thu, May 16, 10:54 PM
kristina added a comment to D54742: [CodeMetrics] Don't let extends of i1 be free..

This seems to be causing multiple performance regressions across several bots in compile time and execution time tests.

Thu, May 16, 8:56 PM
kristina added 1 commit(s) for D54742: [CodeMetrics] Don't let extends of i1 be free.: rL360970: [CodeMetrics] Don't let extends of i1 be free..
Thu, May 16, 8:49 PM
kristina added an edge to rL360970: [CodeMetrics] Don't let extends of i1 be free.: D54742: [CodeMetrics] Don't let extends of i1 be free..
Thu, May 16, 8:49 PM
kristina committed rGbd9748424165: Reland "[Clang][PP] Add the __FILE_NAME__ builtin macro" (authored by kristina).
Reland "[Clang][PP] Add the __FILE_NAME__ builtin macro"
Thu, May 16, 2:12 PM
kristina committed rL360938: Reland "[Clang][PP] Add the __FILE_NAME__ builtin macro".
Reland "[Clang][PP] Add the __FILE_NAME__ builtin macro"
Thu, May 16, 2:11 PM
kristina committed rC360938: Reland "[Clang][PP] Add the __FILE_NAME__ builtin macro".
Reland "[Clang][PP] Add the __FILE_NAME__ builtin macro"
Thu, May 16, 2:11 PM
kristina closed D61756: Add a __FILE_NAME__ macro..
Thu, May 16, 2:11 PM · Restricted Project
kristina updated the diff for D61756: Add a __FILE_NAME__ macro..

Revised to use llvm::sys::path::filename to avoid issues on Windows hosts.

Thu, May 16, 12:28 PM · Restricted Project

Wed, May 15

kristina reopened D61756: Add a __FILE_NAME__ macro..

Reverted in rL360842 as Windows bots were failing.

Wed, May 15, 8:42 PM · Restricted Project
kristina committed rG9d65624bf657: Revert r360833 until I can work out the issue with Win32 bots (authored by kristina).
Revert r360833 until I can work out the issue with Win32 bots
Wed, May 15, 8:28 PM
kristina committed rL360842: Revert r360833 until I can work out the issue with Win32 bots.
Revert r360833 until I can work out the issue with Win32 bots
Wed, May 15, 8:27 PM
kristina committed rC360842: Revert r360833 until I can work out the issue with Win32 bots.
Revert r360833 until I can work out the issue with Win32 bots
Wed, May 15, 8:27 PM
kristina committed rG69e927662dc9: Fix assumption about Win32 paths in r360833 (authored by kristina).
Fix assumption about Win32 paths in r360833
Wed, May 15, 7:44 PM
kristina committed rL360839: Fix assumption about Win32 paths in r360833.
Fix assumption about Win32 paths in r360833
Wed, May 15, 7:44 PM
kristina committed rC360839: Fix assumption about Win32 paths in r360833.
Fix assumption about Win32 paths in r360833
Wed, May 15, 7:44 PM
kristina committed rG3acc1d1be329: [Clang][PP] Add the __FILE_NAME__ builtin macro. (authored by kristina).
[Clang][PP] Add the __FILE_NAME__ builtin macro.
Wed, May 15, 5:52 PM
kristina committed rC360833: [Clang][PP] Add the __FILE_NAME__ builtin macro..
[Clang][PP] Add the __FILE_NAME__ builtin macro.
Wed, May 15, 5:50 PM
kristina committed rL360833: [Clang][PP] Add the __FILE_NAME__ builtin macro..
[Clang][PP] Add the __FILE_NAME__ builtin macro.
Wed, May 15, 5:50 PM
kristina closed D61756: Add a __FILE_NAME__ macro..
Wed, May 15, 5:50 PM · Restricted Project
kristina added a comment to D61756: Add a __FILE_NAME__ macro..

Landing this as discussed on IRC, will try to push it forward with WG14.

Wed, May 15, 5:42 PM · Restricted Project
kristina added a comment to D61756: Add a __FILE_NAME__ macro..

@rsmith Ping.

Wed, May 15, 3:28 PM · Restricted Project

Fri, May 10

kristina added a comment to D61756: Add a __FILE_NAME__ macro..

Need @rsmith to bless this as it's introducing a nonstandard extension, however small it may be. The original diff did have a consensus on it, so I didn't really put up a formal RFC on cfe-dev.

Fri, May 10, 4:38 PM · Restricted Project
kristina updated the diff for D61756: Add a __FILE_NAME__ macro..

Actually I got it wrong, the path is normalized to use regular slashes at that point, so there is no point in handling backslashes in paths at all even with Microsoft extensions.

Fri, May 10, 3:55 PM · Restricted Project

Thu, May 9

kristina updated the summary of D61756: Add a __FILE_NAME__ macro..
Thu, May 9, 1:52 PM · Restricted Project
kristina updated the diff for D61756: Add a __FILE_NAME__ macro..

Fix style, remove unnecessary braces, add missing newline.

Thu, May 9, 1:29 PM · Restricted Project
kristina added a reviewer for D61756: Add a __FILE_NAME__ macro.: dexonsmith.
Thu, May 9, 1:24 PM · Restricted Project
kristina abandoned D17741: adds __FILE_BASENAME__ builtin macro.

Superseded by D61756

Thu, May 9, 1:23 PM
kristina created D61756: Add a __FILE_NAME__ macro..
Thu, May 9, 1:20 PM · Restricted Project

Wed, May 8

kristina commandeered D17741: adds __FILE_BASENAME__ builtin macro.

Sorry, forgot about this, will make a new diff with just the macro for review later tonight.

Wed, May 8, 9:30 AM

Apr 9 2019

kristina committed rGa1c44941f360: Update modulemaps for Analysis/VecFuncs.def. (authored by kristina).
Update modulemaps for Analysis/VecFuncs.def.
Apr 9 2019, 10:04 AM
kristina committed rL358021: Update modulemaps for Analysis/VecFuncs.def..
Update modulemaps for Analysis/VecFuncs.def.
Apr 9 2019, 10:04 AM

Apr 5 2019

kristina committed rG233a498cf0a7: [docs] Fix rst title in clang langext docs. NFCI (authored by kristina).
[docs] Fix rst title in clang langext docs. NFCI
Apr 5 2019, 11:27 AM
kristina committed rC357793: [docs] Fix rst title in clang langext docs. NFCI .
[docs] Fix rst title in clang langext docs. NFCI
Apr 5 2019, 11:27 AM
kristina committed rL357793: [docs] Fix rst title in clang langext docs. NFCI .
[docs] Fix rst title in clang langext docs. NFCI
Apr 5 2019, 11:27 AM

Mar 12 2019

kristina committed rG14179673e27b: [Docs] Add note about legacy PM to Ch4 of tutorial (authored by kristina).
[Docs] Add note about legacy PM to Ch4 of tutorial
Mar 12 2019, 8:45 AM
kristina committed rL355930: [Docs] Add note about legacy PM to Ch4 of tutorial.
[Docs] Add note about legacy PM to Ch4 of tutorial
Mar 12 2019, 8:45 AM
kristina closed D59258: [Docs] Add a note about legacy FunctionPassManager to the LLVM tutorial..
Mar 12 2019, 8:45 AM · Restricted Project
kristina added a comment to D59258: [Docs] Add a note about legacy FunctionPassManager to the LLVM tutorial..

I did, there are no references to any PassManager related material in the first three chapters.

Mar 12 2019, 8:37 AM · Restricted Project
kristina created D59258: [Docs] Add a note about legacy FunctionPassManager to the LLVM tutorial..
Mar 12 2019, 8:31 AM · Restricted Project
kristina added a comment to D59243: [format] \t => ' '.

Please make sure to specify Differential Revision: https://reviews.llvm.org/D59243 with Dxxxxx being the differential number in the URL when committing (on a separate line in the commit message) which will autmatically close the differential and link it to the commit which makes sure there are no stray/stale differentials. Alternatively manually link the diff to the commit (you can do that by simply quoting the commit as rL<SVN Rev> and then closing the differential manually.

Mar 12 2019, 3:03 AM · Restricted Project
kristina committed rG5b1e1c0537d0: Very minor typo. NFC (authored by kristina).
Very minor typo. NFC
Mar 12 2019, 12:11 AM
kristina committed rL355895: Very minor typo. NFC.
Very minor typo. NFC
Mar 12 2019, 12:07 AM
kristina closed D59241: [typo] we we => we.
Mar 12 2019, 12:07 AM · Restricted Project

Mar 11 2019

kristina accepted D59241: [typo] we we => we.

we were?

Mar 11 2019, 11:57 PM · Restricted Project

Mar 3 2019

kristina committed rG24659eb2e766: Remove large amount of empty lines mid-file. NFC (authored by kristina).
Remove large amount of empty lines mid-file. NFC
Mar 3 2019, 5:22 AM
kristina committed rL355286: Remove large amount of empty lines mid-file. NFC.
Remove large amount of empty lines mid-file. NFC
Mar 3 2019, 5:22 AM

Feb 28 2019

kristina added a comment to D17741: adds __FILE_BASENAME__ builtin macro.

If the author is still missing at the end of next week, any objections to me resubmitting a similar patch that just implements __FILE_NAME__ or __BASE_NAME__ (Need a few more opinions here I guess, personally I think __FILE_NAME__ makes more sense)?

Feb 28 2019, 9:12 AM

Feb 27 2019

Herald added a project to D56383: [XRay][tools] Use symbols instead of function id: Restricted Project.

Gentle ping for author, has this landed or still in the backlog? (If it's landed can you attach the commit and close it, please? Just trying to to avoid diffs on Phab going stale.)

Feb 27 2019, 4:35 AM · Restricted Project
kristina added a comment to D57400: Add a .gitignore file to the root that ignores any files outside of the project directories..

What about using /*/ at the ignore pattern? This allows top-level files, and makes only new top-level *directories* require an ignore update. To my mind, that seems a bit more narrowly scoped and might be a bit less surprising. Thoughts?

Feb 27 2019, 4:33 AM

Feb 26 2019

kristina committed rG76eb4b02d93b: Update docs of memcpy/move/set wrt. align and len (authored by kristina).
Update docs of memcpy/move/set wrt. align and len
Feb 26 2019, 10:55 AM
kristina committed rL354911: Update docs of memcpy/move/set wrt. align and len.
Update docs of memcpy/move/set wrt. align and len
Feb 26 2019, 10:52 AM
kristina closed D57600: update docs of memcpy/memmove/memset re: alignment and len=0.
Feb 26 2019, 10:52 AM · Restricted Project

Feb 25 2019

kristina added a comment to D57600: update docs of memcpy/memmove/memset re: alignment and len=0.

@RalfJung Do you need someone to commit this? I can do it if you'd like.

Feb 25 2019, 1:36 PM · Restricted Project
kristina accepted D57600: update docs of memcpy/memmove/memset re: alignment and len=0.

Please make sure you have llvm-commits added as a subscriber when creating patches in the future (I'm not sure why Herald sometimes doesn't do it). The patch that changed this was rL322965, and I fixed one of the related regressions, and was meaning to update the docs but never did, so LGTM and I'm happy signing off on this.

Feb 25 2019, 9:31 AM · Restricted Project

Feb 24 2019

kristina committed rG103799c06028: Fix accidentally used hard tabs. NFC (authored by kristina).
Fix accidentally used hard tabs. NFC
Feb 24 2019, 10:09 AM
kristina committed rC354752: Fix accidentally used hard tabs. NFC.
Fix accidentally used hard tabs. NFC
Feb 24 2019, 10:06 AM
kristina committed rL354752: Fix accidentally used hard tabs. NFC.
Fix accidentally used hard tabs. NFC
Feb 24 2019, 10:06 AM
kristina committed rC354751: Wrap code for builtin_assume_aligned at 80 col.NFC.
Wrap code for builtin_assume_aligned at 80 col.NFC
Feb 24 2019, 9:58 AM
kristina committed rG716cbfb4640f: Wrap code for builtin_assume_aligned at 80 col.NFC (authored by kristina).
Wrap code for builtin_assume_aligned at 80 col.NFC
Feb 24 2019, 9:57 AM
kristina committed rL354751: Wrap code for builtin_assume_aligned at 80 col.NFC.
Wrap code for builtin_assume_aligned at 80 col.NFC
Feb 24 2019, 9:57 AM

Feb 16 2019

kristina added a comment to D57400: Add a .gitignore file to the root that ignores any files outside of the project directories..

I still don't like it...It's different, unusual, and IMO surprising to have such a wildcard ignore.

We haven't tended to have lots of random accidental file additions before, and while someone may surely mess up again, I don't think it likely to be a common occurrence.

I'd much prefer simply the targeted ignore of "/build*", at least for starters.

Feb 16 2019, 6:46 PM
kristina committed rG440f8f0c2b45: [LLVMSupport]: Remove a severely outdated README. (authored by kristina).
[LLVMSupport]: Remove a severely outdated README.
Feb 16 2019, 5:52 PM
kristina committed rL354209: [LLVMSupport]: Remove a severely outdated README..
[LLVMSupport]: Remove a severely outdated README.
Feb 16 2019, 5:52 PM
kristina planned changes to D56482: DO NOT SUBMIT. Draft for guidelines on using Phabricator..
Feb 16 2019, 3:20 PM · Restricted Project
kristina added a comment to D57400: Add a .gitignore file to the root that ignores any files outside of the project directories..

I'm in favor of this and I agree with @pcc's points and reasoning behind this.

Feb 16 2019, 3:14 PM

Feb 15 2019

kristina added a comment to D57429: [docs] Document ignoring build directory.

I actually like the D57400 approach more, it's much easier to keep a list of known top level projects as a whitelist. There are many names people could give to such a build directory (out or build or b) not to mention any other cruft one may have there. (ie. I build a libc as part of toolchain build).

Feb 15 2019, 2:37 AM · Restricted Project

Feb 6 2019

kristina added a comment to D56943: [clang-format][NFC] Allow getLLVMStyle() to take a language.

The patch itself looks sound. However given that you have a specific use case in mind (TableGen files) could you provide supplementary coverage for that specific use case (unit tests for formatting td syntax using format::getLLVMStyle(format::FormatStyle::LK_TableGen)? I'm not entirely sure how useful this particular change is given that there's no linked patches related to your use case, I think adding those would help as well (possibly as a separate dependent patchset).

Feb 6 2019, 7:46 PM · Restricted Project, Restricted Project

Jan 29 2019

kristina added a comment to D57128: Add --unwindlib=[libgcc|compiler-rt] to parallel --rtlib=.

FWIW, this also broke my bootstraps of mingw-w64 environments/toolchains. After building compiler-rt builtins, before having any libunwind/libcxx built, I previously regarded my toolchain as complete for building and testing C apps and libraries, but that fails now.

Would it be possible to add a third alternative, --unwindlib=none, to signal that while I'm using --rtlib=compiler-rt, I don't want to link to any unwinder? (In my case, I'm injecting libunwind in libc++.a so it only gets added when linking C++ code.) Or at least make it possible to only add this linker flag when linking C++? Alternatively I'll need to provide a dummy libunwind.a until the real one has been built.

Jan 29 2019, 12:27 AM

Jan 28 2019

kristina added a comment to D57128: Add --unwindlib=[libgcc|compiler-rt] to parallel --rtlib=.

One more thing, shouldn't libunwind be only included for C++ (since it's the internal dependency of libc++abi)? There shouldn't be any need to include it for C.

Jan 28 2019, 9:06 PM
kristina accepted D55439: [MC] Do not consider .ifdef/.ifndef as a use.

LGTM.

Jan 28 2019, 8:38 AM

Jan 20 2019

kristina committed rL351722: [llgo]: fix compilation under current llvm.
[llgo]: fix compilation under current llvm
Jan 20 2019, 8:37 PM
kristina closed D56638: [llgo]: Somewhat revive it and make it buildable with current trunk..
Jan 20 2019, 8:37 PM
kristina added a comment to D56638: [llgo]: Somewhat revive it and make it buildable with current trunk..

Revised, landing it without split stack stuff, should autoupdate the revision here.

Jan 20 2019, 8:32 PM

Jan 19 2019

kristina committed rL351639: Remove a period from CREDITS.TXT (testing email change). NFC.
Remove a period from CREDITS.TXT (testing email change). NFC
Jan 19 2019, 1:15 AM

Jan 18 2019

kristina added a comment to D56638: [llgo]: Somewhat revive it and make it buildable with current trunk..

Ping.

Jan 18 2019, 1:58 PM

Jan 17 2019

kristina added a reviewer for D55439: [MC] Do not consider .ifdef/.ifndef as a use: kristina.

LGTM if GAS does allow multiple uses of .set to change the value. One nit on the test, can you add a case where you don't have an .if directive like:

Jan 17 2019, 8:10 AM

Jan 14 2019

kristina committed rL351082: [Sema] Expose a control flag for integer to pointer ext warning.
[Sema] Expose a control flag for integer to pointer ext warning
Jan 14 2019, 10:21 AM
kristina committed rC351082: [Sema] Expose a control flag for integer to pointer ext warning.
[Sema] Expose a control flag for integer to pointer ext warning
Jan 14 2019, 10:20 AM
kristina closed D56241: [Sema] expose a control flag for integer to pointer ext warning.
Jan 14 2019, 10:20 AM · Restricted Project
kristina added a comment to D56241: [Sema] expose a control flag for integer to pointer ext warning.

Going to test and land it as requested by @lebedev.ri on IRC.

Jan 14 2019, 9:26 AM · Restricted Project

Jan 13 2019

kristina added a comment to D56638: [llgo]: Somewhat revive it and make it buildable with current trunk..

Currently actual tests would require using libgcc, as compiler-rt does not support split stack yet. If libgcc is required for tests then I don't think I can accurately make one. So if you require a test for this, it's likely that I'll have to mark this as "Changes Planned" for now until compiler-rt is sufficient to link this, unfortunately. Up to you really, though in my opinion even without tests this is better than it failing to compile. And the reasons for avoiding libgcc are fairly complicated, my intentions currently are to stay as far away from GNU runtime components as possible.

Jan 13 2019, 2:40 PM
kristina added a comment to D28791: [compiler-rt][crt] Simple crtbegin and crtend implementation.

FWIW, I completely support landing this. I think the opposition is essentially "it would be better to not design a libc in that way" which is certainly a valid opinion, but given the existence of such libc designs widely deployed and widely used, it seems very good to lay groundwork for LLVM to support them.

I also think we should *not* be pointing at GNU or any other project here, and instead simply state that these exist to support using LLVM in conjunction with systems whose libc chooses this particular design pattern.

I don't think LLVM should be in the business of trying to cast some kind of "you should feel bad" judgement on such systems. If someone in the LLVM community wants to develop a libc as part of LLVM (which I would quite like to see), then that is the place to debate libc design decisions, and not anywhere else.

So, that said, does anyone have comments on the code itself? If no one is up to commenting on the code and giving Petr direct feedback there, I'll just LGTM this because I think it is long (looooooong) overdue.

Lastly, to address specific questions here:

That's fine, it's just not the state of the world and we should support compiling appropriately.

I don't want to pick a fight, but there can be used exactly same argument to defend pulling libgcc here.

That doesn't make sense to me -- the LLVM project has lots of reasons why it doesn't pull GPL-ed code into its tree.

But yes, we are going to be in the business of being 100% and fully compatible with libgcc in order to effectively support platforms based on libcs that follow the design pattern of glibc, certainly including platforms that use glibc. Is that work? Yes. Should the project do it? Absolutely yes. Just like we work hard to be compatible with the gcc commandline and other layers of compatibility, we should work to support these platforms well.

Jan 13 2019, 1:34 AM · Restricted Project, Restricted Project

Jan 12 2019

kristina added a comment to D56638: [llgo]: Somewhat revive it and make it buildable with current trunk..

Changes to runtime.go address the regression caused by rL322965.

Jan 12 2019, 8:22 AM
kristina created D56638: [llgo]: Somewhat revive it and make it buildable with current trunk..
Jan 12 2019, 8:18 AM

Jan 10 2019

kristina added a comment to D56482: DO NOT SUBMIT. Draft for guidelines on using Phabricator..

Addressed all comments, will wait for feedback and then do the final draft, and if people are happy with that, I'll lint the whole file and then commit it.

Jan 10 2019, 2:41 AM · Restricted Project

Jan 9 2019

kristina added a comment to D56482: DO NOT SUBMIT. Draft for guidelines on using Phabricator..

! In D56482#1350874, @kristina wrote:

I only added a section, all the warnings are from existing bits below. Not sure if it's a good idea to reformat it as part of the diff as it will make it harder to see the added section. Can do it afterwards but that's what's currently being used to generate documentation.

Sorry I wasn't clear, I'm using a script from D55523: [clang-tidy] Linting .rst documentation to validate .rst files, if you read the revision there is some info on the rational. (I simply ran it here on a copy of the file you are editing prior to your revision). You'll see from D55523 that I mention that I saw a lot of review comments which amounted to stylistic changes in the .rst files, and yet I see a lot of reviewers time pointing these out, time and time again and its all simple stuff that could be automated. (or at least added to such a how to guide)

it would be good if we could ensure .rst files are checked prior to review (how we do this I don't know) without initially generating 10,000 of minor whitespaces changes.

when I reviewed all .rst files currently checked into LLVM I found 10,000's of simple violations (maybe people aren't worried about it but certainly it comes up a lot in reviews and causes the second or third revisions)

I think another point is that lot of review comments could potentially be caught by clang-tidy, there is sometimes lots of the review conversations especially with new contributors, about "don't use anonymous namspaces but prefer static functions","clang-format the file", don't overly use auto", don't have "const value types" all stuff that is in the CodingStyle but is easily missed when making or updating a review.

It would be good if we had a mechanism to be able to validate a patch prior to commit, maybe using something like clang-tidy-diff.py in combination with something like the .rst linter to reduce the iterations on a revision, speed up development and reduce the burden that seems present on a group of dedicated but possible select people.

Jan 9 2019, 12:52 PM · Restricted Project
kristina added a comment to D56482: DO NOT SUBMIT. Draft for guidelines on using Phabricator..

$ ./validate_check.py --rst ../../../../../docs/Phabricator.rst
Checking ..\..\..\..\..\docs\Phabricator.rst...
warning: line 97 multiple blank lines
warning: line 166 is in excess of 80 characters (82) : as it will retrieve reviewers, the `Differential Revision`, etc from the review
...
warning: line 175 contains double spaces
warning: line 188 is in excess of 80 characters (97) : The first command will take the latest version of the reviewed patch and apply it to the working
...
warning: line 194 is in excess of 80 characters (111) : This presumes that the git repository has been configured as described in :ref:developers-work-with-git-svn.
...
warning: line 203 multiple blank lines
warning: line 205 is in excess of 80 characters (84) : current `master and will create a commit corresponding to D<Revision>` with a
...
warning: line 208 is in excess of 80 characters (85) : Check you are happy with the commit message and amend it if necessary. Now switch to
...
warning: line 218 multiple blank lines
warning: line 219 multiple blank lines

Jan 9 2019, 2:45 AM · Restricted Project
kristina added a reviewer for D56482: DO NOT SUBMIT. Draft for guidelines on using Phabricator.: lebedev.ri.
Jan 9 2019, 1:59 AM · Restricted Project
kristina added inline comments to D56482: DO NOT SUBMIT. Draft for guidelines on using Phabricator..
Jan 9 2019, 1:59 AM · Restricted Project
kristina updated the diff for D56482: DO NOT SUBMIT. Draft for guidelines on using Phabricator..

Spellcheck.

Jan 9 2019, 1:54 AM · Restricted Project
kristina created D56482: DO NOT SUBMIT. Draft for guidelines on using Phabricator..
Jan 9 2019, 1:45 AM · Restricted Project

Jan 8 2019

kristina updated subscribers of rL350671: [PGO] Use SourceFileName rather module name in PGOFuncName.

+llvm-commits

Jan 8 2019, 5:25 PM
kristina raised a concern with rL350671: [PGO] Use SourceFileName rather module name in PGOFuncName.

Unaddressed issues in pre-commit review.

Jan 8 2019, 5:05 PM