Page MenuHomePhabricator

manmanren (Manman Ren)
User

Projects

User does not belong to any projects.

User Details

User Since
Dec 17 2014, 5:37 PM (230 w, 4 d)

Recent Activity

Mar 8 2019

manmanren committed rGe73ae9a142c2: Reland compiler-rt support for order file instrumentation. (authored by manmanren).
Reland compiler-rt support for order file instrumentation.
Mar 8 2019, 7:32 AM

Mar 7 2019

manmanren added a comment to D58997: Order File Instrumentation: dump the data in compiler-rt (Make it work for Linux/Windows etc).

Thanks!

Mar 7 2019, 8:33 PM · Restricted Project, Restricted Project

Mar 6 2019

manmanren added inline comments to D58997: Order File Instrumentation: dump the data in compiler-rt (Make it work for Linux/Windows etc).
Mar 6 2019, 1:33 PM · Restricted Project, Restricted Project

Mar 5 2019

manmanren added inline comments to D58997: Order File Instrumentation: dump the data in compiler-rt (Make it work for Linux/Windows etc).
Mar 5 2019, 2:24 PM · Restricted Project, Restricted Project
manmanren created D58997: Order File Instrumentation: dump the data in compiler-rt (Make it work for Linux/Windows etc).
Mar 5 2019, 2:18 PM · Restricted Project, Restricted Project

Mar 4 2019

manmanren committed rGff4bb36d7c64: Revert compiler-rt diffs for order file instrumentation to get bot green! (authored by manmanren).
Revert compiler-rt diffs for order file instrumentation to get bot green!
Mar 4 2019, 5:23 PM
manmanren committed rG31b31e511155: Attemp to fix windows profile-rt build breakage. (authored by manmanren).
Attemp to fix windows profile-rt build breakage.
Mar 4 2019, 4:52 PM
manmanren committed rG03d534813222: Attemp to fix build brokage due to D57530. (authored by manmanren).
Attemp to fix build brokage due to D57530.
Mar 4 2019, 3:42 PM
manmanren closed D58751: Order File Instrumentation: add clang support for -forder-file-instrumentation.

r355333

Mar 4 2019, 2:37 PM · Restricted Project
manmanren committed rG4737abc71ccd: Order File Instrumentation: dump the data in compiler-rt (authored by manmanren).
Order File Instrumentation: dump the data in compiler-rt
Mar 4 2019, 2:30 PM
manmanren committed rG394d4ccf693a: Order File Instrumentation: add clang support for -forder-file-instrumentation (authored by manmanren).
Order File Instrumentation: add clang support for -forder-file-instrumentation
Mar 4 2019, 12:32 PM
manmanren added inline comments to D58751: Order File Instrumentation: add clang support for -forder-file-instrumentation.
Mar 4 2019, 12:31 PM · Restricted Project

Mar 1 2019

manmanren updated the diff for D57530: Order File Instrumentation: dump the data in compiler-rt.

Mark windows as unsupported in the testing case.

Mar 1 2019, 9:19 AM · Restricted Project, Restricted Project
manmanren committed rG576124a31991: Try to fix NetBSD buildbot breakage introduced in D57463. (authored by manmanren).
Try to fix NetBSD buildbot breakage introduced in D57463.
Mar 1 2019, 7:26 AM

Feb 28 2019

manmanren added a comment to D57530: Order File Instrumentation: dump the data in compiler-rt.

Thanks!

Feb 28 2019, 6:07 PM · Restricted Project, Restricted Project
manmanren updated the diff for D57530: Order File Instrumentation: dump the data in compiler-rt.

Address review comments!

Feb 28 2019, 3:59 PM · Restricted Project, Restricted Project
manmanren committed rG12b75594ed86: Trying to fix bot breakage due to symbols not defined for WINDOWS! (authored by manmanren).
Trying to fix bot breakage due to symbols not defined for WINDOWS!
Feb 28 2019, 12:48 PM
manmanren committed rG1829512dd3a1: Add a module pass for order file instrumentation (authored by manmanren).
Add a module pass for order file instrumentation
Feb 28 2019, 12:13 PM

Feb 27 2019

manmanren updated the diff for D57463: Add a module pass for order file instrumentation.

Rebase

Feb 27 2019, 7:34 PM · Restricted Project
manmanren updated the diff for D57530: Order File Instrumentation: dump the data in compiler-rt.

