[cfe-dev] [libc++] RFC: Add Windows kernel support and partial MSVC 2015 support

[Eric Fiselier via cfe-dev]

>
>
> What kind of static asserts? Can you provide an example?
>
> What I had in mind here was for the first line of inplace_merge (and other
> allocating algorithms) to be something along the lines of
> static_assert(!_LIBCPP_HAS_NO_ALLOC).  I think you had a much better
> suggestion though…
>

The algorithms all use std::get_temporary_buffer to allocate memory, and
IIRC all of the algorithms should still work if std::get_temporary_buffer
returns no additional memory. In this particular case I think it would be
better to patch get_temporary_buffer and leave the algorithms as-is.

All other allocation cases that need static_assert should be handled by the
std::allocation suggestion.


> >> * I'll also need to figure out how to not drag along unwanted header
> dependencies.
>
>
>
> > I don't see how libc++ could upstream changes since it requires every
> header
>
> > it currently includes (modulo bugs).
>
> The straightforward (and labor intensive) way is with #ifdef
> _LIBCPP_HAS_NO_ALLOC
>
>
>
>
>
> _LIBCPP_HAS_NO_ALLOC is exactly the invasive change I wanted to avoid.
> First <new> is currently a freestanding header,
>
> and I think it should stay that way. Second I want to avoid the
> maintenance cost of such a restrictive
>
> configuration. This macro would have to guard the the vast majority of the
> library, unlike
>
> _LIBCPP_HAS_EXCEPTIONS and _LIBCPP_NO_RTTI which have a much smaller and
> more manageable scope.
>
>
>
> If the end goal is simply to diagnose when end users use features that
> dynamically allocate I suspect there
>
> are less invasive ways to do it. First there are two important things to
> note:
>
>
>
> (1) Libc++ has very few naked new/delete calls. Almost all dynamic
> allocations go through std::allocator.
>
> (2) std::allocator is typically used in dependent contexts (templates).
>
>
>
> Instead of #ifdef'ing out std::allocator and everything that uses it, we
> could make instantiating std::allocator::allocate
>
> produce a diagnostic. This would make the changes needed within libc++
> significantly smaller while still
>
> producing reasonable diagnostics when users attempt to use those types.
>
>
>
> Putting a static assert (or some other kind of diagnostic) in
> std::allocator::allocate seems like an excellent idea to me.  I’d also want
> to hunt down the other places where raw new is used, but I think this
> approach has a lot of promise.
>

I think most usages of raw new could be made to use std::allocator instead,
so they wouldn't have to be handled separately.


> We can document what we officially support, but say that other things
> might work.  If someone instantiates code that hits std::allocator, they
> will get a static assert.  If they write their own code that calls new or
> delete, they will get a linker error (in the Windows Kernel at least).
>

If me manage to make libc++ always use std::allocator instead of raw new
then it might be feasible to mark the new/delete definitions as
unavailable, since they would only have one caller internally. This would
allow usages to be diagnosed at compile-time instead of link-time. It would
also ensure that replacement definitions of new/delete are not found at
link time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170329/368a2aa8/attachment.html>