similar to: Appveyor for the LLVM Github Org

> On Apr 20, 2017, at 12:39 AM, Eric Fiselier <eric at efcs.ca> wrote: > > > > On Wed, Apr 19, 2017 at 11:19 PM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: > What would be the status of these buildbots? Is it for your private usage? > > I intend for them to be public Windows buildbots for libc++. I’m not sure

Hi Will, I would like to request collaborator permissions for the Libc++ github mirror. I plan to use the access to setup Appveyor buildbots for libc++. In order to do this I need to be listed as a collaborator on Github. The alternative to Github access would be setting up the correct webhooks for llvm.org/git/libcxx.git, but this seems harder to both do and maintain. /Eric --------------

What would be the status of these buildbots? Is it for your private usage? Otherwise having “project' bots” using a non-official mirror may sound like a strange situation to me. — Mehdi > On Apr 19, 2017, at 5:04 PM, Eric Fiselier via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Adding cfe-dev list... > > On Wed, Apr 19, 2017 at 5:50 PM, Eric Fiselier <eric at

> On Apr 20, 2017, at 12:30 PM, Eric Fiselier <eric at efcs.ca> wrote: > > > > On Thu, Apr 20, 2017 at 11:06 AM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: > >> On Apr 20, 2017, at 12:39 AM, Eric Fiselier <eric at efcs.ca <mailto:eric at efcs.ca>> wrote: >> >> >> >> On Wed, Apr

> On Apr 20, 2017, at 7:03 PM, Eric Fiselier <eric at efcs.ca> wrote: > > > > On Thu, Apr 20, 2017 at 4:55 PM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: > >> On Apr 20, 2017, at 12:30 PM, Eric Fiselier <eric at efcs.ca <mailto:eric at efcs.ca>> wrote: >> >> >> >> On Thu, Apr

Hi, Fragmentation of the bots is not ideal. While I totally understand Eric's reasoning for doing so, and am delighted to see another Windows bot helping to ensure quality code, I think this is a bit of a slippery slope. We already have the main Buildbots, Green Dragon, Chapuni's Bots, a myriad of private bots and now this new bot. I don't think it is reasonable to ask people to

Hi All, I'm working on rewriting libc++'s documentation using Sphinx. Hopefully it will be easier to write and maintain documentation using restructured text and not HTML. What steps do I need to take to get libc++ a Sphinx builder and get the required changes made for libcxx.llvm.org? /Eric

Hi Eric, On 20 July 2015 at 10:41, Eric Fiselier <eric at efcs.ca> wrote: > Hi All, > > I'm working on rewriting libc++'s documentation using Sphinx. > Hopefully it will be easier to write and maintain documentation using > restructured text and not HTML. > > What steps do I need to take to get libc++ a Sphinx builder and get > the required changes made for

And here we go: http://lab.llvm.org:8011/builders/libcxx-libcxxabi-arm-linux There are only 11 failures, which seem reasonably trivial to fix (missing symbols and asserts). I'll be looking into them, but if you have any clue, tips are welcome! Thanks everyone for the help and support! cheers, --renato

On Fri, Jul 31, 2015 at 12:01 AM, Dan Liew <dan at su-root.co.uk> wrote: > Hi Eric, > > On 20 July 2015 at 10:41, Eric Fiselier <eric at efcs.ca> wrote: >> Hi All, >> >> I'm working on rewriting libc++'s documentation using Sphinx. >> Hopefully it will be easier to write and maintain documentation using >> restructured text and not HTML.

CC Tanya and ping. On Mon, Jul 20, 2015 at 1:41 PM, Eric Fiselier <eric at efcs.ca> wrote: > Hi All, > > I'm working on rewriting libc++'s documentation using Sphinx. > Hopefully it will be easier to write and maintain documentation using > restructured text and not HTML. > > What steps do I need to take to get libc++ a Sphinx builder and get > the required

cmake -E cmake_progress_report llvm-3.8.0.src_bld_x86_64-rhel6.4-linux-gnu/CMakeFiles In file included from llvm-3.8.0.src/projects/libcxx/include/__hash_table:19:0, from llvm-3.8.0.src/projects/libcxx/src/hash.cpp:10: llvm-3.8.0.src/projects/libcxx/include/cmath:310:9: error: '::signbit' has not been declared using ::signbit; ^

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

If you're willing to install libc++ you can easily work around this by running `ninja install-cxx install-cxxabi` before running any of the LLVM or Clang build targets. /Eric On Tue, Dec 27, 2016 at 7:45 AM, Carsten Mattner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Tue, Dec 27, 2016 at 3:38 PM, Asiri Rathnayake > <asiri.rathnayake at gmail.com> wrote: >

FWIW, I’d like for us to come to an agreement before the branch for LLVM 7.0 is cut. How do others feel about this? Am I wrong when I claim that shipping an ABI-unstable feature in the std:: namespace is a deviation from normal practice? Am I overcautious when I say it’s asking for trouble? Eric, I know you’re busy and may not have time to do the work so I’m totally willing to chime in, but I’d

Why did you want the symbols moved out of libc++experimental, and for the header to be moved from <experimental/filesystem> to <filesystem>? It certainly seems like it'd be safer and clearer to move them back to the old locations, but it's not clear to me if that'd be trading off something else of value. Was there some other greater purpose served by the change in

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, My current understanding of the problem (based on https://reviews.llvm.org/D49774) is that we have a type, file_time_type, which is part of the ABI and is currently defined as std::chrono::time_point<_FileSystemClock>, where _FileSystemClock is an internal type represented using a __int128_t. However, C++20 will add a type called file_clock and redefine file_time_type to be

I'm seeing some test failures for unit tests for msan (check-msan) happening in googletest, which I find weird. I'm on Arch Linux, with r342711. Below is one type of error that I see. The full log is 416MB (!) big. My guess is that those errors are related, but if anyone needs the full log, I'll provide it. Here is a reduced log from the end:

> On Feb 20, 2020, at 14:25, Johannes Doerfert <johannesdoerfert at gmail.com> wrote: > > On 02/20, Louis Dionne via llvm-dev wrote: >> I know there has been significant discussion about "moving" from >> Phabricator to GitHub reviews and pull requests, etc. I'm not >> suggesting that we do anything in terms of global LLVM policy. >> However, as