Page MenuHomePhabricator

ldionne (Louis Dionne)
User

Projects

User does not belong to any projects.

User Details

User Since
Feb 11 2015, 3:26 PM (210 w, 2 d)

Recent Activity

Today

ldionne committed rCXX354725: [libcxx] Make sure all experimental tests are disabled when….
[libcxx] Make sure all experimental tests are disabled when…
Sat, Feb 23, 3:27 AM
ldionne committed rG73be0cb773ca: [libcxx] Make sure all experimental tests are disabled when… (authored by ldionne).
[libcxx] Make sure all experimental tests are disabled when…
Sat, Feb 23, 3:24 AM
ldionne committed rL354725: [libcxx] Make sure all experimental tests are disabled when….
[libcxx] Make sure all experimental tests are disabled when…
Sat, Feb 23, 3:24 AM
ldionne closed D55834: [libcxx] Make sure all experimental tests are disabled when enable_experimental=False.
Sat, Feb 23, 3:24 AM · Restricted Project

Yesterday

ldionne created D58558: [libc++] Rename _NOALIAS macro to _LIBCPP_NOALIAS.
Fri, Feb 22, 3:56 PM
ldionne committed rGc2d95792d64b: [clang] Only provide C11 features in <float.h> starting with C++17 (authored by ldionne).
[clang] Only provide C11 features in <float.h> starting with C++17
Fri, Feb 22, 12:49 PM
ldionne committed rC354691: [clang] Only provide C11 features in <float.h> starting with C++17.
[clang] Only provide C11 features in <float.h> starting with C++17
Fri, Feb 22, 12:49 PM
ldionne committed rL354691: [clang] Only provide C11 features in <float.h> starting with C++17.
[clang] Only provide C11 features in <float.h> starting with C++17
Fri, Feb 22, 12:49 PM
ldionne closed D58289: [clang] Only provide C11 features in <float.h> starting with C++17.
Fri, Feb 22, 12:48 PM · Restricted Project, Restricted Project

Thu, Feb 21

ldionne added a comment to D57670: [CMake] Support CMake variables for setting target, sysroot and toolchain.

I believe this broke building libunwind standalone for me since it complains about add_target_flags() not being defined. I guess it also needs to be copied to the libunwind cmake files?

Thu, Feb 21, 10:57 AM · Restricted Project

Wed, Feb 20

ldionne committed rG431cfbf17281: [NFC] Fix incorrect comment in std::function test (authored by ldionne).
[NFC] Fix incorrect comment in std::function test
Wed, Feb 20, 4:53 PM
ldionne committed rCXX354537: [NFC] Fix incorrect comment in std::function test.
[NFC] Fix incorrect comment in std::function test
Wed, Feb 20, 4:53 PM
ldionne committed rL354537: [NFC] Fix incorrect comment in std::function test.
[NFC] Fix incorrect comment in std::function test
Wed, Feb 20, 4:53 PM

Tue, Feb 19

ldionne added a comment to D58203: [libc++] Inline stdexcept constructors, destructors, and assignment operators when using MSVC ABI.

Question: Why do we define those (almost trivial) functions in the dylib? It seems like those should always be in the headers?

Tue, Feb 19, 5:05 PM

Mon, Feb 18

ldionne accepted D58333: [libcxxabi][CMake] Drop unused HandleOutOfTreeLLVM include.
Mon, Feb 18, 10:56 AM · Restricted Project

Fri, Feb 15

ldionne added inline comments to D55840: P0722R3: Implement library support for destroying delete.
Fri, Feb 15, 12:12 PM
ldionne committed rPSTL354148: [pstl] Remove some warnings when compiling with a recent Clang.
[pstl] Remove some warnings when compiling with a recent Clang
Fri, Feb 15, 9:50 AM
ldionne changed the repository for D58289: [clang] Only provide C11 features in <float.h> starting with C++17 from rCXX libc++ to rC Clang.
Fri, Feb 15, 9:42 AM · Restricted Project, Restricted Project
ldionne added a comment to D58149: [clang] Make sure C99/C11 features in <float.h> are provided in C++11.

I agree with the comments. I think we should strive to be strictly conforming. I make that argument all the time for libc++, so I'll be consistent :-).

