[PATCH] D71408: [lit] Remove lit's REQUIRES-ANY directive

[Greg Parker via Phabricator via cfe-commits]

gparker42 accepted this revision.
gparker42 added a comment.
This revision is now accepted and ready to land.

Good. `REQUIRES-ANY` was preserved when the boolean expressions were added 
because libc++ was still using it. libc++ has since changed their tests so 
removing it should be fine now.
(previous discussion: D18185 )

The risk for any remaining users of `REQUIRES-ANY` is that they will see a test 
run too often. That's an acceptable failure mode (unlike silently not running 
the test at all).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71408/new/

https://reviews.llvm.org/D71408



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D57936: [CodeGenObjC] When available, emit a direct call to objc_alloc_init(cls) instead of [objc_alloc(cls) init]

[Greg Parker via Phabricator via cfe-commits]

gparker42 added inline comments.



Comment at: clang/lib/CodeGen/CGObjC.cpp:459
+  llvm::Value *Receiver =
+  CGF.CGM.getObjCRuntime().GetClass(CGF, ObjTy->getInterface());
+  return CGF.EmitObjCAllocInit(Receiver, CGF.ConvertType(OME->getType()));

gparker42 wrote:
> rjmccall wrote:
> > You might need to check for a `super` message send, which can be a class 
> > message send in a class method.
> > 
> > Also, I think `getInterface()` can return null here, although it might need 
> > to be contrived to fit the other requirements.  `Class`, 
> > where that protocol declares `+alloc`?  If there isn't a way to just emit 
> > the receiver pointer of a normal message send from an `ObjCMessageExpr`, 
> > that's really too bad.
> Should this be done inside `tryGenerateSpecializedMessageSend`, or from the 
> same place that calls `tryGenerateSpecializedMessageSend`? That position 
> already rejects `[super …]` call sites, and might make it more obvious how 
> the `objc_alloc` and `objc_alloc_init` optimizations interact. (Currently it 
> takes some digging to verify that the `objc_alloc_init` generator does not 
> need to look for the pattern `[objc_alloc(cls) init]`).
(Never mind, that super check wouldn't help catch `[[super alloc] init]`because 
it's checking `init`'s receiver.)


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57936/new/

https://reviews.llvm.org/D57936



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D57936: [CodeGenObjC] When available, emit a direct call to objc_alloc_init(cls) instead of [objc_alloc(cls) init]

[Greg Parker via Phabricator via cfe-commits]

gparker42 added inline comments.



Comment at: clang/lib/CodeGen/CGObjC.cpp:459
+  llvm::Value *Receiver =
+  CGF.CGM.getObjCRuntime().GetClass(CGF, ObjTy->getInterface());
+  return CGF.EmitObjCAllocInit(Receiver, CGF.ConvertType(OME->getType()));

rjmccall wrote:
> You might need to check for a `super` message send, which can be a class 
> message send in a class method.
> 
> Also, I think `getInterface()` can return null here, although it might need 
> to be contrived to fit the other requirements.  `Class`, where 
> that protocol declares `+alloc`?  If there isn't a way to just emit the 
> receiver pointer of a normal message send from an `ObjCMessageExpr`, that's 
> really too bad.
Should this be done inside `tryGenerateSpecializedMessageSend`, or from the 
same place that calls `tryGenerateSpecializedMessageSend`? That position 
already rejects `[super …]` call sites, and might make it more obvious how the 
`objc_alloc` and `objc_alloc_init` optimizations interact. (Currently it takes 
some digging to verify that the `objc_alloc_init` generator does not need to 
look for the pattern `[objc_alloc(cls) init]`).


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57936/new/

https://reviews.llvm.org/D57936



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D45601: Warn on bool* to bool conversion

[Greg Parker via Phabricator via cfe-commits]

gparker42 added a comment.

Note that we recently relaxed a similar diagnostic for `NSNumber *` in the 
static analyzer. Such code is semantically similar to `inttype *`.
https://reviews.llvm.org/D44044


https://reviews.llvm.org/D45601



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D27214: [ObjC] Encode type arguments in property information string constants

[Greg Parker via Phabricator via cfe-commits]

gparker42 added a comment.

This won't work. The property attribute string consists of comma-separated 
fields. The encoding used here embeds commas into the type value, which will 
break parsing of the attribute string. You'll need to use a separator other 
than a comma.


Repository:
  rL LLVM

https://reviews.llvm.org/D27214



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D34810: [Sema] -Wcomma should not warn for expressions that return void

[Greg Parker via Phabricator via cfe-commits]

gparker42 added a comment.

I thought void-returning functions were supposed to be allowed based on the 
description in https://reviews.llvm.org/D3976 , but later in that discussion 
the definition was changed to instead allow almost nothing.


Repository:
  rL LLVM

https://reviews.llvm.org/D34810



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D28931: Disable aligned new/delete on Apple platforms without posix_memalign

[Greg Parker via Phabricator via cfe-commits]

gparker42 added a comment.

No, the old versions of OS X that lack `posix_memalign` also lack 
`aligned_alloc`.


https://reviews.llvm.org/D28931



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits