AaronBallman wrote:
Thank you for putting together the experiment @efriedma-quic, it's greatly
appreciated! I agree with closing it for now; we can resurrect it later if
necessary.
https://github.com/llvm/llvm-project/pull/102390
___
cfe-commits mail
efriedma-quic wrote:
Note I'm not really attached to merging this either. I mostly posted this to
have a space to discuss the consequences of #70307/#100452. If the decision is
that we don't want this, I'm fine with that.
Also, if we change our mind based on user reports, this would be prett
https://github.com/efriedma-quic closed
https://github.com/llvm/llvm-project/pull/102390
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
hubert-reinterpretcast wrote:
I don't see a compelling reason for the extension and I find its behaviour
somewhat arbitrary: why is it okay to allow the overflow in the definition of
an enumerator but not okay to allow for `alignas`?
https://github.com/llvm/llvm-project/pull/102390
___
AaronBallman wrote:
> I think a default-error, sfinae-failing diagnostic should be pretty safe;
> everyone will get the correct diagnostics by default, and some narrow subset
> of people can disable them if they cause issues.
Clang community stance has consistently been that we have no interes
glandium wrote:
> and the fix is already applied from looking at
> https://android.googlesource.com/platform/frameworks/native/+/master/libs/nativewindow/include/android/hardware_buffer.h#329
it's not part of any released NDK, and it's common to be stuck with older NDKs.
Most people are probab
efriedma-quic wrote:
I targeted all overflows with this fix because we were missing diagnostics for
all overflows. For example, "enum{x=99*99};" only produces a pedantic
warning on clang 18. So if we need the extra flexibility, we should just add
it for everything.
I think a default
cor3ntin wrote:
I agree with @AaronBallman that, given there hasn't been a lot of outstanding
complaints following https://github.com/llvm/llvm-project/pull/70307, we don't
want to allow that sort of relaxation of constexpr evaluation as it's both non
conforming (and potentially problematic fo
AaronBallman wrote:
CC @zygoloid @hubert-reinterpretcast @cor3ntin @shafik for more opinions
regarding diagnostic behavior
> Not sure if this is really worth doing if it only affects the Android NDK;
> Android trunk has been fixed. And presumably most people will use the
> compiler from the N
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Eli Friedman (efriedma-quic)
Changes
Recent Android NDK headers are broken on 32-bit because they contain an invalid
shift, and older versions of clang didn't catch this. Demote the error to a
default-error with a flag so it can be suppre
https://github.com/efriedma-quic created
https://github.com/llvm/llvm-project/pull/102390
Recent Android NDK headers are broken on 32-bit because they contain an invalid
shift, and older versions of clang didn't catch this. Demote the error to a
default-error with a flag so it can be suppresse
11 matches
Mail list logo