Fri, Feb 15, 9:41 AM · Restricted Project
ldionne created D58289: [clang] Only provide C11 features in <float.h> starting with C++17.
Fri, Feb 15, 9:41 AM · Restricted Project, Restricted Project
ldionne committed rG28dc566701a5: [pstl] Remove some warnings when compiling with a recent Clang (authored by ldionne).
[pstl] Remove some warnings when compiling with a recent Clang
Fri, Feb 15, 9:33 AM
ldionne committed rL354148: [pstl] Remove some warnings when compiling with a recent Clang.
[pstl] Remove some warnings when compiling with a recent Clang
Fri, Feb 15, 9:33 AM
ldionne requested changes to D58201: Make std::memory_order an enum class (P0439R0).
Fri, Feb 15, 9:19 AM
ldionne accepted D58272: Add .gitignore.
Fri, Feb 15, 7:18 AM

Wed, Feb 13

ldionne added a comment to D58149: [clang] Make sure C99/C11 features in <float.h> are provided in C++11.
In D58149#1397390, @jfb wrote:

Formally, I don't think C11 is a normative reference for C++11 or C++14, only C++17 (see [intro.refs] in the standard).

Wed, Feb 13, 5:08 PM · Restricted Project
ldionne added a comment to D50106: [libc++] Fix tuple assignment from type derived from a tuple-like.

Our constructors still have the same bug,. Are you planning on fixing those as well? Doing so will require a metric butt-tonne of overloads.
If you're not planning on fixing the constructors, then can you explain why it's better that we're inconsistent?

Wed, Feb 13, 1:00 PM
ldionne requested changes to D58019: Add is_nothrow_convertible (P0758R1).

This is looking better and better.

Wed, Feb 13, 12:03 PM
ldionne updated the diff for D54722: [libcxx] Make sure reference_wrapper works with incomplete types.

Rebase onto master and update the licenses to the new license. Ping!

Wed, Feb 13, 11:50 AM
ldionne requested changes to D57403: Extending make_shared to Support Arrays (Partially) - P0674R1.

This is a good start, but please make sure you implement and test the full paper.

Wed, Feb 13, 11:40 AM
ldionne committed rGdefa9f8f85cf: [clang] Make sure C99/C11 features in <float.h> are provided in C++11 (authored by ldionne).
[clang] Make sure C99/C11 features in <float.h> are provided in C++11
Wed, Feb 13, 11:08 AM
ldionne committed rL353970: [clang] Make sure C99/C11 features in <float.h> are provided in C++11.
[clang] Make sure C99/C11 features in <float.h> are provided in C++11
Wed, Feb 13, 11:07 AM
ldionne committed rC353970: [clang] Make sure C99/C11 features in <float.h> are provided in C++11.
[clang] Make sure C99/C11 features in <float.h> are provided in C++11
Wed, Feb 13, 11:07 AM
ldionne closed D58149: [clang] Make sure C99/C11 features in <float.h> are provided in C++11.
Wed, Feb 13, 11:07 AM · Restricted Project
ldionne added a comment to D58149: [clang] Make sure C99/C11 features in <float.h> are provided in C++11.

I'll ship this. @eli.friedman I think this is your playground -- if you want any changes to happen post-review, please LMK and I will gladly cooperate.

Wed, Feb 13, 11:05 AM · Restricted Project
ldionne accepted D56913: decoupling Freestanding atomic<T> from libatomic.a.

LGTM, with some de-duplication suggested. I'm not an atomic wrangler, though, so I'd feel more comfortable if someone like @jfb could quickly double-check the implementation of the atomic operations.

Wed, Feb 13, 10:18 AM
ldionne added a reviewer for D58140: [libc++] Enable deprecation warnings by default: aaron.ballman.
Wed, Feb 13, 10:09 AM
ldionne committed rG95601bdd2970: [libcxx] Do not assume the number of elements in a moved-from associative… (authored by ldionne).
[libcxx] Do not assume the number of elements in a moved-from associative…
Wed, Feb 13, 8:44 AM
ldionne committed rCXX353955: [libcxx] Do not assume the number of elements in a moved-from associative….
[libcxx] Do not assume the number of elements in a moved-from associative…
Wed, Feb 13, 8:44 AM
ldionne committed rL353955: [libcxx] Do not assume the number of elements in a moved-from associative….
[libcxx] Do not assume the number of elements in a moved-from associative…
Wed, Feb 13, 8:43 AM
ldionne closed D57903: [libcxx] Add missing checks to tests for the move w/allocator constructors of associative containers..

r353955

Wed, Feb 13, 8:43 AM
ldionne accepted D57903: [libcxx] Add missing checks to tests for the move w/allocator constructors of associative containers..
Wed, Feb 13, 8:38 AM

Tue, Feb 12