Add a testing case to make sure the instrumentation works correctly!

Feb 27 2019, 7:30 PM · Restricted Project, Restricted Project
manmanren created D58751: Order File Instrumentation: add clang support for -forder-file-instrumentation.
Feb 27 2019, 5:27 PM · Restricted Project
manmanren updated the diff for D57530: Order File Instrumentation: dump the data in compiler-rt.

Hi David,

Feb 27 2019, 9:08 AM · Restricted Project, Restricted Project

Feb 7 2019

manmanren added inline comments to D57463: Add a module pass for order file instrumentation.
Feb 7 2019, 10:18 AM · Restricted Project
manmanren updated the diff for D57463: Add a module pass for order file instrumentation.

I think I have addressed most of the comments. There is one comment which I am not sure.

Feb 7 2019, 10:13 AM · Restricted Project

Jan 31 2019

manmanren updated the diff for D57530: Order File Instrumentation: dump the data in compiler-rt.

Small Nits

Jan 31 2019, 3:20 PM · Restricted Project, Restricted Project
manmanren updated the diff for D57463: Add a module pass for order file instrumentation.

Address some review comments

Jan 31 2019, 3:18 PM · Restricted Project
manmanren updated the diff for D57463: Add a module pass for order file instrumentation.

Add support for the new pass manager

Jan 31 2019, 3:16 PM · Restricted Project
manmanren created D57530: Order File Instrumentation: dump the data in compiler-rt.
Jan 31 2019, 11:20 AM · Restricted Project, Restricted Project

Jan 30 2019

manmanren created D57463: Add a module pass for order file instrumentation.
Jan 30 2019, 9:53 AM · Restricted Project

Nov 29 2018

manmanren added a comment to D51568: [modules] Add `-fno-absolute-module-directory` flag for relocatable modules.

I am not sure if this is the best approach, but the implementation looks okay to me. @bruno @rsmith What do you think?

Nov 29 2018, 7:27 AM

Mar 9 2017

manmanren added a comment to D29923: PPCallbacks::MacroUndefined, change signature and add test..

Please update the patch with context: http://llvm.org/docs/Phabricator.html#requesting-a-review-via-the-web-interface

Mar 9 2017, 10:44 AM
manmanren added a comment to D25664: [PeepholeOptimizer] Load now may be folded into isLoadFoldBarrier instruction.

Is it possible to add a testing case?

Mar 9 2017, 10:32 AM

Feb 13 2017

manmanren accepted D26831: [LangRef] Update the TBAA section.

LGTM. Sorry for the delay,

Feb 13 2017, 1:26 PM

Jan 18 2017

manmanren added a comment to D28299: Module: use PCMCache to manage memory buffers for pcm files..

Ping :]
Hoping to wrap this up this week.
Cheers,
Manman

Jan 18 2017, 1:47 PM
manmanren added a comment to D27689: Module: hash the pcm content and use it as SIGNATURE for implicit modules..

Ping :]
I am hoping to wrap this up this week. Thanks,
Manman

Jan 18 2017, 1:47 PM

Jan 17 2017

manmanren accepted D28779: [ASTReader] Add a DeserializationListener callback for IMPORTED_MODULES.

LGTM

Jan 17 2017, 5:00 PM
manmanren accepted D28790: [Modules] Correct test comment from obsolete earlier version of code. NFC.

LGTM

Jan 17 2017, 4:52 PM

Jan 13 2017

manmanren added inline comments to D27689: Module: hash the pcm content and use it as SIGNATURE for implicit modules..
Jan 13 2017, 3:58 PM
manmanren updated the diff for D27689: Module: hash the pcm content and use it as SIGNATURE for implicit modules..

Add CC1 option to control hashing of the module file content.

Jan 13 2017, 3:56 PM

Jan 12 2017

manmanren added a comment to D27689: Module: hash the pcm content and use it as SIGNATURE for implicit modules..

Bruno helped on collecting performance data for this patch:
$ cat cocoa-test.h
#import <Cocoa/Cocoa.h>

Jan 12 2017, 11:35 AM
manmanren updated the diff for D28299: Module: use PCMCache to manage memory buffers for pcm files..

Addressing review comments.

Jan 12 2017, 9:58 AM

Jan 11 2017

manmanren updated the diff for D27689: Module: hash the pcm content and use it as SIGNATURE for implicit modules..

