[PATCH] D107717: [LLVM][CMake][NFC] Resolve FIXME: Rename LLVM_CMAKE_PATH to LLVM_CMAKE_DIR throughout the project

ldionne accepted this revision. ldionne added a comment. This LGTM. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D107717/new/ https://reviews.llvm.org/D107717 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-

[PATCH] D104500: [clang] Apply P1825 as Defect Report from C++11 up to C++20.

ldionne added a comment. In D104500#2865917 , @mizvekov wrote: > Well I thought that meant exactly that libc++ does not support C++98, it only > works on clang because it provides so much of C++11 as an extension. > > I did not remove this just on my own

[PATCH] D105439: [clang] protects users from relying on libc++ detail headers

ldionne added a comment. I'm not entirely sure I understand the purpose of this patch. So the idea is that let's say a tool suggests including `<__algorithm/find.h>` to get the definition of `std::find` as a IWYU fix-it sort of suggestion, the user would naively do that, and then the compiler (

[PATCH] D106339: Add support to generate Sphinx DOCX documentation

ldionne added a comment. Herald added a project: Flang. If there is no plan to move forward with generating `.docx` documentation, can we please abandon this review? I'm trying to clean up libc++'s review queue. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.

[PATCH] D112921: [clang] Enable sized deallocation by default in C++14 onwards

ldionne requested changes to this revision. ldionne added inline comments. This revision now requires changes to proceed. Comment at: libcxx/test/std/language.support/support.dynamic/new.delete/new.delete.array/sized_delete_array14.pass.cpp:12 // UNSUPPORTED: sanitizer-new-dele

[PATCH] D111477: DO NOT SUBMIT: workaround for context-sensitive use of non-type-template-parameter integer suffixes

ldionne added a comment. This broke libc++'s CI: https://buildkite.com/llvm-project/libcxx-ci/builds/6374#7569da95-c852-44f9-8b69-947245cf0b65 When you make a change to Clang AND the libc++ tests at the same time, you have to account for the fact that we support older versions of Clang. For exa

[PATCH] D111477: DO NOT SUBMIT: workaround for context-sensitive use of non-type-template-parameter integer suffixes

ldionne added a comment. Trying to fix this in https://reviews.llvm.org/D113112. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D111477/new/ https://reviews.llvm.org/D111477 ___ cfe-commits mailing list cf

[PATCH] D97411: [DebugInfo] Add an attribute to force type info to be emitted for types that are required to be complete.

ldionne added a comment. In D97411#2588181 , @akhuang wrote: > @ldionne Do you think it'd be reasonable to add this debug info attribute to > some types in libc++? (For types that have constructors but don't call them; > some previous discussion in https

[PATCH] D97411: [DebugInfo] Add an attribute to force type info to be emitted for types that are required to be complete.

ldionne added a comment. I don't have an opinion about the attribute itself. I do have an opinion about using that attribute in libc++ instead of fixing the underlying issue (I think we shouldn't do it). Can you confirm what the problematic types are? In another patch I saw `__hash_node`, `__ha

[PATCH] D46443: Add missing cstdalign header

ldionne requested changes to this revision. ldionne added a comment. This revision now requires changes to proceed. In D46443#2566394 , @hubert.reinterpretcast wrote: > The resolution of LWG 2828 > m

[PATCH] D46443: Add missing cstdalign header

ldionne requested changes to this revision. ldionne added inline comments. This revision now requires changes to proceed. Comment at: libcxx/test/std/language.support/cstdalign/cstdalign.pass.cpp:8 +//===--===//

[PATCH] D46443: [libc++] Add missing cstdalign header

ldionne accepted this revision. ldionne added a comment. This revision is now accepted and ready to land. Please wait for CI to finish! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D46443/new/ https://reviews.llvm.org/D46443 __

[PATCH] D110216: [clang] retain type sugar in auto / template argument deduction

ldionne added a comment. In D110216#3127530 , @mizvekov wrote: > Exactly what Aaron said :-) > > Though might be a complication here if libcxx tests this with both ToT and > stable clang, so could be perhaps this needs to be changed in a way that > work

[PATCH] D110216: [clang] retain type sugar in auto / template argument deduction

ldionne added a comment. I think this should do it: diff --git a/libcxx/test/std/utilities/any/any.nonmembers/any.cast/const_correctness.fail.cpp b/libcxx/test/std/utilities/any/any.nonmembers/any.cast/const_correctness.verify.cpp similarity index 81% rename from libcxx/test/std/utiliti

[PATCH] D112921: [clang] Enable sized deallocation by default in C++14 onwards

ldionne requested changes to this revision. ldionne added a comment. Regarding the back-deployment target for Apple, I believe the first OSes where `libc++.dylib` had sized deallocation are `macOS 10.12`, `iOS 10.0`, `watchOS 3.0`, and `tvOS 10.0`. We should be able to enable reliance on sized

[PATCH] D110216: [clang] retain type sugar in auto / template argument deduction

ldionne accepted this revision. ldionne added a comment. This revision is now accepted and ready to land. LGTM from the libc++ perspective. Unsubscribing to reduce spam, please ping me on Discord if you need further input. Thanks! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTIO

[PATCH] D113977: [Coroutine] Warn deprecated 'std::experimental::coro' uses

ldionne accepted this revision. ldionne added a comment. This revision is now accepted and ready to land. LGTM with some suggestions, thanks for adding this notice! Comment at: clang/include/clang/Basic/DiagnosticGroups.td:57-59 +def DeprecatedCorotuine : + DiagGroup<"deprecat

[PATCH] D112430: [ARM][libunwind] add PACBTI-M support for libunwind

ldionne added a comment. Please rebase onto `main` and re-upload before submitting, so that the CI runs. There was a flaky failure previously, but I'd like to see it run before merging. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D112430/new/ htt

[PATCH] D114649: [libc++] Implement not-yet-voted LWG3436

ldionne created this revision. ldionne added a reviewer: rsmith. ldionne requested review of this revision. Herald added projects: clang, libc++. Herald added subscribers: libcxx-commits, cfe-commits. Herald added a reviewer: libc++. LWG3436 adds support for array types in construct_at. That is ne

[PATCH] D114649: [libc++] Implement not-yet-voted LWG3436

ldionne added a comment. @rsmith I suspect that enabling array placement new properly will be more complicated than this, but this simple change solved my immediate issue. Please let me know if that's insufficient. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://revi

[PATCH] D106339: Add support to generate Sphinx DOCX documentation

ldionne removed projects: libc++, libunwind. ldionne removed reviewers: libunwind, libc++, ldionne. ldionne added a comment. Herald added projects: libc++, libunwind. Herald added a reviewer: libc++. Herald added a reviewer: libunwind. Removing from the runtimes review queue -- please ping me dire

[PATCH] D114903: [clang] Support array placement new in constant expressions

ldionne created this revision. ldionne added a reviewer: rsmith. ldionne requested review of this revision. Herald added a project: clang. Herald added a subscriber: cfe-commits. This is necessary for std::construct_at to work on arrays inside a constant expression. Repository: rG LLVM Github

[PATCH] D114649: [libc++] Implement not-yet-voted LWG3436

ldionne marked an inline comment as done. ldionne added a comment. In D114649#3157040 , @Mordante wrote: > Since this patch requires both an update to both Clang and libc++ I think it > would land the Clang part in a separate patch. Then wait for the CI

[PATCH] D109460: [clang][Darwin] Try to guess the SDK root with xcrun when unspecified

ldionne abandoned this revision. ldionne added a comment. Abandoning in favor of D136315 . Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D109460/new/ https://reviews.llvm.org/D109460 ___

[PATCH] D136315: [clang][Darwin] Try to guess the SDK root with xcrun when unspecified

ldionne added a comment. Thanks for picking this up! I looked at my local changes and I had started modifying `inferDeploymentTargetFromSDK`. I had left the comment: /// TODO: We should only infer it if the SDK was provided with SDKROOT or -isysroot. /// If we inferred the SDK with xc

[PATCH] D136533: [clang] Fix missing diagnostic of declaration use when accessing TypeDecls through typename access

ldionne added a comment. Is it possible that it would be one of those two bugs? https://github.com/llvm/llvm-project/issues?q=is%3Aopen+is%3Aissue+author%3Aldionne+availability+ Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D136533/new/ https://rev

[PATCH] D136533: [clang] Fix missing diagnostic of declaration use when accessing TypeDecls through typename access

ldionne added a comment. Ah, I understand. Thanks for explaining and sorry, I had only taken a quick look. So -- the reason why this isn't found by the libc++ CI is that it only triggers when we build on macOS, and our CI does not perform a bootstrapping build on macOS. In other words, we're n

[PATCH] D136533: [clang] Fix missing diagnostic of declaration use when accessing TypeDecls through typename access

ldionne added a comment. In D136533#3892949 , @ldionne wrote: > 2. Shipping this change does mean that anyone building anything with a new > Clang and a not-yet-updated libc++ with a deployment target before 10.15 (or > whatever first version we shipped

[PATCH] D136533: [clang] Fix missing diagnostic of declaration use when accessing TypeDecls through typename access

ldionne added a comment. In D136533#3894958 , @thakis wrote: > In D136533#3893032 , @ldionne wrote: > >> In D136533#3892949 , @ldionne >> wrote: >> >>> 2. Shipping this c

[PATCH] D136533: [clang] Fix missing diagnostic of declaration use when accessing TypeDecls through typename access

ldionne added a comment. In D136533#3896536 , @mizvekov wrote: > Now that you mention it, looking at the code, I think we don't diagnose an > use of a type alias itself, if that is what you mean? > > Ie, clang doesn't, GCC does, MSVC doesn't: https://god

[PATCH] D131274: [clang][Darwin] Re-apply "Always set the default C++ Standard Library to libc++"

This revision was automatically updated to reflect the committed changes. Closed by commit rG65d83ba34378: [clang][Darwin] Re-apply "Always set the default C++ Standard Library to libc++" (authored by ldionne). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llv

[PATCH] D12669: [libcxxabi] Fix alignment of pointers returned by fallback_malloc

ldionne commandeered this revision. ldionne added a reviewer: EricWF. ldionne added a comment. Commandeering to abandon since we're landing D129842 instead. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D12669/new/ https://reviews.llvm.org/D12669

[PATCH] D132324: [RFC] Remove support for building libc++ with `LLVM_ENABLE_PROJECTS`

ldionne added a comment. Please don't change libc++ things like that without my approval first. This is a transition I've been working on for 2+ years, I had a local patch for it waiting to be published, and this patch is incomplete in several ways. I greatly appreciate the effort and wanting t

[PATCH] D132324: [RFC] Remove support for building libc++ with `LLVM_ENABLE_PROJECTS`

ldionne added a comment. In D132324#3742406 , @aaron.ballman wrote: > For clarity, @ldionne are you requesting that these changes be reverted due > to being incomplete, or do you prefer this be fixed forward? Sorry, I left no action item on my end afte

[PATCH] D132324: [RFC] Remove support for building libc++ with `LLVM_ENABLE_PROJECTS`

ldionne added a comment. This sucks, but I'm going to revert this series of patches. This is getting somewhat out of hands and I feel that we're rushing to fix all kinds of issues in various directions. I'm going to revert the following patches, in this order: 1. 952f90b72b35

[PATCH] D132324: [RFC] Remove support for building libc++ with `LLVM_ENABLE_PROJECTS`

ldionne added a comment. In D132324#3742700 , @Ericson2314 wrote: >> I also think we don't want to move forward with D132411 >> -- it's going against this transition. > > I would like to discuss some of this sort of th

[PATCH] D132488: [CMake] Move cxx-headers to RUNTIME_DISTRIBUTION_COMPONENTS in Apple-stage2.cmake

ldionne created this revision. ldionne added a reviewer: fhahn. Herald added a subscriber: mgorny. Herald added a project: All. ldionne requested review of this revision. Herald added a project: clang. Herald added a subscriber: cfe-commits. We build libcxx using LLVM_ENABLE_RUNTIMES during Stage2

[PATCH] D132488: [CMake] Move cxx-headers to RUNTIME_DISTRIBUTION_COMPONENTS in Apple-stage2.cmake

This revision was automatically updated to reflect the committed changes. Closed by commit rG7dfcf9342b5a: [CMake] Move cxx-headers to RUNTIME_DISTRIBUTION_COMPONENTS in Apple-stage2. (authored by ldionne). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.or

[PATCH] D133249: [libc++] Documents details of the pre-commit CI.

ldionne accepted this revision. ldionne added inline comments. Comment at: clang/www/hacking.html:311-312 + Unlike Clang, libc++ supports multiple versions of Clang. Therefore when a + patch changes the diagnostics it might be required to use a regex in the + "expected" tests

[PATCH] D131963: [libc++] Add custom clang-tidy checks

ldionne accepted this revision. ldionne added subscribers: smeenai, beanz. ldionne added a comment. This revision is now accepted and ready to land. I'd be fine with this as-is if it works in the CI. IIUC, the current blocker for this is that the `ClangConfig.cmake` installed by LLVM is not robu

[PATCH] D134604: [clang] Instiantiate early substituted entities with sugared template arguments

ldionne added a comment. As explained in more details here (https://reviews.llvm.org/D133249#inline-1289205), it would be nice to stop using the `DELETE.ME` idiom to kick off libc++ CI, unless you really think there's a good chance to cause failures in libc++ specifically. TLDR of the link: th

[PATCH] D125683: [runtimes] Replace LIBCXX_ENABLE_STATIC_ABI_LIBRARY & friends by a new LIBCXX_CXX_ABI choice

ldionne added a comment. In D125683#3811492 , @nikic wrote: > I have some concerns about this change: > > - It makes it fundamentally impossible to link against a static > system-libcxxabi (or any other `LIBCXX_CXX_ABI` option). This is currently > alre

[PATCH] D134650: [runtimes] Remove all traces of the legacy testing configuration system

ldionne created this revision. Herald added subscribers: libcxx-commits, mstorsjo, arichardson. Herald added projects: libunwind, All. Herald added a reviewer: libunwind. ldionne requested review of this revision. Herald added projects: clang, libc++, libc++abi. Herald added a subscriber: cfe-commi

[PATCH] D134604: [clang] Instiantiate early substituted entities with sugared template arguments

ldionne added a comment. In D134604#3815634 , @mizvekov wrote: > I was aware of those discussions, and I even made a workaround to avoid this > extra cost of running unrelated pipelines. > The patch on the very bottom of this stack (D134079 >

[PATCH] D134878: Update developer policy on potentially breaking changes

ldionne added a comment. Thanks for working on this! FWIW, this more or less standardizes what we've been doing in libc++ for the past ~1.5 years and it's been pretty low effort for us to do. And putting my vendor hat on, it's been extremely useful for me to track down potential issues when try

[PATCH] D134878: Update developer policy on potentially breaking changes

ldionne accepted this revision. ldionne added inline comments. Comment at: llvm/docs/DeveloperPolicy.rst:140 + +* After the change has been committed to the repository, the potentially + disruptive changes described in the release notes should be posted to the a

[PATCH] D134650: [runtimes] Remove all traces of the legacy testing configuration system

ldionne added a subscriber: vvereschaka. ldionne added a comment. @vvereschaka Can you please confirm that the CMake cache changes look good to you? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D134650/new/ https://reviews.llvm.org/D134650 __

[PATCH] D134650: [runtimes] Remove all traces of the legacy testing configuration system

ldionne updated this revision to Diff 464060. ldionne added a comment. Rebase on main. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D134650/new/ https://reviews.llvm.org/D134650 Files: clang/cmake/caches/CrossWinToARMLinux.cmake libcxx/cmake/c

[PATCH] D134650: [runtimes] Remove all traces of the legacy testing configuration system

ldionne updated this revision to Diff 464234. ldionne added a comment. Address comments. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D134650/new/ https://reviews.llvm.org/D134650 Files: clang/cmake/caches/CrossWinToARMLinux.cmake libcxx/cmake

[PATCH] D134650: [runtimes] Remove all traces of the legacy testing configuration system

ldionne added inline comments. Comment at: clang/cmake/caches/CrossWinToARMLinux.cmake:163 set(RUNTIMES_${TOOLCHAIN_TARGET_TRIPLE}_COMPILER_RT_EMULATOR "\\\"${Python3_EXECUTABLE}\\\" \\\"${LLVM_PROJECT_DIR}/llvm/utils/remote-exec.py\\\" --execdir %%T --exec-pattern=

[PATCH] D134650: [runtimes] Remove all traces of the legacy testing configuration system

ldionne updated this revision to Diff 464351. ldionne added a comment. Add release note. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D134650/new/ https://reviews.llvm.org/D134650 Files: clang/cmake/caches/CrossWinToARMLinux.cmake libcxx/cmake

[PATCH] D134650: [runtimes] Remove all traces of the legacy testing configuration system

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rGa48f018bb7d8: [runtimes] Remove all traces of the legacy testing configuration system (authored by ldionne). Repository: rG LLVM Github Monorepo

[PATCH] D135341: [clang] adds `__reference_constructs_from_temporary` and `__reference_converts_from_temporary`

ldionne added a comment. Interesting, I actually wasn't even aware of that C++23 feature in the library. FWIW, libc++ will be more than happy to use that builtin instead of trying to figure it out inside the library (if that's even possible)! We'll have to check whether GCC implements it, but h

[PATCH] D135238: [clang] adds copy-constructible type-trait builtins

ldionne added inline comments. Comment at: clang/include/clang/Basic/TokenKinds.def:528 +TYPE_TRAIT_1(__is_nothrow_copy_constructible, IsNothrowCopyConstructible, KEYCXX) +TYPE_TRAIT_1(__is_trivially_copy_constructible, IsTriviallyCopyConstructible, KEYCXX) TYPE_TRAIT_2(__refe

[PATCH] D109460: [clang][Darwin] Try to guess the SDK root with xcrun when unspecified

ldionne added a comment. In D109460#3860750 , @calebzulawski wrote: > I'm interested in this feature--is there any reason this wasn't completed? If > not, I might be able to take over implementing this. Lack of bandwidth. It would be awesome if someone

[PATCH] D139938: [clang] Don't spuriously pass -stdlib=libc++ to CC1 on Darwin

This revision was automatically updated to reflect the committed changes. Closed by commit rG6540f32db09c: [clang] Don't spuriously pass -stdlib=libc++ to CC1 on Darwin (authored by ldionne). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D139938/new/

[PATCH] D139938: [clang] Don't spuriously pass -stdlib=libc++ to CC1 on Darwin

ldionne reopened this revision. ldionne added a comment. This revision is now accepted and ready to land. In D139938#4008909 , @steven_wu wrote: > In D139938#4008232 , @hans wrote: > >> This seems to have broken t

[PATCH] D139938: [clang] Re-apply change to avoid passing -stdlib=libc++ spuriously to CC1 on Darwin

ldionne updated this revision to Diff 484403. ldionne retitled this revision from "[clang] Don't spuriously pass -stdlib=libc++ to CC1 on Darwin" to "[clang] Re-apply change to avoid passing -stdlib=libc++ spuriously to CC1 on Darwin". ldionne edited the summary of this revision. ldionne added a

[PATCH] D139938: [clang] Re-apply change to avoid passing -stdlib=libc++ spuriously to CC1 on Darwin

ldionne added inline comments. Comment at: compiler-rt/test/profile/lit.cfg.py:45-51 +# TODO: target_cflags can sometimes contain C++ only flags like -stdlib=, which are +# ignored when compiling as C code. Passing this flag when compiling as C results in +# warning

[PATCH] D139938: [clang] Re-apply change to avoid passing -stdlib=libc++ spuriously to CC1 on Darwin

ldionne added a comment. I'll ship this now since CI seems happy and I reproduced the issue and saw it was fixed by my new change. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D139938/new/ https://reviews.llvm.org/D139938

[PATCH] D139938: [clang] Re-apply change to avoid passing -stdlib=libc++ spuriously to CC1 on Darwin

This revision was automatically updated to reflect the committed changes. Closed by commit rG52aab0e4b4a5: [clang] Re-apply change to avoid passing -stdlib=libc++ spuriously to CC1 on… (authored by ldionne). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.o

[PATCH] D139986: [clang][TypePrinter] Teach isSubstitutedDefaultArgument about integral types

ldionne added a comment. @dblaikie We added the libc++ tests to the Clang pre-commit CI after discussing with @erichkeane since he told me breaking libc++ was a recurring pain point, and having a way to detect that would be greatly appreciated by the Clang folks. The goal was really only to he

[PATCH] D139114: [Clang][Sema] Enabled implicit conversion warning for CompoundAssignment operator.

ldionne added subscribers: fahad, rprichard, MaskRay. ldionne added a comment. The code in libunwind does look fishy to me (before the change), so I think flagging this in the compiler is good. I don't know that code at all, though, so I'm pinging a few libunwind regulars so they can let us know

[PATCH] D141423: Trigger the Clang/libc++ CI pipeline even when libc++ has been modified

ldionne created this revision. Herald added subscribers: mstorsjo, arichardson. Herald added a project: All. ldionne requested review of this revision. Herald added projects: clang, libc++. Herald added subscribers: libcxx-commits, cfe-commits. Herald added a reviewer: libc++. Previously, we would

[PATCH] D137338: Fix dupe word typos

ldionne accepted this revision. ldionne added a comment. Thanks for the fixes. LGTM for `libcxx/`, `libcxxabi/` and `libunwind/`. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D137338/new/ https://reviews.llvm.org/D137338 __

[PATCH] D137724: [CMake] Warn when the version is older than 3.20.0.

ldionne added a comment. LGTM (sorry, it looks like I approved on behalf of all libc++ vendors but that wasn't my intention). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D137724/new/ https://reviews.llvm.org/D137724 _

[PATCH] D137876: Dummy change to test the Clang/libc++ CI

ldionne created this revision. Herald added a project: All. ldionne requested review of this revision. Herald added subscribers: cfe-commits, MaskRay. Herald added a project: clang. Pinging some folks just for awareness, I'll abandon this if CI passes. Repository: rG LLVM Github Monorepo http

[PATCH] D137876: Dummy change to test the Clang/libc++ CI

ldionne abandoned this revision. ldionne added a comment. libc++ CI passed. So I think this is working. Nice. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D137876/new/ https://reviews.llvm.org/D137876 __

[PATCH] D138042: [libc++] Trigger both Clang and libc++ CI when there are changes to both

ldionne created this revision. ldionne added a reviewer: Mordante. Herald added a subscriber: arichardson. Herald added a project: All. ldionne requested review of this revision. Herald added projects: clang, libc++. Herald added subscribers: libcxx-commits, cfe-commits. Herald added a reviewer: li

[PATCH] D138062: [clang] Don't include C++ Standard Library headers when -nostdinc is used

ldionne created this revision. ldionne added reviewers: MaskRay, phosek, arphaman. Herald added subscribers: pmatos, asb, abrachet, StephenFan, jgravelle-google, sbc100, dschuff. Herald added a project: All. ldionne requested review of this revision. Herald added subscribers: cfe-commits, aheejin.

[PATCH] D138062: [clang] Don't include C++ Standard Library headers when -nostdinc is used

ldionne added a reviewer: clang-vendors. ldionne added a comment. I'm not sure who else to add on this review. Since changing the behavior of user-facing flags can be breaking, I'm adding the vendors. Feel free to suggest more. Note that this was discovered when landing D136683

[PATCH] D138062: [clang] Don't include C++ Standard Library headers when -nostdinc is used

ldionne added a comment. Thanks! I'll land this and watch for any fallout. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D138062/new/ https://reviews.llvm.org/D138062 ___ cfe-commits mailing list cfe-comm

[PATCH] D138062: [clang] Don't include C++ Standard Library headers when -nostdinc is used

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG9621b1776a1b: [clang] Don't include C++ Standard Library headers when -nostdinc is used (authored by ldionne). Repository: rG LLVM Github Monorepo

[PATCH] D142007: [NFC] Fix "form/from" typos

ldionne accepted this revision. ldionne added a comment. This revision is now accepted and ready to land. LGTM, thanks! I don't think you need to wait for other owners to approve before landing this, this is pretty clearly an improvement. Repository: rG LLVM Github Monorepo CHANGES SINCE LAS

[PATCH] D127313: [libc++] Implement P0618R0 (Deprecating )

ldionne accepted this revision. ldionne added a comment. This revision is now accepted and ready to land. LGTM with changes applied and passing CI. Comment at: libcxx/docs/ReleaseNotes.rst:149-152 +- The contents of , ``wstring_convert`` and ``wbuffer_convert`` have been m

[PATCH] D127460: Rename GCCBuiltin into ClangBuiltin

ldionne accepted this revision as: libc++abi. ldionne added a comment. LGTM for libc++abi once my comment is addressed, which should make the libc++ CI pass. Please don't submit this until you have a green check-mark from the libc++ CI. Comment at: llvm/include/llvm/ADT/Tripl

[PATCH] D125683: [runtimes] Replace LIBCXX_ENABLE_STATIC_ABI_LIBRARY & friends by a new LIBCXX_CXX_ABI choice

ldionne added inline comments. Comment at: clang/cmake/caches/Fuchsia-stage2.cmake:124 set(RUNTIMES_${target}_LIBCXX_ENABLE_SHARED OFF CACHE BOOL "") -set(RUNTIMES_${target}_LIBCXX_ENABLE_STATIC_ABI_LIBRARY ON CACHE BOOL "") set(RUNTIMES_${target}_LIBCXX_ABI_VERSION

[PATCH] D120244: [clang][sema] Enable first-class bool support for C2x

ldionne added a comment. We've started having several internal user complaints because their system headers are suddenly triggering a warning for using ``. This seems to be caused by the fact that `#warning` is surfaced to users even when the `#warning` is present in a system header (which make

