Page MenuHomePhabricator

[libc++] Make sure std::is_object returns true for block types
ClosedPublic

Authored by ldionne on Jan 14 2020, 8:08 AM.

Details

Summary

This allows blocks to be used in more places, for example in std::optional.

rdar://problem/57892832

Diff Detail

Event Timeline

ldionne created this revision.Jan 14 2020, 8:08 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 14 2020, 8:08 AM
rjmccall added inline comments.
libcxx/include/type_traits
1047

The compiler considers blocks to be scalar types:

enum ScalarTypeKind {
  STK_CPointer,
  STK_BlockPointer,
  STK_ObjCObjectPointer,
  STK_MemberPointer,
  STK_Bool,
  STK_Integral,
  STK_Floating,
  STK_IntegralComplex,
  STK_FloatingComplex,
  STK_FixedPoint
};
rjmccall added inline comments.Jan 14 2020, 9:58 AM
libcxx/include/__config
467

Oh, and blocks are not strictly an Objective-C language extension; I understand that "blocks" is a highly generic term that you may not want to use alone, but calling them "ObjC blocks" may be misleading as well.

ldionne updated this revision to Diff 239416.Jan 21 2020, 12:59 PM

Make sure blocks are scalar types, not object types.

rjmccall accepted this revision.Jan 21 2020, 1:27 PM

Thanks, this looks right, assuming you've decided to continue calling them "objc blocks" despite my comment.

This revision is now accepted and ready to land.Jan 21 2020, 1:27 PM
dexonsmith accepted this revision.Jan 21 2020, 1:32 PM

This LGTM too, but like John I would prefer a non-_OBJC_ name for the macro since -fblocks also gets used with C/C++.

libcxx/include/__config
467

Maybe, _LIBCPP_HAS_EXTENSION_BLOCKS?

ldionne updated this revision to Diff 239463.Jan 21 2020, 5:14 PM

Rename __config macro to _LIBCPP_HAS_EXTENSION_BLOCKS

This revision was automatically updated to reflect the committed changes.