Rebase on top of r291686.

Jan 11 2017, 10:27 AM

Jan 6 2017

manmanren retitled D28415: PCH: fix a regression that reports a module is defined in both pch and pcm from to PCH: fix a regression that reports a module is defined in both pch and pcm.
Jan 6 2017, 2:40 PM

Jan 5 2017

manmanren added inline comments to D28299: Module: use PCMCache to manage memory buffers for pcm files..
Jan 5 2017, 10:54 AM
manmanren updated the diff for D28299: Module: use PCMCache to manage memory buffers for pcm files..

Add testing case.

Jan 5 2017, 10:47 AM
manmanren added a comment to D28299: Module: use PCMCache to manage memory buffers for pcm files..

I forgot to upload the testing case, I will add it now.

Jan 5 2017, 10:45 AM

Jan 4 2017

manmanren accepted D26034: [CodeCompletion] Block property setters: Use dynamic priority heuristic.

LGTM.

Jan 4 2017, 10:17 AM
manmanren retitled D28299: Module: use PCMCache to manage memory buffers for pcm files. from to Module: use PCMCache to manage memory buffers for pcm files..
Jan 4 2017, 9:58 AM
manmanren updated the diff for D27689: Module: hash the pcm content and use it as SIGNATURE for implicit modules..

Addressing review comments!

Jan 4 2017, 9:55 AM

Dec 20 2016

manmanren added a comment to D26831: [LangRef] Update the TBAA section.

Thanks for working on this, Sanjoy!

Dec 20 2016, 11:27 AM
manmanren accepted D27852: [modules] Handle modules with nonstandard names in module.private.modulemaps.

Thanks,
Manman

Dec 20 2016, 9:38 AM

Dec 17 2016

manmanren accepted D27546: [ASTReader] Sort RawComments before merging.

LGTM.

Dec 17 2016, 7:44 PM

Dec 12 2016

manmanren retitled D27689: Module: hash the pcm content and use it as SIGNATURE for implicit modules. from to Module: hash the pcm content and use it as SIGNATURE for implicit modules..
Dec 12 2016, 3:09 PM

Dec 11 2016

manmanren accepted D26438: [Verifier] Add verification for TBAA metadata.

Thanks,

Dec 11 2016, 1:38 PM

Dec 7 2016

manmanren added a comment to D26438: [Verifier] Add verification for TBAA metadata.

Thanks for the work!

Dec 7 2016, 1:47 PM
manmanren accepted D27039: [CodeCompletion] Autocomplete NS_DESIGNATED_INITIALIZER in initializers with arguments.

LGTM

Dec 7 2016, 1:01 PM
manmanren accepted D27053: [CodeCompletion] Provide Objective-C class property completion results.

LGTM .

Dec 7 2016, 9:28 AM
manmanren accepted D26503: [Parser][ObjC] Improve diagnostics and recovery when C++ keywords are used as identifiers in Objective-C++.

LGTM

Dec 7 2016, 8:23 AM

Dec 6 2016

manmanren added a comment to D26438: [Verifier] Add verification for TBAA metadata.

The rest looks pretty reasonable.

Dec 6 2016, 4:46 PM

Nov 18 2016

manmanren accepted D26635: [TBAA] Don't generate invalid TBAA when merging nodes.

In particular, I think once D26438 is checked in (I'm also waiting for you to take a look at that one, btw :) )

I will take a look at that soon :)

Nov 18 2016, 12:29 PM

Nov 17 2016

manmanren added inline comments to D26635: [TBAA] Don't generate invalid TBAA when merging nodes.
Nov 17 2016, 3:17 PM

Nov 15 2016

manmanren added a comment to D26635: [TBAA] Don't generate invalid TBAA when merging nodes.

Cheers,

Nov 15 2016, 4:30 PM
manmanren added a comment to D26503: [Parser][ObjC] Improve diagnostics and recovery when C++ keywords are used as identifiers in Objective-C++.

Cheers,
Manman

Nov 15 2016, 3:26 PM

Nov 14 2016

manmanren added a comment to D25916: Modules: emit an error instead of a random crash (or a misleading error) due to use-after-free..

Does it mean that a system module should only import system modules? If a system module is allowed to import non-system modules, for a non-system module, we will validate diagnostic options differently depending on whether a system module or a non-system module imports it. This will cause a non-system module that was validated earlier to be invalidated by a child thread.

