https://github.com/carlosgalvezp closed
https://github.com/llvm/llvm-project/pull/102364
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
carlosgalvezp wrote:
Boost/MPL 1.86.0 is now released!
https://github.com/boostorg/mpl/releases/tag/boost-1.86.0
Thus I'm merging this patch, thanks for the reviews! I will keep an eye in case
there's need for a revert.
https://github.com/llvm/llvm-project/pull/102364
___
thesamesam wrote:
re boost: I was thinking the same re waiting until it's out but I didn't want
to say it. Sounds good.
https://github.com/llvm/llvm-project/pull/102364
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi
https://github.com/AaronBallman approved this pull request.
Code changes LGTM
https://github.com/llvm/llvm-project/pull/102364
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
> > How soon after 1.86 landing do you plan to submit this?
>
> I was thinking as soon as it's released, I don't see a reason for waiting any
> longer. The sooner we merge the sooner we can collect feedback and re-adjust
> if needed. But of course it's up to the Clang owner
carlosgalvezp wrote:
> How soon after 1.86 landing do you plan to submit this?
I was thinking as soon as it's released, I don't see a reason for waiting any
longer. The sooner we merge the sooner we can collect feedback and re-adjust if
needed. But of course it's up to the Clang owners to deci
rupprecht wrote:
> Since boost/mpl is at the core of issues and many projects depend directly or
> transitively on it, I think it might be good to wait until version 1.86 is
> released, so people can bump to a release version instead of trunk.
>
> It should be around the corner,
> [AFAICS](ht
carlosgalvezp wrote:
Since boost/mpl is at the core of issues and many projects depend directly or
transitively on it, I think it might be good to wait until version 1.86 is
released, so people can bump to a release version instead of trunk.
It should be around the corner, [AFAICS](https://ww
rupprecht wrote:
> > The last time I followed this attempt was https://reviews.llvm.org/D150226,
> > where there was objection because it was ignored in system headers, so
> > effectively impossible to discover how widespread this is. When did this
> > become unignored in system headers?
>
>
AaronBallman wrote:
> The last time I followed this attempt was https://reviews.llvm.org/D150226,
> where there was objection because it was ignored in system headers, so
> effectively impossible to discover how widespread this is. When did this
> become unignored in system headers?
https://g
rupprecht wrote:
The last time I followed this attempt was https://reviews.llvm.org/D150226,
where there was objection because it was ignored in system headers, so
effectively impossible to discover how widespread this is. When did this become
unignored in system headers?
I remember fixing al
carlosgalvezp wrote:
Thanks for the review and the info @thesamesam ! AFAICS the MPL issue is fixed
on trunk, targeting release 1.86.
About Pycuda, it's also stemming from MPL according to the build logs.
So it seems to me the solution to these projects is too "just" bump to the
newer MPL ver
https://github.com/thesamesam edited
https://github.com/llvm/llvm-project/pull/102364
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/thesamesam approved this pull request.
Thanks @AaronBallman!
Other than gdb (thank you Carlos for working on that), I'm only aware of two
issues:
* qtlocation -> boost (https://bugs.gentoo.org/895516 ->
https://bugreports.qt.io/browse/QTBUG-116652 ->
https://github.com/boos
carlosgalvezp wrote:
By the way, the latest revision of the GDB patch (improved after the first
round of review) can be found here:
https://sourceware.org/pipermail/gdb-patches/2024-June/210252.html
https://github.com/llvm/llvm-project/pull/102364
__
@@ -49,6 +49,9 @@ C++ Specific Potentially Breaking Changes
few users and can be written as ``__is_same(__remove_cv(T),
decltype(nullptr))``,
which GCC supports as well.
+- The warning `-Wenum-constexpr-conversion` has been upgraded into a hard
+ compiler error that cann
https://github.com/carlosgalvezp updated
https://github.com/llvm/llvm-project/pull/102364
>From 88f1a873d6c6ef06ad9a1847d098d65845cf1469 Mon Sep 17 00:00:00 2001
From: Carlos Galvez
Date: Tue, 6 Aug 2024 22:50:10 +0200
Subject: [PATCH 1/2] [clang] Turn -Wenum-constexpr-conversion into a hard
e
AaronBallman wrote:
CC @thesamesam @mgorny (and anyone else who wants to chime in) for opinions on
whether this change will cause significant issues for distro maintainers
https://github.com/llvm/llvm-project/pull/102364
___
cfe-commits mailing list
c
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Carlos Galvez (carlosgalvezp)
Changes
The warning has been active for a few releases now, first only in user code,
later in system headers, and finally as an error by default.
Therefore, we believe it is now time to transition into a hard
https://github.com/carlosgalvezp created
https://github.com/llvm/llvm-project/pull/102364
The warning has been active for a few releases now, first only in user code,
later in system headers, and finally as an error by default.
Therefore, we believe it is now time to transition into a hard err
20 matches
Mail list logo
