similar to: RFC: Plan for removing components from namespace std::experimental

I second Justin's suggestion, but would that happen in LLVM 5 or 6? Just as something to consider, it may also cause spurious errors for people who are relying on the at-version-stability of experimental libraries, causing them to turn off warnings for deprecated code. As C Bergstrom has said, users buy into experimental libraries with the knowledge that the interface or behaviour could

On Mon, Apr 10, 2017 at 1:22 PM, Marshall Clow <mclow.lists at gmail.com> wrote: > As part of the work on C++17, WG21 released a series of "Technical > Specifications", (TS) which added proposed new features to the standard > library. These were all defined in the namespace 'std::experimental' (and > namespaces inside of that). > > Then, much of these

> On Aug 10, 2018, at 13:28, Marshall Clow via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > > > On Thu, Jul 26, 2018 at 9:20 PM, Eric Fiselier via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote: > Hi All, > > I recently committed <filesystem> to trunk. I wanted to bring attention to some quirks it currently has.

On Feb 14, 2014, at 1:09 PM, Howard Hinnant <hhinnant at apple.com> wrote: > Author: hhinnant > Date: Fri Feb 14 15:09:01 2014 > New Revision: 201432 > > URL: http://llvm.org/viewvc/llvm-project?rev=201432&view=rev > Log: Remove myself as owner of libc++ > > Modified: > llvm/trunk/CODE_OWNERS.TXT > > Modified: llvm/trunk/CODE_OWNERS.TXT > URL:

Hi All, I recently committed <filesystem> to trunk. I wanted to bring attention to some quirks it currently has. First, it's been put in a separate library, libc++fs, for now. Users are responsible for linking the library when they use filesystem. Second, it should still not be considered ABI stable. Vendors should be aware of this before shipping it. Hopefully all the standard and

<dynarray> was added to the C++14 standard, libc++ implemented it, and then it was removed. Now (from the standard’s point of view), it is in limbo. I would like to move it into std/experimental; to make it clear that it’s not a part of the standard. Any objections? Anyone using it? — Marshall

The upcoming C++1z (probably C++17) standard will not contain several things - most notably auto_ptr. Soon, libc++ will not be providing auto_ptr by default when building in C++1z mode. You'll be able to get it back with a "-D_LIBCPP_ENABLE_CXX17_REMOVED_AUTO_PTR" on your command line, or "#define _LIBCPP_ENABLE_CXX17_REMOVED_AUTO_PTR" before including any libc++ header

LLVM developers: Does anyone have time and interest to review a libc++ change? https://reviews.llvm.org/D26920 Eric

On Wed, Jun 3, 2015 at 12:21 AM, Nick Lewycky <nlewycky at google.com> wrote: > On 1 June 2015 at 07:20, Marshall Clow <mclow.lists at gmail.com> wrote: > >> This weekend, I got an email from Nuno Lopes informing me that UBSAN now >> paid attention to attribute(nonnull), and he was having some problems with >> it going off when using libc++. >> > >

This weekend, I got an email from Nuno Lopes informing me that UBSAN now paid attention to attribute(nonnull), and he was having some problems with it going off when using libc++. I did some investigation, and found that he was exactly right - there were places (deep inside the vector code, for example) which called std::memcpy(null, null, 0) - which is definitely UB. In an ideal world, our C

On Fri, Feb 14, 2014 at 1:29 PM, Howard Hinnant <hhinnant at apple.com> wrote: > On Feb 14, 2014, at 4:23 PM, Marshall Clow <mclow.lists at gmail.com> wrote: > >> On Feb 14, 2014, at 1:09 PM, Howard Hinnant <hhinnant at apple.com> wrote: >> >>> Author: hhinnant >>> Date: Fri Feb 14 15:09:01 2014 >>> New Revision: 201432 >>>

Binutils and LLVM As part of "owning our own toolchain", various people have expressed an interest and have been working on creating various tools that duplicate the functionality of tools available on other systems. As a start, I'd like to summarize the current status, and ask people for help updating the list. List taken from <http://www.gnu.org/software/binutils/>

On Mon, Jun 01, 2015 at 10:52:20AM -0700, Marshall Clow wrote: > P.S. recent gcc (at least 4.8.x and later) make optimizations based on > this UB (i.e, if you pass a pointer to memcpy, then it can't be NULL). BTW, this seems to be more an issue with glibc adding the tagging and not behavior of GCC itself. Joerg

On Wed, Jun 26, 2019 at 10:27 AM JF Bastien <jfbastien at apple.com> wrote: >> 3. If there is a specification, we should follow it. The scope that we need includes most of the C Standard Library; POSIX additions; and some necessary, system-specific extensions. This does not mean we should (or can) follow the entire specification -- there will be some parts which simply aren't worth

On Fri, Feb 20, 2015 at 7:02 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > 2. We need to clarify how libstdc++ and libsupc++ can be used as > > libc++'s ABI library and explicitly define the level of support for > > these configurations. Are there any people using this functionality? > > These configurations have been broken for GCC >= 4.9.2 and I haven't

David Jones <dlj at google.com> writes: > >> * Provide C symbols as specified by the standards, but take advantage > >> and use C++ language facilities for the core implementation. > > Does this mean C programs would require a C++ runtime? If not, how will > the project ensure that? > > Shooting from the hip: no. Turning off exceptions, RTTI, and static

On Mon, Jun 01, 2015 at 09:57:17AM -0700, Reid Kleckner wrote: > Why should memset / memcpy be attribute nonnull? Is there standardese that > supports that? The generic entry text of the standard section. IMO this is a standard bug and someone should *please* get it fixed. It is ridiculous that zero sized operations are considered UB. Joerg

# Everything is done on Mac OS X 10.8.4, with llvm/clang/libc++/libc++abi built from source this morning # totclang is an alias for the built clang. $ export LLVM=/Sources/LLVM $ export LIBCXX=$LLVM/libcxx $ export LIBCXXABI=$LLVM/libcxxabi $ totclang -std=c++11 -stdlib=libc++ -I $LIBCXX/include -fsanitize=undefined ubsan.cpp -L $LIBCXX/lib -L $LIBCXXABI/lib -lc++abi $

Marshall, you're the owner here. Is this OK to merge? On Sat, Feb 7, 2015 at 8:39 AM, Dimitry Andric <dimitry at andric.com> wrote: > Yes, please. > > -Dimitry > >> On 06 Feb 2015, at 16:07, Eric Fiselier <eric at efcs.ca> wrote: >> >> Hi all, >> >> I would really like to get a patch into 3.6 for libc++. The patch >> renames

Hi All, Currently libc++ does not list linux as a supported platform. This should change. I think we should be able to list linux (with libc++abi) as a supported configuration. but there are some issues I would like to see resolved first. 1. We should add CMake support for building libc++ against a static libc++abi. If libc++ is linked to a shared libc++abi the resulting library can only be used