It seems like we should validate the options the same way regardless of what the importer is, but I'm guessing this was done for a reason... What's the behaviour of a user-header imported by a system header (without modules)? If the user header warnings show up even without -Wsystem-headers, then we should be okay validating, right?

Nov 14 2016, 4:38 PM
manmanren added a comment to D25916: Modules: emit an error instead of a random crash (or a misleading error) due to use-after-free..

We are hitting this issue when building large projects, but the reproducibility is quite low.

Nov 14 2016, 12:08 PM

Nov 11 2016

manmanren added a comment to D26438: [Verifier] Add verification for TBAA metadata.

Hi all (esp. @manmanren ),

Are you happy with the general direction here? If so, I'll start writing some FileCheck unit tests (I don't want to sink time into tests if there we are likely going to see major corrections here).

Nov 11 2016, 5:03 PM

Nov 10 2016

manmanren added a comment to D26438: [Verifier] Add verification for TBAA metadata.

The tag for the load instruction is !2 whose access type is !7 == !{!"float", !5, i64 0}.

!7 is a scalar type node, it is a float, right?

Perhaps we are talking past each other, but are you concluding that it is scalar by looking at its name? I thought the names themselves were not supposed to be significant within the TBAA type system.

Structurally, it is exactly a struct that with a single char field. If I compile

struct S {
     int i;
     float f;
};

struct S2 {
     char c;
};

float f(struct S* s, struct S2* s2) {
     return s->f + s2->c;
}

then I get:

!0 = !{i32 1, !"PIC Level", i32 2}
!1 = !{!"clang version 4.0.0 (http://llvm.org/git/clang.git b74377b0a34a33cb3c7b565f0e543cd3e56b3f6b) (llvm/trunk 286280)"}
!2 = !{!3, !7, i64 4}
!3 = !{!"S", !4, i64 0, !7, i64 4}
!4 = !{!"int", !5, i64 0}
!5 = !{!"omnipotent char", !6, i64 0}
!6 = !{!"Simple C/C++ TBAA"}
!7 = !{!"float", !5, i64 0}
!8 = !{!9, !5, i64 0}
!9 = !{!"S2", !5, i64 0}

with !2 as the access tag for s->f and !8 as the access tag for s2->c. !2 has !7 as its access type (which means it must be a scalar type), which is indistinguishable from the struct type node !9, except from its name. Without a priori knowledge of what "float" and "S2" mean, we can't conclude one way or the other.

Nov 10 2016, 10:12 AM

Nov 9 2016

manmanren added a comment to D26438: [Verifier] Add verification for TBAA metadata.

There is this bit of language in the TBAA implementation:

// The second field is the access type node, it
// must be a scalar type node.

but in the TBAA metadata generated by clang it seems like we have access types like !{!"int", !N, i64 0} which look like struct nodes.

Can you give an example where clang generates a struct path tag node where the 2nd field is not a scalar type node?

That seems to be the case everywhere. E.g.

struct S {
     int i;
     float f;
};

float f(struct S* s) {
     return s->f;
}

compiles to

; ModuleID = 'x.c'
source_filename = "x.c"
target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-apple-macosx10.12.0"

%struct.S = type { i32, float }

; Function Attrs: norecurse nounwind readonly ssp uwtable
define float @f(%struct.S* nocapture readonly %s) local_unnamed_addr #0 {
entry:
  %f = getelementptr inbounds %struct.S, %struct.S* %s, i64 0, i32 1
  %0 = load float, float* %f, align 4, !tbaa !2
  ret float %0
}

attributes #0 = { ... }

!llvm.module.flags = !{!0}
!llvm.ident = !{!1}

!0 = !{i32 1, !"PIC Level", i32 2}
!1 = !{!"clang version 4.0.0 (http://llvm.org/git/clang.git b74377b0a34a33cb3c7b565f0e543cd3e56b3f6b) (llvm/trunk 286280)"}
!2 = !{!3, !7, i64 4}
!3 = !{!"S", !4, i64 0, !7, i64 4}
!4 = !{!"int", !5, i64 0}
!5 = !{!"omnipotent char", !6, i64 0}
!6 = !{!"Simple C/C++ TBAA"}
!7 = !{!"float", !5, i64 0}

The tag for the load instruction is !2 whose access type is !7 == !{!"float", !5, i64 0}.

