[PATCH] D31413: [libc++] Use __attribute__((init_priority(101))) to ensure streams get initialized early

ldionne added a comment. In D31413#2279182 , @aaron.ballman wrote: > Yes, and the way I would handle this is to change the `init_priority` value > checking to allow values <= 100 if the attribute location is within a system > header. This would allow li

[PATCH] D68364: Prototype implementation of P0784R7: mark all members of std::allocator and std::allocator_traits as constexpr.

ldionne updated this revision to Diff 292600. ldionne added a comment. Herald added a reviewer: libc++. Complete implementation of P0784 with tests Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D68364/new/ https://reviews.llvm.org/D68364 Files: l

[PATCH] D68364: Implement C++20's P0784 (More constexpr containers)

ldionne added a comment. In D68364#2280187 , @rsmith wrote: > The mechanism by which this interacts with Clang looks good to me. Excellent. > I've not done any detailed analysis to check all the functions made > `constexpr` by P0784 are handled by this

[PATCH] D68364: Implement C++20's P0784 (More constexpr containers)

ldionne added inline comments. Comment at: libcxx/include/version:254 // # define __cpp_lib_concepts 201806L +# define __cpp_lib_constexpr_dynamic_alloc 201907L // # define __cpp_lib_constexpr_misc 201811L -

[PATCH] D68364: Implement C++20's P0784 (More constexpr containers)

ldionne added a subscriber: jwakely. ldionne added inline comments. Comment at: libcxx/include/new:243 # ifdef _LIBCPP_HAS_NO_BUILTIN_OVERLOADED_OPERATOR_NEW_DELETE return ::operator new(__size, __align_val); # else This breaks GCC (as of GCC 9). I don't k

[PATCH] D68364: Implement C++20's P0784 (More constexpr containers)

ldionne updated this revision to Diff 293429. ldionne added a comment. Add some tests from D69134 . Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D68364/new/ https://reviews.llvm.org/D68364 Files: libcxx/docs/Feat

[PATCH] D68364: Implement C++20's P0784 (More constexpr containers)

ldionne accepted this revision as: libc++. ldionne added a comment. I'll go ahead and ship this even though I know it will cause problems on GCC. Comment at: libcxx/include/new:243 # ifdef _LIBCPP_HAS_NO_BUILTIN_OVERLOADED_OPERATOR_NEW_DELETE return ::operator new(__size,

[PATCH] D68364: Implement C++20's P0784 (More constexpr containers)

This revision was not accepted when it landed; it landed in state "Needs Review". This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG0724f8bf47f8: [libc++] Implement C++20's P0784 (More constexpr con

[PATCH] D85924: [clang][feature] Add cxx_abi_relative_vtable feature

ldionne accepted this revision. ldionne added a comment. This LGTM, but I agree someone should sign off on whether `__has_feature` is the right approach here. @aaron.ballman ? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D85924/new/ https://review

[PATCH] D84049: Disable use of _ExtInt with '__atomic' builtins

ldionne added inline comments. Comment at: libcxx/test/libcxx/atomics/ext-int.verify.cpp:1 +// REQUIRES: clang-11 + This isn't great, since it won't run on clang-12, etc. I'll change it to: ``` // UNSUPPORTED: clang-4, clang-5, clang-6, clang-7, clang-8, clang-9

[PATCH] D84049: Disable use of _ExtInt with '__atomic' builtins

ldionne added inline comments. Comment at: libcxx/test/libcxx/atomics/ext-int.verify.cpp:1 +// REQUIRES: clang-11 + jtmott-intel wrote: > ldionne wrote: > > This isn't great, since it won't run on clang-12, etc. I'll change it to: > > > > ``` > > // UNSUPPORTED:

[PATCH] D87051: scan-build-py: fix multiprocessing error