ldionne created D58149: [clang] Make sure C99/C11 features in <float.h> are provided in C++11.
Tue, Feb 12, 2:25 PM · Restricted Project
ldionne requested changes to D57903: [libcxx] Add missing checks to tests for the move w/allocator constructors of associative containers..
Tue, Feb 12, 1:33 PM
ldionne updated the diff for D58140: [libc++] Enable deprecation warnings by default.

Added missing #defines in tests

Tue, Feb 12, 12:26 PM
ldionne added a comment to D58140: [libc++] Enable deprecation warnings by default.

I'd like to enable this early in the LLVM 9 cycle.

Tue, Feb 12, 12:02 PM
ldionne created D58140: [libc++] Enable deprecation warnings by default.
Tue, Feb 12, 11:25 AM
ldionne added a comment to D58019: Add is_nothrow_convertible (P0758R1).

@ldionne just for reference, this is what it would look like to use is_nothrow_constructible:

 template <typename _Fm, typename _To>
 struct is_nothrow_convertible : __and_<
     is_convertible<_Fm, _To>,
     __libcpp_is_nothrow_constructible<true, true, _Fm, _To>
>::type { };
Tue, Feb 12, 10:46 AM
ldionne added inline comments to D57903: [libcxx] Add missing checks to tests for the move w/allocator constructors of associative containers..
Tue, Feb 12, 9:53 AM
ldionne requested changes to D58019: Add is_nothrow_convertible (P0758R1).
Tue, Feb 12, 9:37 AM
ldionne added inline comments to D55840: P0722R3: Implement library support for destroying delete.
Tue, Feb 12, 9:31 AM
ldionne added a comment to D55840: P0722R3: Implement library support for destroying delete.

Question:

In C++20 we should declare destroying_delete_t, even if __cpp_impl_destroying_delete isn't defined.
But in that case should be define __cpp_lib_destroying_delete? The library has the type, but users
can't actually perform destroying delete.

Since __cpp_impl_destroyng_delete isn't for users, but __cpp_lib_destroying_delete is, then I don't think we should define it unless the compiler actually provides the language feature.

Tue, Feb 12, 9:30 AM
ldionne committed rG7232a84e686a: [libc++] Avoid UB in the no-exceptions mode in a few places (authored by ldionne).
[libc++] Avoid UB in the no-exceptions mode in a few places
Tue, Feb 12, 8:06 AM
ldionne committed rCXX353850: [libc++] Avoid UB in the no-exceptions mode in a few places.
[libc++] Avoid UB in the no-exceptions mode in a few places
Tue, Feb 12, 8:06 AM
ldionne committed rL353850: [libc++] Avoid UB in the no-exceptions mode in a few places.
[libc++] Avoid UB in the no-exceptions mode in a few places
Tue, Feb 12, 8:06 AM
ldionne closed D57761: [libc++] Avoid UB in the no-exceptions mode in a few places.
Tue, Feb 12, 8:06 AM · Restricted Project

Mon, Feb 11

ldionne added a comment to D57761: [libc++] Avoid UB in the no-exceptions mode in a few places.

@mclow.lists @jfb I added tests per your request. Please LMK if this is satisfactory.

Mon, Feb 11, 1:08 PM · Restricted Project
ldionne updated the diff for D57761: [libc++] Avoid UB in the no-exceptions mode in a few places.

Added tests for the abort() behavior and fixed UB I had missed in map::at().

Mon, Feb 11, 1:07 PM · Restricted Project
ldionne added a comment to D49863: [istream] Fix error flags and exceptions propagated from input stream operations.

I would like to merge this even though http://wg21.link/p1264 has not been voted into C++ yet, because this is arguably a bug and libc++ differs from other stdlibs in this regard. Once http://wg21.link/p1264 is merged into C++ in one way of another, libc++ will simply have nothing to do.

Mon, Feb 11, 1:05 PM
ldionne committed rPSTL353727: [NFC] Fix typo in PSTL test.
[NFC] Fix typo in PSTL test
Mon, Feb 11, 11:34 AM
ldionne requested changes to D56913: decoupling Freestanding atomic<T> from libatomic.a.

Here's a summary of what I understand the current state of the patch is (mostly for my own reference as a bird's eye view):

Mon, Feb 11, 10:47 AM
ldionne committed rG41cc52d590d4: [NFC] Fix typo in PSTL test (authored by ldionne).
[NFC] Fix typo in PSTL test
Mon, Feb 11, 9:47 AM
ldionne committed rL353727: [NFC] Fix typo in PSTL test.
[NFC] Fix typo in PSTL test
Mon, Feb 11, 9:47 AM
ldionne closed D57887: [pstl] fix comment typos in test.