Nov 9 2016, 7:43 PM
manmanren added a comment to D26438: [Verifier] Add verification for TBAA metadata.

When did we stop using the "old" form? We don't need to preserve an auto-upgrade forever, as long as we can simply drop metadata for old bitcodes this is as valid alternative.

We've had the auto upgrade logic for what looks like approximately 3 years. I think it is reasonable to deprecate the functionality and eventually remove it, though I know (from off-list emails) that it will break (in terms of performance, not correctness) downstream users.

Can you explain more on why it will break downstream users in terms of performance?

I meant if we go by Mehdi's strategy of dropping old style tbaa metadata instead of auto-upgrading them then downstream users who generate the old style tbaa metadata will no longer get the benefit of TBAA. Their code will be correctly compiled, but will run slower.

Nov 9 2016, 7:31 PM
manmanren added a comment to D26438: [Verifier] Add verification for TBAA metadata.

When did we stop using the "old" form? We don't need to preserve an auto-upgrade forever, as long as we can simply drop metadata for old bitcodes this is as valid alternative.

We've had the auto upgrade logic for what looks like approximately 3 years. I think it is reasonable to deprecate the functionality and eventually remove it, though I know (from off-list emails) that it will break (in terms of performance, not correctness) downstream users.

Nov 9 2016, 7:02 PM
manmanren added a comment to D26438: [Verifier] Add verification for TBAA metadata.

Hi Manman,

I may have misunderstood your point, but for struct-path TBAA, the last integer for a type node is the offset. Only for old scalar TBAA, the last optional integer specifies whether it is immutable. There is no ambiguity in struct-path TBAA.

Thanks, that clears it up for me.

There is this bit of language in the TBAA implementation:

// The second field is the access type node, it
// must be a scalar type node.

but in the TBAA metadata generated by clang it seems like we have access types like !{!"int", !N, i64 0} which look like struct nodes.

Can you give an example where clang generates a struct path tag node where the 2nd field is not a scalar type node?

Nov 9 2016, 7:00 PM
manmanren added inline comments to D22696: [CodeGenPrep] Skip merging empty case blocks.
Nov 9 2016, 11:41 AM
manmanren added a comment to D26438: [Verifier] Add verification for TBAA metadata.

There is one place where there is an ambiguity in the specification:
given a base type !{!"whatever", !N, i64 1} there is no way to tell if
this is a struct containing !N at offset i64 1 or a scalar immutable
TBAA node with !N as the parent. Right now I interpret this as the
former (as the implementation has been doing for 3 years). I will fix
the specification in a forthcoming documentation patch.

Nov 9 2016, 11:14 AM

Nov 8 2016

manmanren accepted D26071: [CodeCompletion] Show block invocation result for block property setters.

LGTM.

Nov 8 2016, 4:38 PM
manmanren added a comment to D26229: [TBAA] Drop support for "old style" scalar TBAA.

Nice clean up!

Nov 8 2016, 7:47 AM

Oct 26 2016

manmanren accepted D25993: [Objective-C] Add objc_subclassing_restricted attribute.

LGTM.

Oct 26 2016, 10:27 AM

Oct 24 2016

manmanren added a comment to D25916: Modules: emit an error instead of a random crash (or a misleading error) due to use-after-free..

In this testing case, the first clang invocation builds a system module X and a non-system module Y (X imports Y). At the second clang invocation, the parent thread validates the existing module X and module Y. Because X is a system module, we don't diagnose the differences in diagnostic options. When building module Z in the child thread, since Z is not a system module, we will spot the diagnostic differences and invalidate module Y. But the parent thread will continue accessing the deleted FileEntry for module Y.

Oct 24 2016, 11:40 AM
manmanren retitled D25916: Modules: emit an error instead of a random crash (or a misleading error) due to use-after-free. from to Modules: emit an error instead of a random crash (or a misleading error) due to use-after-free..
Oct 24 2016, 11:31 AM

Oct 20 2016

manmanren updated the diff for D25806: Module: correctly set the module file kind when emitting diagnostics for file_modified.

Thanks Richard for the testing case. It is also obvious from the testing case that we can have another diagnostic in flight when emitting err_fe_pch_file_modified.

Oct 20 2016, 11:33 AM

Oct 19 2016