ldionne accepted this revision. ldionne added a comment. This revision is now accepted and ready to land. From the docs: > `multiprocessing.freeze_support()` > Add support for when a program which uses multiprocessing has been frozen to > produce a Windows executable. (Has been tested with py2ex

[PATCH] D87189: [CMake] Remove dead FindPythonInterp code

ldionne accepted this revision. ldionne added a comment. This revision is now accepted and ready to land. Herald added a subscriber: dexonsmith. I love this. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D87189/new/ https://reviews.llvm.org/D87189

[PATCH] D87459: [libcxx][test] ostream{,buf}_iterator::difference_type changes in C++20

ldionne added a comment. What paper is this? I searched but failed to find a paper this falls off from. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D87459/new/ https://reviews.llvm.org/D87459 ___ cfe-co

[PATCH] D87459: [libcxx][test] ostream{,buf}_iterator::difference_type changes in C++20

ldionne added a comment. In D87459#2265871 , @CaseyCarter wrote: > In D87459#2265864 , @ldionne wrote: > >> What paper is this? I searched but failed to find a paper this falls off >> from. > > P0896R4 "The One Ran

[PATCH] D87459: [libcxx][test] ostream{,buf}_iterator::difference_type changes in C++20

ldionne commandeered this revision. ldionne edited reviewers, added: CaseyCarter; removed: ldionne. ldionne added a comment. Herald added a subscriber: jkorous. In D87459#2265875 , @CaseyCarter wrote: >> Ah, I see it. I'll add that bit to libc++ so we don'

[PATCH] D42459: [cmake] [libcxx] Call llvm_setup_rpath() when adding shared libraries.

ldionne added a comment. @hintonda Is there a reason why this was done except for "standardizing the usage across projects"? I'm asking because this change prevents us from being able to avoid having a rpath completely when building libc++. That is the behavior we want when building libc++ as

[PATCH] D42459: [cmake] [libcxx] Call llvm_setup_rpath() when adding shared libraries.

ldionne added a comment. In D42459#2383794 , @hintonda wrote: > In D42459#2383753 , @ldionne wrote: > >> @hintonda Is there a reason why this was done except for "standardizing the >> usage across projects"? > > I

[PATCH] D42459: [cmake] [libcxx] Call llvm_setup_rpath() when adding shared libraries.

ldionne added a comment. I proposed a revert here for those who are interested: https://reviews.llvm.org/D91099 Repository: rL LLVM CHANGES SINCE LAST ACTION https://reviews.llvm.org/D42459/new/ https://reviews.llvm.org/D42459 ___ cfe-commits m

[PATCH] D13673: Add initial support for the MUSL C library.

ldionne added a comment. Herald added subscribers: krytarowski, mgorny. @vkalintiris @jroelofs Is it possible to detect Musl through some macro? I'd like to get rid of the CMake option -- this isn't the sort of property that we want to set explicitly at configure time, it's the sort of property

[PATCH] D91311: Add new 'preferred_name' attribute.

ldionne added a comment. What the attribute achieves is great, however I must say I'm really with Arthur's original comment regarding the ergonomics of it. IMO, it makes a lot more sense to permit the typedef author to pick how their typedef is going to be "named" by the compiler. If they pick

[PATCH] D91311: Add new 'preferred_name' attribute.

ldionne added a comment. In D91311#2398526 , @rsmith wrote: > [...] Thanks for your detailed explanation. I did not understand the philosophy of the attribute, and it's now clear to me that it shouldn't be tied to the typedef, indeed. > There's another

[PATCH] D91311: Add new 'preferred_name' attribute.

ldionne added subscribers: david_stone, mattcalabrese, mpark. ldionne added a comment. In D91311#2400917 , @dblaikie wrote: > How would that work for users - they would get error messages from the > compiler using type names that don't exist in the source

[PATCH] D90719: [DebugInfo] Modify ctor homing as workaround for unconstructed libcxx types

ldionne added a comment. Sorry, I read this last week and probably forgot to reply. I think the right thing to do is to fix the UB, which appears to mean fixing libc++. However, can you take a look at whether defining these macros help? // Fix undefined behavior in how __tree stores its end

[PATCH] D13673: Add initial support for the MUSL C library.

ldionne added a comment. In D13673#2394187 , @jroelofs wrote: > More context: https://www.openwall.com/lists/musl/2013/03/29/13 Thanks for the context. This is a very puristic point of view from the musl author.. not very useful. There are things that ar

[PATCH] D91565: Guard init_priority attribute within libc++

ldionne requested changes to this revision. ldionne added inline comments. This revision now requires changes to proceed. Comment at: libcxx/include/experimental/__config:80 +// Detect if the init_priority attribute is supported. +#if (defined(_LIBCPP_COMPILER_GCC) && defined(__A

[PATCH] D91311: Add new 'preferred_name' attribute.

ldionne accepted this revision as: libc++. ldionne added a comment. This revision is now accepted and ready to land. In D91311#2400998 , @dblaikie wrote: > A concrete/real-world example might be helpful, if you happen to have one on > hand. See what Rich

[PATCH] D91311: Add new 'preferred_name' attribute.

ldionne requested changes to this revision. ldionne added a comment. This revision now requires changes to proceed. Actually, apologies -- I might have accepted this too quickly. We can stick with this design, but I'd like to understand why `#if _LIBCPP_HAS_NO_PREFERRED_NAME` is necessary in ``,

[PATCH] D45639: [Driver] Support default libc++ library location on Darwin

ldionne added a comment. I think this looks good. I must admit I'm a bit worried about any unintended consequences this might have or breakage this might cause in cases where we'd switch from linking against the SDK libc++.dylib to the toolchain one. This would only impact the toolchain release

[PATCH] D91311: Add new 'preferred_name' attribute.

ldionne added a comment. In D91311#2404098 , @rsmith wrote: > In D91311#2403805 , @ldionne wrote: > >> We can stick with this design, but I'd like to understand why `#if >> _LIBCPP_HAS_NO_PREFERRED_NAME` is necessa

[PATCH] D68364: Implement C++20's P0784 (More constexpr containers)

ldionne added a comment. In D68364#2294569 , @jwakely wrote: > In D68364#2293971 , @leonardchan > wrote: > >> Is there a recommended way for working around this? We're using GCC 10.2.1. >> Thanks. > > I don't thin

[PATCH] D17053: [libcxx]: vector: Use < instead of != to improve failure mode

ldionne added a comment. In D17053#2315384 , @dexonsmith wrote: > In D17053#632700 , @EricWF wrote: > >> Maybe if we want to improve the failure mode we can add a >> `_LIBCPP_ASSERT(__new_last <= __end, "invalid ran

[PATCH] D17053: [libcxx]: vector: Use < instead of != to improve failure mode

ldionne added a comment. Also, regarding `allocator::pointer` vs raw pointers -- if someone defines a fancy pointer type whose `operator<` is significantly more costly than `operator!=`, I think this loop in libc++ is not the first thing that's going to bite them. I don't think that's the right

[PATCH] D88984: Prefer libc++ headers in the -isysroot over the toolchain

ldionne created this revision. ldionne added reviewers: arphaman, dexonsmith. Herald added subscribers: cfe-commits, jkorous. Herald added a project: clang. ldionne requested review of this revision. Currently, Clang looks for libc++ headers alongside the installation directory of Clang, and it al

[PATCH] D89001: [clang] Don't look into for C++ headers if they are found alongside the toolchain

ldionne created this revision. ldionne added reviewers: arphaman, dexonsmith. Herald added subscribers: cfe-commits, jkorous. Herald added a project: clang. ldionne requested review of this revision. Currently, Clang looks for libc++ headers alongside the installation directory of Clang, and it al

[PATCH] D88984: Prefer libc++ headers in the -isysroot over the toolchain

ldionne updated this revision to Diff 296772. ldionne added a comment. Split the patch in two Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D88984/new/ https://reviews.llvm.org/D88984 Files: clang-tools-extra/test/clang-tidy/infrastructure/Inputs

[PATCH] D89001: [clang] Don't look into for C++ headers if they are found alongside the toolchain

ldionne updated this revision to Diff 297000. ldionne added a comment. Try to fix test failure on Linux Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D89001/new/ https://reviews.llvm.org/D89001 Files: clang/lib/Driver/ToolChains/Darwin.cpp clan

[PATCH] D89001: [clang] Don't look into for C++ headers if they are found alongside the toolchain

This revision was automatically updated to reflect the committed changes. Closed by commit rGa3a24316087d: [clang] Don't look into for C++ headers if they are found alongside… (authored by ldionne). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.

[PATCH] D89177: [cmake] Add support for multiple distributions

ldionne added a comment. Are the runtimes expected to support this multi-distribution configuration? I don't think we'd want to move libc++ towards building multiple configurations at once in a single CMake invocation -- it's already too complicated to build just one configuration. While I'm v

[PATCH] D89177: [cmake] Add support for multiple distributions

ldionne added a comment. In D89177#2332626 , @beanz wrote: > In D89177#2332547 , @ldionne wrote: > >> Are the runtimes expected to support this multi-distribution configuration? >> I don't think we'd want to move l

[PATCH] D91565: Guard init_priority attribute within libc++

ldionne accepted this revision as: libc++. ldionne added a comment. LGTM from libc++'s perspective. You should wait until the Clang part is LGTM'd before committing, of course. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D91565/new/ https://revie

[PATCH] D43159: Modernize: Use nullptr more.

ldionne updated this revision to Diff 307398. ldionne added a comment. Herald added a project: libc++. Herald added a reviewer: libc++. Rebase onto master Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D43159/new/ https://reviews.llvm.org/D43159 Fil

[PATCH] D43159: [libc++] Replace several uses of 0 by nullptr

ldionne updated this revision to Diff 307402. ldionne added a comment. Herald added a project: libc++abi. Herald added a reviewer: libc++abi. Address review comments. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D43159/new/ https://reviews.llvm.org

[PATCH] D43159: [libc++] Replace several uses of 0 by nullptr

ldionne accepted this revision. ldionne added a comment. I'll ship this if CI passes, since I addressed all comments we had originally. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D43159/new/ https://reviews.llvm.org/D43159 __

[PATCH] D91311: Add new 'preferred_name' attribute.

ldionne accepted this revision as: libc++. ldionne added a comment. LGTM from the libc++ point of view. The CI is passing -- those failures are flaky modules tests that we need to fix. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D91311/new/ https

[PATCH] D43159: [libc++] Replace several uses of 0 by nullptr

ldionne updated this revision to Diff 307888. ldionne marked 3 inline comments as done. ldionne added a comment. Apply review comments. Thanks for the catches! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D43159/new/ https://reviews.llvm.org/D43159

[PATCH] D91311: Add new 'preferred_name' attribute.

ldionne added a comment. In D91311#2417293 , @rsmith wrote: > In D91311#2416940 , @ldionne wrote: > >> LGTM from the libc++ point of view. The CI is passing -- those failures are >> flaky modules tests that we need

[PATCH] D43159: [libc++] Replace several uses of 0 by nullptr

This revision was not accepted when it landed; it landed in state "Needs Review". This revision was automatically updated to reflect the committed changes. Closed by commit rG527a7fdfbd74: [libc++] Replace several uses of 0 by nullptr (authored by brucem, committed by ldionne). Repository: rG

[PATCH] D91311: Add new 'preferred_name' attribute.

ldionne added a comment. In D91311#2423809 , @rsmith wrote: > In D91311#2418881 , @ldionne wrote: > >> In D91311#2417293 , @rsmith wrote: >> >>> In D91311#2416940

[PATCH] D32838: [libcxx] Make __shared_weak_count VTable consistent across all build configurations

ldionne updated this revision to Diff 299342. ldionne added a comment. Herald added a project: libc++. Herald added a subscriber: libcxx-commits. Herald added 1 blocking reviewer(s): libc++. Rebase onto master Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llv

[PATCH] D32838: [libcxx] Make __shared_weak_count VTable consistent across all build configurations

ldionne updated this revision to Diff 299344. ldionne added a comment. Herald added a subscriber: mgorny. Herald added a project: libc++abi. Herald added a reviewer: libc++abi. Remove uses of _LIBCPP_BUILD_STATIC Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.

[PATCH] D32838: [libcxx] Make __shared_weak_count VTable consistent across all build configurations

ldionne accepted this revision. ldionne added a comment. This revision is now accepted and ready to land. For libc++: We never manually define `_LIBCPP_BUILD_STATIC`, so libc++ always contains `__shared_weak_count::__get_deleter`. For libc++abi: It could happen that `_LIBCPP_BUILD_STATIC` is defi

[PATCH] D32838: [libcxx] Make __shared_weak_count VTable consistent across all build configurations

This revision was automatically updated to reflect the committed changes. Closed by commit rG229db3647491: [libc++] Make __shared_weak_count vtable consistent across all build… (authored by EricWF, committed by ldionne). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://r

[PATCH] D89793: [libc++] Explicitly request new/delete in libc++ for Win to ARM Linux builds

ldionne created this revision. ldionne added a reviewer: broadwaylamb. Herald added subscribers: cfe-commits, jkorous, kristof.beyls, mgorny. Herald added a project: clang. ldionne requested review of this revision. Since 9b40ee8eb0c1

[PATCH] D89793: [libc++] Explicitly request new/delete in libc++ for Win to ARM Linux builds

ldionne added a subscriber: rsmith. ldionne added a comment. This should fix the Win to ARM Linux bot failures seen by @rsmith in https://reviews.llvm.org/D68269. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D89793/new/ https://reviews.llvm.org/D8

[PATCH] D89793: [libc++] Explicitly request new/delete in libc++ for Win to ARM Linux builds

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rGeaa928b71a09: [libc++] Explicitly request new/delete in libc++ for Win to ARM Linux builds (authored by ldionne). Repository: rG LLVM Github Monor

[PATCH] D90188: Add support for attribute 'using_if_exists'

ldionne added inline comments. Comment at: clang/test/SemaCXX/using-if-exists-attr.cpp:16 +template +using template_alias UIE = NS::x; // expected-warning {{'using_if_exists' attribute only applies to named declarations, types, and value declarations}} + I assu

[PATCH] D31363: [libc++] Remove cmake glob for source files

ldionne added a comment. This patch isn't necessary anymore, as we don't use globing anymore. Let's abandon it to clean up the review queue. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D31363/new/ https://reviews.llvm.org/D31363 ___ cfe-com

[PATCH] D31363: [libc++] Remove cmake glob for source files

ldionne added a comment. In D31363#2360132 , @ldionne wrote: > This patch isn't necessary anymore, as we don't use globing anymore. Let's > abandon it to clean up the review queue. Actually, I misspoke. We still use it, but only in a few places. If you s

[PATCH] D45639: [Driver] Support default libc++ library location on Darwin

ldionne added a comment. Re-reading this. the whole discussion about `filesystem` is now irrelevant, since it's part of the dylib. The comment I have is that `libc++.dylib` is considered to be a system library on macOS, not a toolchain-provided library. This matters because we make sure that `

[PATCH] D45639: [Driver] Support default libc++ library location on Darwin

ldionne added a comment. Note: This patch basically implements **Solution (1)**. I would love to see it rebased onto `master` and for tests to be added if we're all comfortable going down that route. Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D45639/new/ http

[PATCH] D47111: : Implement monotonic_buffer_resource.

ldionne added a comment. Can we please close this review as it's been superseded by D89057 ? Repository: rCXX libc++ CHANGES SINCE LAST ACTION https://reviews.llvm.org/D47111/new/ https://reviews.llvm.org/D47111 ___

[PATCH] D50739: Clean up macros to detect underling C library functionality

ldionne added a reviewer: libc++. ldionne added a comment. Is this still relevant? We don't have `_LIBCPP_HAS_C11_FEATURES` anymore. If not relevant, let's close this to clear up the queue. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D50739/new/ https://reviews.llvm.org/D50739 __

[PATCH] D91630: [Parse] Add parsing support for C++ attributes on using-declarations

ldionne updated this revision to Diff 347069. ldionne marked an inline comment as done. ldionne added a comment. Herald added a project: clang. Rebase onto main and apply Aaron's comment. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D91630/new/ htt

[PATCH] D91630: [Parse] Add parsing support for C++ attributes on using-declarations

ldionne updated this revision to Diff 348547. ldionne marked 3 inline comments as done. ldionne added a comment. Apply review comments. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D91630/new/ https://reviews.llvm.org/D91630 Files: clang/docs/La

[PATCH] D91630: [Parse] Add parsing support for C++ attributes on using-declarations

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rGdc672999a9b1: [clang][Parse] Add parsing support for C++ attributes on using-declarations (authored by erik.pilkington, committed by ldionne). Repo

[PATCH] D90188: Add support for attribute 'using_if_exists'

ldionne updated this revision to Diff 348810. ldionne added a comment. Herald added a project: clang. Rebase onto `main`. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D90188/new/ https://reviews.llvm.org/D90188 Files: clang/include/clang/AST/Dec

[PATCH] D91630: [Parse] Add parsing support for C++ attributes on using-declarations

ldionne added a comment. In D91630#2787438 , @thakis wrote: > This is breaking check-clang everywhere, eg > https://lab.llvm.org/buildbot/#/builders/109/builds/15757 > > Please run tests before landing, or failing that watch the bots after > committing.

[PATCH] D91630: [Parse] Add parsing support for C++ attributes on using-declarations

ldionne updated this revision to Diff 348859. ldionne added a comment. Rebase onto `main`. I want to trigger CI again. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D91630/new/ https://reviews.llvm.org/D91630 Files: clang/docs/LanguageExtensions.

[PATCH] D91630: [Parse] Add parsing support for C++ attributes on using-declarations

ldionne updated this revision to Diff 348861. ldionne added a comment. Fix embarrassingly obvious oversight when I applied Aaron's feedback. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D91630/new/ https://reviews.llvm.org/D91630 Files: clang/do

[PATCH] D91630: [Parse] Add parsing support for C++ attributes on using-declarations

This revision was automatically updated to reflect the committed changes. Closed by commit rG97d234935f15: [clang][Parse] Add parsing support for C++ attributes on using-declarations (authored by ldionne). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org

[PATCH] D90188: Add support for attribute 'using_if_exists'

ldionne updated this revision to Diff 348952. ldionne added a comment. Rebase onto main to trigger CI. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D90188/new/ https://reviews.llvm.org/D90188 Files: clang/include/clang/AST/DeclCXX.h clang/incl

[PATCH] D90188: Add support for attribute 'using_if_exists'

ldionne updated this revision to Diff 349010. ldionne added a comment. Run clang-format. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D90188/new/ https://reviews.llvm.org/D90188 Files: clang/include/clang/AST/DeclCXX.h clang/include/clang/AST/

[PATCH] D90188: Add support for attribute 'using_if_exists'

ldionne updated this revision to Diff 349087. ldionne added a comment. Fix CI issues (hopefully - at least everything runs locally). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D90188/new/ https://reviews.llvm.org/D90188 Files: clang/include/cl

[PATCH] D90188: Add support for attribute 'using_if_exists'

This revision was automatically updated to reflect the committed changes. Closed by commit rG369c64839946: [clang] Implement the using_if_exists attribute (authored by erik.pilkington, committed by ldionne). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.o

[PATCH] D100581: [Clang] -Wunused-but-set-parameter and -Wunused-but-set-variable

ldionne added a comment. Hello! There are still some false positives, for example this one is breaking the libc++ CI: https://buildkite.com/llvm-project/libcxx-ci/builds/3530#8679608a-200b-4a48-beb4-a9e9924a8848 Would it be possible to either fix this quickly or revert the change until the iss

[PATCH] D100581: [Clang] -Wunused-but-set-parameter and -Wunused-but-set-variable

ldionne added a comment. In D100581#2793926 , @dblaikie wrote: > In D100581#2793775 , @ldionne wrote: > >> Hello! There are still some false positives, for example this one is >> breaking the libc++ CI: >> https

[PATCH] D110289: [libc++] Remove unused macro in __config

ldionne updated this revision to Diff 374518. ldionne added a comment. Herald added subscribers: cfe-commits, llvm-commits, dexonsmith, usaxena95, kadircet, arphaman, hiraditya. Herald added projects: LLVM, clang-tools-extra. Remove uses of __MAC_OS_X_VERSION_MIN_REQUIRED in LLVM Repository:

[PATCH] D110289: [libc++] Remove unused macro in __config

ldionne added a comment. In D110289#3016525 , @jloser wrote: > I think it's used in a few places from a quick `git grep`: [...] `__MAC_OS_X_VERSION_MIN_REQUIRED` is defined by Apple's ``. It is equivalent to `__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED_

[PATCH] D108696: [Coroutines] [Frontend] Lookup in std namespace first

ldionne added a comment. This sounds more reasonable to me, however we need to ship `` in libc++ before we enable this, or else we're going to start suggesting that users include `` when we don't have it. Comment at: clang/lib/Sema/SemaCoroutine.cpp:1668 +if (!CoroNamespa

[PATCH] D110289: [libc++] Remove unused macro in __config

ldionne accepted this revision as: libc++. ldionne added a comment. Other CI failures appear unrelated to the change, so I'm shipping this. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D110289/new/ https://reviews.llvm.org/D110289

[PATCH] D110289: [libc++] Remove unused macro in __config

This revision was not accepted when it landed; it landed in state "Needs Review". This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rGe6126faba060: [libc++] Remove unused macro in __config (authored b

[PATCH] D109408: [libcxxabi] NFC: fix incorrect indentation of braces

ldionne added a comment. In D109408#2996128 , @zhouyizhou wrote: > In D109408#2996092 , @Quuxplusone > wrote: > >> I was going to land this just now, but then realized that I've lost the >> thread of why we're

[PATCH] D40259: [libcxx] LWG2993: reference_wrapper

ldionne commandeered this revision. ldionne added a reviewer: K-ballo. ldionne added a comment. Herald added a subscriber: jkorous. This is superseded by D92725 , so I'm going to commandeer and abandon this to clear up the review queue. Thanks for your contributi

[PATCH] D40259: [libcxx] LWG2993: reference_wrapper

ldionne abandoned this revision. ldionne added a comment. Closing as this is superseded by D92725 . Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D40259/new/ https://reviews.llvm.org/D40259 _

[PATCH] D96070: [clang] [driver] Enable static linking to libc++

ldionne added a comment. I think the root cause of the push back you're getting is that this is normally handled by vendors when they decide how they're going to ship libc++ on their platform or in their toolchain. For example, on Apple platforms, we ship `libc++.dylib`, and we make sure to re

[PATCH] D50106: [libc++] Fix tuple assignment from types derived from a tuple-like

ldionne updated this revision to Diff 322746. ldionne retitled this revision from "[libc++] Fix tuple assignment from type derived from a tuple-like" to "[libc++] Fix tuple assignment from types derived from a tuple-like". ldionne edited the summary of this revision. ldionne added a comment. Hera

[PATCH] D50106: [libc++] Fix tuple assignment from types derived from a tuple-like

ldionne updated this revision to Diff 323047. ldionne added a comment. Fix segfault on GCC and a few incorrect checks in the type traits. I reduced the GCC segfault and it appears to have been fixed on GCC trunk, so I won't be filing a bug report. Repository: rG LLVM Github Monorepo CHANGES

[PATCH] D50106: [libc++] Fix tuple assignment from types derived from a tuple-like

ldionne updated this revision to Diff 324645. ldionne added a comment. Fix build on GCC (or at least I think it should) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D50106/new/ https://reviews.llvm.org/D50106 Files: libcxx/include/tuple libcx

[PATCH] D50106: [libc++] Fix tuple assignment from types derived from a tuple-like

ldionne updated this revision to Diff 324648. ldionne added a comment. Address Arthur's comments. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D50106/new/ https://reviews.llvm.org/D50106 Files: libcxx/include/tuple libcxx/test/libcxx/utilitie

[PATCH] D50106: [libc++] Fix tuple assignment from types derived from a tuple-like

ldionne updated this revision to Diff 325039. ldionne added a comment. Fix GCC issues. I swear I had done the same fix locally previously, but I must have messed something up with Git or `arc diff`. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D5010

[PATCH] D93003: [libunwind] unw_* alias fixes for ELF and Mach-O

ldionne added a comment. In D93003#2567088 , @steven_wu wrote: > In D93003#2566906 , @rprichard wrote: > >> Maybe this is blocked on someone from Apple reviewing the Mach-O parts? > > This is fine with me for how Ap

[PATCH] D50106: [libc++] Fix tuple assignment from types derived from a tuple-like

ldionne updated this revision to Diff 325445. ldionne marked 6 inline comments as done. ldionne added a comment. Address Arthur's comments. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D50106/new/ https://reviews.llvm.org/D50106 Files: libcxx/in

[PATCH] D50106: [libc++] Fix tuple assignment from types derived from a tuple-like

ldionne added a comment. I think we should be pretty much good to go now. Will let CI run just in case. Comment at: libcxx/include/tuple:971 +_VSTD::get<0>(*this) = _VSTD::forward<_Up1>(__pair.first); +_VSTD::get<1>(*this) = _VSTD::forward<_Up2>(__pair.second);

[PATCH] D50106: [libc++] Fix tuple assignment from types derived from a tuple-like

ldionne updated this revision to Diff 325449. ldionne added a comment. Rebase onto main. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D50106/new/ https://reviews.llvm.org/D50106 Files: libcxx/include/tuple libcxx/test/libcxx/utilities/tuple/t

[PATCH] D50106: [libc++] Fix tuple assignment from types derived from a tuple-like

This revision was not accepted when it landed; it landed in state "Needs Review". This revision was automatically updated to reflect the committed changes. Closed by commit rGa0839b14df6d: [libc++] Fix tuple assignment from types derived from a tuple-like (authored by ldionne). Changed prior to

[PATCH] D88984: Prefer libc++ headers in the -isysroot over the toolchain

ldionne abandoned this revision. ldionne added a comment. Herald added a project: clang-tools-extra. Revisiting this, I don't think we need to move forward with this. Let's just carry our downstream patch until we don't need it anymore (which should be soon ish), and leave upstream Clang as it i

[PATCH] D101899: std::forward_list::swap to use propagate_on_container_swap for noexcept specification

ldionne accepted this revision. ldionne added a comment. This revision is now accepted and ready to land. Thanks a lot for fixing this and sorry Repository: rCXX libc++ CHANGES SINCE LAST ACTION https://reviews.llvm.org/D101899/new/ https://reviews.llvm.org/D101899 ___

[PATCH] D101899: std::forward_list::swap to use propagate_on_container_swap for noexcept specification

This revision was automatically updated to reflect the committed changes. Closed by commit rG7adf713a5e22: [libc++] Change forward_list::swap to use propagate_on_container_swap for… (authored by airglow923, committed by ldionne). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[PATCH] D102507: [HIP] Support in device code

ldionne added a comment. In D102507#2830688 , @yaxunl wrote: > In D102507#2792087 , @rsmith wrote: > >> @ldionne How should we go about establishing whether libc++ would be >> prepared to officially support CUDA?

<    1   2   3   4   5   6   7   8   >