Committed as r353727.

Mon, Feb 11, 9:47 AM
ldionne accepted D57887: [pstl] fix comment typos in test.

Thanks for the patch.

Mon, Feb 11, 9:44 AM
ldionne added a comment to D58019: Add is_nothrow_convertible (P0758R1).

Actually, I'm looking at this and std::is_convertible again, and I think this should be using std::is_convertible in the implementation. I know the paper suggests the implementation in this patch, however it's unclear to me whether that implementation properly handles all the cases that std::is_convertible handles (notably with references). Also, using std::is_convertible under the hood means that we will use the __is_convertible_to intrinsic when it's available instead.

Mon, Feb 11, 9:35 AM
ldionne added a comment to D58011: Fix -fsanitize=vptr badness in <__debug>.

The fix requires unconditionally breaking the debug mode ABI. Users should not expect ABI stability from debug mode.

Mon, Feb 11, 9:19 AM · Restricted Project
ldionne requested changes to D58019: Add is_nothrow_convertible (P0758R1).
Mon, Feb 11, 9:07 AM

Wed, Feb 6

ldionne committed rGfeeedafd28b9: Revert "[libc++] Only add dylib-related features when using the system's libc++" (authored by ldionne).
Revert "[libc++] Only add dylib-related features when using the system's libc++"
Wed, Feb 6, 10:33 AM
ldionne committed rCXX353321: Revert "[libc++] Only add dylib-related features when using the system's libc++".
Revert "[libc++] Only add dylib-related features when using the system's libc++"
Wed, Feb 6, 10:32 AM
ldionne committed rL353321: Revert "[libc++] Only add dylib-related features when using the system's libc++".
Revert "[libc++] Only add dylib-related features when using the system's libc++"
Wed, Feb 6, 10:32 AM
ldionne committed rG6f6beae627b2: [libc++] Only add dylib-related features when using the system's libc++ (authored by ldionne).
[libc++] Only add dylib-related features when using the system's libc++
Wed, Feb 6, 10:08 AM
ldionne committed rCXX353319: [libc++] Only add dylib-related features when using the system's libc++.
[libc++] Only add dylib-related features when using the system's libc++
Wed, Feb 6, 10:06 AM
ldionne committed rL353319: [libc++] Only add dylib-related features when using the system's libc++.
[libc++] Only add dylib-related features when using the system's libc++
Wed, Feb 6, 10:06 AM
ldionne added a comment to D56913: decoupling Freestanding atomic<T> from libatomic.a.

I will come back with another patch that addresses these comments.

Wed, Feb 6, 9:13 AM

Tue, Feb 5

ldionne added a comment to D56913: decoupling Freestanding atomic<T> from libatomic.a.

I like where this is going generally speaking, but there's a couple of things I'd like to understand. It would also be great if other maintainers with more experience could chime in regarding the rename of __c11_atomic_xxx to __cxx_atomic_xxx -- is this removing functionality that we're providing (but we shouldn't be providing :-)?

Tue, Feb 5, 2:34 PM
ldionne committed rGa53eb79be683: [libc++] Fix XFAILs when exceptions are disabled (authored by ldionne).
[libc++] Fix XFAILs when exceptions are disabled
Tue, Feb 5, 12:56 PM
ldionne committed rL353215: [libc++] Fix XFAILs when exceptions are disabled.
[libc++] Fix XFAILs when exceptions are disabled
Tue, Feb 5, 12:55 PM
ldionne committed rCXX353215: [libc++] Fix XFAILs when exceptions are disabled.
[libc++] Fix XFAILs when exceptions are disabled
Tue, Feb 5, 12:55 PM
ldionne committed rGf5f2f7775507: [libc++] Fix XFAILs on macOS when exceptions are disabled (authored by ldionne).
[libc++] Fix XFAILs on macOS when exceptions are disabled
Tue, Feb 5, 12:13 PM
ldionne committed rL353210: [libc++] Fix XFAILs on macOS when exceptions are disabled.
[libc++] Fix XFAILs on macOS when exceptions are disabled
Tue, Feb 5, 12:12 PM
ldionne committed rCXX353210: [libc++] Fix XFAILs on macOS when exceptions are disabled.
[libc++] Fix XFAILs on macOS when exceptions are disabled
Tue, Feb 5, 12:12 PM
ldionne committed rGbb6d61c75207: [libc++] Use UNSUPPORTED instead of TEST_STD_VER #ifdef (authored by ldionne).
[libc++] Use UNSUPPORTED instead of TEST_STD_VER #ifdef
Tue, Feb 5, 11:50 AM
ldionne committed rCXX353206: [libc++] Use UNSUPPORTED instead of TEST_STD_VER #ifdef.
[libc++] Use UNSUPPORTED instead of TEST_STD_VER #ifdef
Tue, Feb 5, 11:50 AM
ldionne closed D57704: [libcxx] Tests cleanup: use UNSUPPORTED instead of TEST_STD_VER..