manmanren retitled D25806: Module: correctly set the module file kind when emitting diagnostics for file_modified from to Module: correctly set the module file kind when emitting diagnostics for file_modified.
Oct 19 2016, 5:05 PM
manmanren added a comment to D25777: [Sema][TreeTransform] Re-create DesignatedInitExpr when it has a field designator with a valid FieldDecl.

It makes sense to rebuild the expression when a field designator stores a FieldDecl.

Oct 19 2016, 2:52 PM

Oct 18 2016

manmanren added a comment to D22638: Module: add debug_type to dump debugging messages related to modules being out of date.

Thanks a lot for the pointers!

Oct 18 2016, 2:00 PM

Oct 17 2016

manmanren added inline comments to D25678: [modules] Do not report missing definitions of demoted constexpr variable templates. This is a followup to regression introduced in r284284. This should fix our libstdc++ modules builds..
Oct 17 2016, 3:41 PM
manmanren updated D22638: Module: add debug_type to dump debugging messages related to modules being out of date.
Oct 17 2016, 3:39 PM
manmanren accepted D25284: AvailabilityAttrs: Delay partial availability diagnostics.

This is better than what I asked for :]

Oct 17 2016, 3:34 PM

Oct 14 2016

manmanren accepted D25519: [CodeCompletion] Refactor: Extract two Objective-C block formatting related functions from FormatFunctionParameter.

LGTM.

Oct 14 2016, 2:48 PM

Oct 12 2016

manmanren added a comment to D25519: [CodeCompletion] Refactor: Extract two Objective-C block formatting related functions from FormatFunctionParameter.

Cheers,
Manman

Oct 12 2016, 10:43 AM

Oct 11 2016

manmanren accepted D25436: [CodeCompletion] Improve completion for properties declared in Objective-C protocols.

LGTM.

Oct 11 2016, 9:33 AM

Oct 10 2016

manmanren added a comment to D25284: AvailabilityAttrs: Delay partial availability diagnostics.

Nice cleanup! Thanks for working on this,

Oct 10 2016, 4:56 PM
manmanren added a comment to D25283: AvailabilityAttrs: Refactor context checking when diagnosing an availability violation.

This is a nice cleanup!

Oct 10 2016, 12:45 PM
manmanren added a comment to D25436: [CodeCompletion] Improve completion for properties declared in Objective-C protocols.

Thanks for working on this!
Manman

Oct 10 2016, 11:22 AM

Sep 15 2016

manmanren accepted D24620: Fix autoupgrade logic for Objective-C class properties module flag.

LGTM. Please update the comment.

Sep 15 2016, 3:16 PM
manmanren added a comment to D24620: Fix autoupgrade logic for Objective-C class properties module flag.

Thanks for working on this!

Sep 15 2016, 1:50 PM

Sep 9 2016

manmanren added a comment to D23079: ObjC: Use a new type for ObjC type parameter (patch 2 out of 3).

Hi Doug,

Sep 9 2016, 12:25 PM

Aug 30 2016

manmanren retitled D24059: NFC: refactor applyObjCProtocolQualifiers from SemaType.cpp to ASTContext so it can be shared. from to NFC: refactor applyObjCProtocolQualifiers from SemaType.cpp to ASTContext so it can be shared..
Aug 30 2016, 3:19 PM
manmanren updated the diff for D23080: ObjC: Use a new type for ObjC type parameter (patch 3 out of 3).

This patch is now much simpler with the updated version of D23079.

Aug 30 2016, 3:15 PM
manmanren updated the diff for D23079: ObjC: Use a new type for ObjC type parameter (patch 2 out of 3).

Address Doug's comment. ObjCTypeParamType is a non-canonical type now, it is canonicalized to the underlying type with protocol qualifiers.

Aug 30 2016, 3:13 PM

Aug 25 2016

manmanren added a comment to D23858: Don't diagnose non-modular includes when we are not compiling a module.

It seems to me like this is papering over an issue rather than fixing it.

Aug 25 2016, 3:04 PM

Aug 24 2016

manmanren retitled D23858: Don't diagnose non-modular includes when we are not compiling a module from to Don't diagnose non-modular includes when we are not compiling a module.
Aug 24 2016, 4:33 PM

Aug 19 2016

manmanren added a comment to D23079: ObjC: Use a new type for ObjC type parameter (patch 2 out of 3).

Thanks for reviewing!

Aug 19 2016, 5:24 PM