On Tue, Oct 6, 2015 at 4:13 PM, Richard Smith <rich...@metafoo.co.uk> wrote:
> On Tue, Oct 6, 2015 at 4:11 PM, Sean Silva <chisophu...@gmail.com> wrote:
>
>> +extern "C++" {
>> +#include <__nullptr>
>> +using std::nullptr_t;
>> +}
>>
>> Does this even compile with modules?
>>
>
> Yes. You're allowed to import a C++ module within an 'extern "C++"' block.
>
Why do we even need `extern "C++"` if we are already under `#ifdef
__cplusplus`?
-- Sean Silva
>
>
>> On Tue, Oct 6, 2015 at 3:57 PM, Richard Smith via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> <stddef.h>. This one is tricky:
>>>
>>> 1) There's an (undocumented) interface between the C standard library
>>> and this header, where the macros __need_ptrdiff_t, __need_size_t,
>>> __need_wchar_t, __need_NULL, __need_wint_t request just a piece of this
>>> header rather than the whole thing. If we see any of those, just go
>>> straight to the underlying header.
>>>
>>> 2) We probably don't want <stddef.h> to include <cstddef> (for
>>> consistency with other headers), but <stddef.h> must provide a ::nullptr_t
>>> (which we don't want <cstddef> to provide). So neither header includes the
>>> other. Instead, both include <__nullptr> for std::nullptr_t, and we
>>> duplicate the definition of max_align_t between them, in the case where the
>>> compiler's <stddef.h> doesn't provide it.
>>>
>>> If you prefer, I could make <stddef.h> include <cstddef> to avoid the
>>> duplication of the max_align_t logic.
>>>
>>> This patch depends on patch 02.
>>>
>>> On Tue, Oct 6, 2015 at 3:42 PM, Richard Smith <rich...@metafoo.co.uk>
>>> wrote:
>>>
>>>> <setjmp.h>, an easy one. We guarantee a setjmp macro exists even if
>>>> this header is somehow included from C (the C standard allows that, so it's
>>>> not worth checking for __cplusplus).
>>>>
>>>> On Tue, Oct 6, 2015 at 3:36 PM, Richard Smith <rich...@metafoo.co.uk>
>>>> wrote:
>>>>
>>>>> Split <math.h> out of <cmath>. This is a big change, but the same
>>>>> pattern as the prior ones.
>>>>>
>>>>> On Tue, Oct 6, 2015 at 3:28 PM, Richard Smith <rich...@metafoo.co.uk>
>>>>> wrote:
>>>>>
>>>>>> Likewise for <errno.h>, <float.h>, <inttypes.h>
>>>>>>
>>>>>> On Tue, Oct 6, 2015 at 3:20 PM, Richard Smith <rich...@metafoo.co.uk>
>>>>>> wrote:
>>>>>>
>>>>>>> Split <ctype.h> header out of <cctype>
>>>>>>>
>>>>>>> On Tue, Oct 6, 2015 at 3:07 PM, Richard Smith <rich...@metafoo.co.uk
>>>>>>> > wrote:
>>>>>>>
>>>>>>>> Next: factoring the definition of std::nullptr_t out into a
>>>>>>>> separate file, so that <cstddef> and <stddef.h> can both use it,
>>>>>>>> without
>>>>>>>> <stddef.h> including <cstddef> and without <cstddef> providing a
>>>>>>>> ::nullptr_t like <stddef.h> does.
>>>>>>>>
>>>>>>>> On Tue, Oct 6, 2015 at 3:02 PM, Eric Fiselier <e...@efcs.ca> wrote:
>>>>>>>>
>>>>>>>>> LGTM.
>>>>>>>>>
>>>>>>>>> On Tue, Oct 6, 2015 at 3:58 PM, Richard Smith <
>>>>>>>>> rich...@metafoo.co.uk> wrote:
>>>>>>>>> > On Mon, Oct 5, 2015 at 7:10 PM, Eric Fiselier <e...@efcs.ca>
>>>>>>>>> wrote:
>>>>>>>>> >>
>>>>>>>>> >> EricWF added a comment.
>>>>>>>>> >>
>>>>>>>>> >> I think thing change will help us close a number out
>>>>>>>>> outstanding bugs. I
>>>>>>>>> >> don't have any fundamental objections to this approach.
>>>>>>>>> However the size of
>>>>>>>>> >> this patch scares me. I understand the changes are mostly
>>>>>>>>> mechanical but
>>>>>>>>> >> their size can hide things. For example has anybody noticed
>>>>>>>>> that your
>>>>>>>>> >> internal changes to `<deque>` are in this patch? It would be
>>>>>>>>> nice to break
>>>>>>>>> >> this down into more digestible pieces that could be quickly
>>>>>>>>> spot checked.
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > OK. First such patch is attached. It just removes the
>>>>>>>>> macro-capturing
>>>>>>>>> > wrapper functions.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> cfe-commits mailing list
>>> cfe-commits@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>>
>>>
>>
>
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