Thanks for the patch! Committed as r353206.

Tue, Feb 5, 11:50 AM
ldionne committed rL353206: [libc++] Use UNSUPPORTED instead of TEST_STD_VER #ifdef.
[libc++] Use UNSUPPORTED instead of TEST_STD_VER #ifdef
Tue, Feb 5, 11:50 AM
ldionne accepted D57704: [libcxx] Tests cleanup: use UNSUPPORTED instead of TEST_STD_VER..
Tue, Feb 5, 11:50 AM
ldionne committed rG51358e45e23e: [libcxx] Start defining lit features for tests depending on availability (authored by ldionne).
[libcxx] Start defining lit features for tests depending on availability
Tue, Feb 5, 11:23 AM
ldionne committed rL353201: [libcxx] Start defining lit features for tests depending on availability.
[libcxx] Start defining lit features for tests depending on availability
Tue, Feb 5, 11:23 AM
ldionne committed rCXX353201: [libcxx] Start defining lit features for tests depending on availability.
[libcxx] Start defining lit features for tests depending on availability
Tue, Feb 5, 11:23 AM
ldionne added a comment to D57734: priority_queue::replace_top(x).

@Quuxplusone Please re-ping this when/if this feature makes it into the standard so that we avoid re-doing the work.

Tue, Feb 5, 11:21 AM · Restricted Project
ldionne added a comment to D57734: priority_queue::replace_top(x).

I think this functionality might be interesting, but trying to get this into libc++ before it is standardized is definitely putting the cart before the horse. I understand that putting the patch here may make it easier for people to apply it to their local copy of libc++. Hopefully not many people think of themselves as vendors and maintain their own libc++ :-).

Tue, Feb 5, 11:19 AM · Restricted Project
ldionne added a comment to D57761: [libc++] Avoid UB in the no-exceptions mode in a few places.
In D57761#1385646, @jfb wrote:

I don't think this patch really needs to fix the tests, but I think the tests need a bit of love for this odd use case.

Tue, Feb 5, 11:11 AM · Restricted Project
ldionne added a comment to D57761: [libc++] Avoid UB in the no-exceptions mode in a few places.
In D57761#1385562, @jfb wrote:

I'm wondering if, as a follow-up, the XFAIL tests that validate the behavior for exceptions should instead:

  • Not XFAIL
  • Install a SIGABORT handler, and call exit(0) or something
  • Instead of catch, call exit(1) because we expected the abort handler to be called.

    That type of testing will find any missing fixes from this patch (and prevent regressions).
Tue, Feb 5, 10:53 AM · Restricted Project
ldionne added a comment to D57761: [libc++] Avoid UB in the no-exceptions mode in a few places.

Here's the justification for changes in this patch.

Tue, Feb 5, 9:30 AM · Restricted Project
ldionne created D57761: [libc++] Avoid UB in the no-exceptions mode in a few places.
Tue, Feb 5, 9:19 AM · Restricted Project
ldionne committed rGa3ec627a1c60: [libc++] Control whether exceptions are enabled in the macOS trunk testing… (authored by ldionne).
[libc++] Control whether exceptions are enabled in the macOS trunk testing…
Tue, Feb 5, 8:44 AM
ldionne committed rL353185: [libc++] Control whether exceptions are enabled in the macOS trunk testing….
[libc++] Control whether exceptions are enabled in the macOS trunk testing…
Tue, Feb 5, 8:43 AM
ldionne committed rCXX353185: [libc++] Control whether exceptions are enabled in the macOS trunk testing….
[libc++] Control whether exceptions are enabled in the macOS trunk testing…
Tue, Feb 5, 8:42 AM
ldionne committed rGb3b896811730: [NFC][libc++] Reindent function (authored by ldionne).
[NFC][libc++] Reindent function
Tue, Feb 5, 7:47 AM
ldionne committed rCXX353180: [NFC][libc++] Reindent function.
[NFC][libc++] Reindent function
Tue, Feb 5, 7:47 AM