[PATCH] D120244: [clang][sema] Enable first-class bool support for C2x

ldionne added a comment. In D120244#3538660 , @aaron.ballman wrote: > In D120244#3538380 , @ldionne wrote: > >> We've started having several internal user complaints because their system >> headers are suddenly

[PATCH] D120244: [clang][sema] Enable first-class bool support for C2x

ldionne added a comment. In D120244#3540598 , @aaron.ballman wrote: > The system header including a header that's explicitly deprecated is dubious > practice, but that does still require some amount of timing coordination. I agree, and I'll be filing b

[PATCH] D125683: [runtimes] Replace LIBCXX_ENABLE_STATIC_ABI_LIBRARY & friends by a new LIBCXX_CXX_ABI choice

ldionne added inline comments. Comment at: clang/cmake/caches/Fuchsia-stage2.cmake:124 set(RUNTIMES_${target}_LIBCXX_ENABLE_SHARED OFF CACHE BOOL "") -set(RUNTIMES_${target}_LIBCXX_ENABLE_STATIC_ABI_LIBRARY ON CACHE BOOL "") set(RUNTIMES_${target}_LIBCXX_ABI_VERSION

[PATCH] D125683: [runtimes] Replace LIBCXX_ENABLE_STATIC_ABI_LIBRARY & friends by a new LIBCXX_CXX_ABI choice

ldionne updated this revision to Diff 432634. ldionne added a comment. Rebase onto main. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D125683/new/ https://reviews.llvm.org/D125683 Files: clang/cmake/caches/Android.cmake clang/cmake/caches/Fuch

[PATCH] D120244: [clang][sema] Enable first-class bool support for C2x

ldionne added a comment. In D120244#3540780 , @aaron.ballman wrote: > In D120244#3540746 , @aaron.ballman > wrote: > >> I'll roll back the `#warning` use and report back when that's done. > > I've rolled it back

[PATCH] D125683: [runtimes] Replace LIBCXX_ENABLE_STATIC_ABI_LIBRARY & friends by a new LIBCXX_CXX_ABI choice

ldionne added inline comments. Herald added a subscriber: Enna1. Comment at: clang/cmake/caches/Fuchsia-stage2.cmake:124 set(RUNTIMES_${target}_LIBCXX_ENABLE_SHARED OFF CACHE BOOL "") -set(RUNTIMES_${target}_LIBCXX_ENABLE_STATIC_ABI_LIBRARY ON CACHE BOOL "") set(RUN

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

ldionne added a comment. I just did some digging. We completed the transition to the libcxx-headers-in-the-SDK already, and now upstream and downstream Clang are the same with respect to those search paths. I think it might just be the case that you need the very latest AppleClang for that to b

[PATCH] D157283: [clang] Match -isysroot behaviour with system compiler on Darwin

ldionne added a comment. In D157283#4614177 , @DmitryPolukhin wrote: > @ldionne could you please upstream 9edb9a711503d540cf3126c0fde11ce9a0d9a7aa > (I > don't know what it is)? > Al

[PATCH] D148266: [clang][driver] Linking to just-built libc++.dylib when bootstrapping libc++ with clang

ldionne added a comment. Gentle ping. Are we waiting on anything to ship this? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D148266/new/ https://reviews.llvm.org/D148266 ___ cfe-commits mailing list cfe-

[PATCH] D158694: [libc++] Re-enable the __std_module test

ldionne abandoned this revision. ldionne added a comment. [Github PR transition cleanup] Abandoning here, will re-open as a Github PR. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D158694/new/ https://reviews.llvm.org/D158694

[PATCH] D155064: [clang][SemaCXX] Diagnose tautological uses of consteval if and is_constant_evaluated

ldionne added inline comments. Comment at: libcxx/test/std/utilities/meta/meta.const.eval/is_constant_evaluated.verify.cpp:27 static_assert(!std::is_constant_evaluated(), ""); - // expected-warning@-1 0-1 {{'std::is_constant_evaluated' will always evaluate to 'true' in a ma

[PATCH] D155064: [clang][SemaCXX] Diagnose tautological uses of consteval if and is_constant_evaluated

ldionne accepted this revision as: libc++. ldionne added a comment. LGTM for libc++. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D155064/new/ https://reviews.llvm.org/D155064 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://li

[PATCH] D155713: [clang] Fix interaction between dllimport and exclude_from_explicit_instantiation

ldionne created this revision. Herald added a project: All. ldionne requested review of this revision. Herald added subscribers: cfe-commits, bd1976llvm. Herald added a project: clang. When an entity is marked with both dllimport and exclude_from_explicit_instantiation, the compiler should not as

[PATCH] D155713: [clang] Fix interaction between dllimport and exclude_from_explicit_instantiation

ldionne added inline comments. Comment at: clang/lib/CodeGen/CodeGenModule.cpp:1515 const NamedDecl *D) const { - if (D && D->isExternallyVisible()) { + if (D && D->isExternallyVisible() && !D->hasAttr()) { if (D->hasAttr())

[PATCH] D157572: [clang] Add `[[clang::library_extension]]` attribute

ldionne added a comment. I think I like this attribute. However, I am concerned that this would make it seem more acceptable to add extensions to the library, when our policy has been that we don't (and for good reasons, we ran into big issues with e.g. `std::string_view` and we learned from t

[PATCH] D157757: [Headers] Replace __need_STDDEF_H_misc with specific __need_ macros

ldionne added a comment. This is going to be really naive, but can someone explain why we need these `__need_X` macros? Why doesn't `` simply always declare what it should declare? Also, does anybody understand the expected relationship between the C Standard Library headers and these Clang

[PATCH] D157757: [Headers] Replace __need_STDDEF_H_misc with specific __need_ macros

ldionne added inline comments. Comment at: clang/lib/Headers/stddef.h:1 /*=== stddef.h - Basic type definitions === * Making a thread out of this: > The relationship between clang's stddef.h and the C Standard Library stdde

[PATCH] D157757: [Headers] Replace __need_STDDEF_H_misc with specific __need_ macros

ldionne added inline comments. Comment at: clang/lib/Headers/stddef.h:118-122 +#ifdef __cplusplus +namespace std { +typedef decltype(nullptr) nullptr_t; +} +using ::std::nullptr_t; iana wrote: > aaron.ballman wrote: > > ldionne wrote: > > > iana wrote: > > > > aa

[PATCH] D140925: [CMake] Use Clang to infer the target triple

ldionne accepted this revision. ldionne added inline comments. This revision is now accepted and ready to land. Comment at: runtimes/CMakeLists.txt:167 +if(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR AND NOT APPLE) + set(CXX_TARGET_TRIPLE ${CMAKE_CXX_COMPILER} --target=${LLVM_RUNTIME_T

[PATCH] D157227: [Clang] Don't add `undef` for `operator new` under -fno-exceptions.

ldionne added a comment. In D157227#4564817 , @nikic wrote: > Removing noundef makes no sense to me, because the return value is noundef > even under fno-exceptions. If we remove something, it should be the nonnull > attribute, because that's what's act

[PATCH] D157324: [clang] Move the Clang CI jobs off of the libc++ builders

ldionne created this revision. Herald added a subscriber: JDevlieghere. Herald added a project: All. ldionne requested review of this revision. Herald added a project: clang. Herald added a subscriber: cfe-commits. The libc++ builders do not have the capacity to serve both libc++ and Clang CI need

[PATCH] D157324: [clang] Move the Clang CI jobs off of the libc++ builders

ldionne added a subscriber: goncharov. ldionne added a comment. @goncharov Now that we have a `buildkite-pipeline.yml` for Clang, would it make sense to stop running the "builtin" jobs like https://buildkite.com/llvm-project/premerge-checks/builds/169498#0189d1af-3c81-4ab5-a87a-ac8db177ccf0 and

<    1   2   3   4   5   6   7   8   >