AaronBallman wrote:
Duplicate of https://github.com/llvm/llvm-project/pull/97208 ... which I
reviewed.
https://github.com/llvm/llvm-project/pull/98945
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listi
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/98945
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -3298,7 +3298,18 @@ static void RenderFloatingPointOptions(const ToolChain
&TC, const Driver &D,
}
// Handle __FINITE_MATH_ONLY__ similarly.
- if (!HonorINFs && !HonorNaNs)
+ bool InfValues = true;
+ bool NanValues = true;
+ auto processArg = [&](const auto *Arg) {
https://github.com/AaronBallman deleted
https://github.com/llvm/llvm-project/pull/97342
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -3298,7 +3298,18 @@ static void RenderFloatingPointOptions(const ToolChain
&TC, const Driver &D,
}
// Handle __FINITE_MATH_ONLY__ similarly.
- if (!HonorINFs && !HonorNaNs)
+ bool InfValues = true;
+ bool NanValues = true;
+ auto processArg = [&](const auto *Arg) {
@@ -3298,7 +3298,18 @@ static void RenderFloatingPointOptions(const ToolChain
&TC, const Driver &D,
}
// Handle __FINITE_MATH_ONLY__ similarly.
- if (!HonorINFs && !HonorNaNs)
+ bool InfValues = true;
+ bool NanValues = true;
+ auto processArg = [&](const auto *Arg) {
AaronBallman wrote:
Given the amount of pain involved, I think this should be applied as a C++23
change rather than applied as a DR. I'd like to avoid adding a feature flag for
this if possible (I'd prefer warning-default-as-error instead, but that doesn't
seem particularly plausible here), bu
Author: Aaron Ballman
Date: 2024-07-15T12:13:49-04:00
New Revision: c2fab5a4c69c857061b06b9a826bf4730821e483
URL:
https://github.com/llvm/llvm-project/commit/c2fab5a4c69c857061b06b9a826bf4730821e483
DIFF:
https://github.com/llvm/llvm-project/commit/c2fab5a4c69c857061b06b9a826bf4730821e483.diff
@@ -347,6 +355,8 @@ class ComplexExprEmitter
#define HANDLEBINOP(OP)
\
ComplexPairTy VisitBin##OP(const BinaryOperator *E) {
\
QualType promotionTy = getPromotionType(
@@ -328,12 +328,20 @@ class ComplexExprEmitter
}
}
- QualType getPromotionType(QualType Ty, bool IsDivOpCode = false) {
+ QualType getPromotionType(FPOptionsOverride Features, QualType Ty,
+bool IsDivOpCode = false) {
if (auto *CT = Ty-
https://github.com/AaronBallman commented:
Thank you for working on this!
https://github.com/llvm/llvm-project/pull/98736
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -442,6 +442,9 @@ def warn_drv_deprecated_arg : Warning<
def warn_drv_deprecated_arg_no_relaxed_template_template_args : Warning<
"argument '-fno-relaxed-template-template-args' is deprecated">,
InGroup;
+def warn_drv_deprecated_arg_ofast : Warning<
+ "argument '-Ofast'
@@ -931,7 +931,8 @@ def O : Joined<["-"], "O">, Group,
def O_flag : Flag<["-"], "O">, Visibility<[ClangOption, CC1Option, FC1Option]>,
Alias, AliasArgs<["1"]>;
def Ofast : Joined<["-"], "Ofast">, Group,
- Visibility<[ClangOption, CC1Option, FlangOption]>;
+ Visibility<[Clan
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/98736
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -34,8 +34,8 @@ void LangOptions::resetNonModularOptions() {
// invocations that cannot be round-tripped to arguments.
// FIXME: we should derive this automatically from ImpliedBy in tablegen.
AllowFPReassoc = UnsafeFPMath;
- NoHonorNaNs = FiniteMathOnly;
- NoHonorInf
@@ -0,0 +1,45 @@
+// RUN: %clang_cc1 %s -verify -fno-builtin -Werror=comment -Wno-error=abi
-Wfatal-errors=assume -Wno-fatal-errors=assume
+
+#define diagnose_if(...) __attribute__((diagnose_if(__VA_ARGS__)))
+
+template
+void diagnose_if_wcomma() diagnose_if(b, "oh no", "warnin
AaronBallman wrote:
> @AaronBallman was there anything else that needed to be done? Just did a
> merge because ReleaseNotes was edited but this should be fine
Nope, this is approved to land.
https://github.com/llvm/llvm-project/pull/92767
___
cfe-com
Author: Aaron Ballman
Date: 2024-07-15T09:31:14-04:00
New Revision: bd04ac0694cc9fb3c43a4acb2f7cd1db08eba673
URL:
https://github.com/llvm/llvm-project/commit/bd04ac0694cc9fb3c43a4acb2f7cd1db08eba673
DIFF:
https://github.com/llvm/llvm-project/commit/bd04ac0694cc9fb3c43a4acb2f7cd1db08eba673.diff
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/98489
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/98489
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
> I'm not sure I understand what happened here, since `_Alignas` did work
> properly before this change, right? How/why are `_Alignas` and `alignas`
> acting differently from eachother in C23 mode?
`_Alignas` on a field used to work properly before
b9cf7f1066cc7ec11c6074d1
AaronBallman wrote:
> @AaronBallman could you please review?
>
> I've fixed at least the LLDB tests. There was an actual bug in function
> parameters construction that was revealed by the invariant check.
>
> However, I can't run the whole LLDB suite. Even among the reported failing
> tests,
AaronBallman wrote:
Thank you for letting me know, I've pushed a fix for that.
Curiously, it seems `_Alignof` on an expression always returns the *preferred*
alignment and not the actual alignment. This is consistent with GCC, even if
it's a bit surprising: https://godbolt.org/z/nvKx98ff9
htt
Author: Aaron Ballman
Date: 2024-07-15T09:03:30-04:00
New Revision: 1af3a89a4b384cbc5a6b111a0f7756085de818cd
URL:
https://github.com/llvm/llvm-project/commit/1af3a89a4b384cbc5a6b111a0f7756085de818cd
DIFF:
https://github.com/llvm/llvm-project/commit/1af3a89a4b384cbc5a6b111a0f7756085de818cd.diff
AaronBallman wrote:
> This started to cause
>
> ```
> $ cat test.c
> #include
> void f(void) {
> char a[strlen("x")];
> (void) a;
> }
> ```
>
> ```
> $ clang -Wall -fsyntax-only test.c
> test.c:3:12: warning: variable length array folded to constant array as an
> extension [-Wgnu-fold
AaronBallman wrote:
Just making sure that this didn't fall off your radar; it seems like a good fix
for us to get into Clang 19 before the branch, if possible.
https://github.com/llvm/llvm-project/pull/92767
___
cfe-commits mailing list
cfe-commits@li
AaronBallman wrote:
> @budimirarandjelovicsyrmia Any updates? Should we revert the patch?
I already reverted in 9d1017204a253782a82d1b7d16c59eea3f811a11 so the bots have
been slowly getting back to green
https://github.com/llvm/llvm-project/pull/70024
__
https://github.com/AaronBallman approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/97894
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Aaron Ballman
Date: 2024-07-12T10:50:48-04:00
New Revision: ac2426e08e6f7c1eb97725f1d6cc35a8a6ddc5ef
URL:
https://github.com/llvm/llvm-project/commit/ac2426e08e6f7c1eb97725f1d6cc35a8a6ddc5ef
DIFF:
https://github.com/llvm/llvm-project/commit/ac2426e08e6f7c1eb97725f1d6cc35a8a6ddc5ef.diff
https://github.com/AaronBallman approved this pull request.
LGTM -- @cor3ntin, are you happy with the changes as well?
https://github.com/llvm/llvm-project/pull/89078
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bi
@@ -233,6 +233,7 @@ ENUM_CODEGENOPT(StructReturnConvention,
StructReturnConventionKind, 2, SRCK_Defa
CODEGENOPT(RelaxAll , 1, 0) ///< Relax all machine code instructions.
CODEGENOPT(RelaxedAliasing , 1, 0) ///< Set when -fno-strict-aliasing is
enabled.
+CODEGENOPT
https://github.com/AaronBallman approved this pull request.
LGTM aside from a minor code formatting suggestion.
https://github.com/llvm/llvm-project/pull/76612
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailm
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/76612
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/97210
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
> It's a bit weird to have an extension warning given we seem to not support u8
> in older language modes at all https://www.godbolt.org/z/1KrqGeT1q
>
> I think we should support the extension before in addition of having a
> warning for it @AaronBallman
It's not an extens
https://github.com/AaronBallman approved this pull request.
Changes LGTM but please be sure to add a release note when landing so users
know about the improvement.
https://github.com/llvm/llvm-project/pull/97424
___
cfe-commits mailing list
cfe-commit
AaronBallman wrote:
> > Do you have an idea as to why the type location is invalid in the first
> > place?
>
> Looking at the new test, my guess is that `auto` remains undeduced, so it has
> nowhere to point out to.
Even when it's undeduced, we should still have a source location for it becau
https://github.com/AaronBallman commented:
Do you have an idea as to why the type location is invalid in the first place?
https://github.com/llvm/llvm-project/pull/98622
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi
AaronBallman wrote:
There are multiple distinct issues that were caught:
build failure -- https://lab.llvm.org/buildbot/#/builders/72/builds/1123
sanitizer failure -- https://lab.llvm.org/buildbot/#/builders/164/builds/920
different failure from above --
https://lab.llvm.org/buildbot/#/builders
@@ -860,9 +861,15 @@ bool Preprocessor::HandleIdentifier(Token &Identifier) {
ModuleImportLoc = Identifier.getLocation();
NamedModuleImportPath.clear();
IsAtImport = true;
-ModuleImportExpectsIdentifier = true;
CurLexerCallback = CLK_LexAfterModuleImport;
https://github.com/AaronBallman commented:
The changes generally LGTM but I'd love to hear from @ChuanqiXu9 as well.
https://github.com/llvm/llvm-project/pull/90574
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/
@@ -905,6 +912,7 @@ void Preprocessor::Lex(Token &Result) {
// This token is injected to represent the translation of '#include "a.h"'
// into "import a.h;". Mimic the notional ';'.
case tok::annot_module_include:
+case tok::annot_repl_input_end:
---
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/90574
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman approved this pull request.
Presuming precommit CI comes back without surprises, this LGTM!
https://github.com/llvm/llvm-project/pull/95969
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/c
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/98146
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
> Perhaps also update
>
> https://github.com/llvm/llvm-project/blob/345861b186645f82c0b812427fdafe6ebd62a058/clang/www/c_status.html#L1283-L1285
Oh what the heck, I thought I already did that! :-D But yes, I'll update that
when landing, thank you!
https://github.com/llvm/l
AaronBallman wrote:
> The android NDK code is wrong, but this no longer compiles (even with
> -Wno-error).
Well that's unfortunate! Thank you for letting us know.
@alanzhao1 do you think it's reasonable for the workaround to only apply to
code in system headers, or does the NDK get included a
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/98617
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/98497
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/98525
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,65 @@
+// RUN: %clang_cc1 -std=c2y %s -verify -Wno-gnu-alignof-expression
+
+/* WG14 N3244: Partial
+ * Slay Some Earthly Demons I
+ *
+ * NB: the committee adopted:
+ * Annex J Item 21 (including additional change) -- no, we lack explicit
documentation
+ * Annex J
AaronBallman wrote:
> Thank you very much for fixing that:)
Happy to help, thank you for your contribution!
https://github.com/llvm/llvm-project/pull/98016
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/
AaronBallman wrote:
> > Yup, that resolved the issue:
> > https://lab.llvm.org/buildbot/#/builders/144/builds/2082 -- not certain why
> > that builder has a different default value for `-std` though. Clang
> > defaults to C17, but that builder seems to be defaulting to C99.
>
> This bot targe
AaronBallman wrote:
Precommit CI failure on Windows appears to be unrelated:
```
_bk;t=1720718143606 TEST 'lld :: ELF/basic-sparcv9.s'
FAILED
_bk;t=1720718143606Exit Code: 1
_bk;t=1720718143606
_bk;t=1720718143606Command Output (stdout):
_bk;t=17
@@ -0,0 +1,2 @@
+if not config.root.clang_enable_cir:
+clang.unsupported = True
AaronBallman wrote:
It looks like this is causing precommit CI failures:
```
llvm-lit.py: C:\ws\src\llvm\utils\lit\lit\llvm\config.py:57: note: using lit
tools: C:\Program Files\
https://github.com/AaronBallman approved this pull request.
LGTM, thank you!
https://github.com/llvm/llvm-project/pull/70024
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
Yup, that resolved the issue:
https://lab.llvm.org/buildbot/#/builders/144/builds/2082 -- not certain why
that builder has a different default value for `-std` though. Clang defaults to
C17, but that builder seems to be defaulting to C99.
https://github.com/llvm/llvm-proje
AaronBallman wrote:
I've relanded the changes with a fix here in commit
0171e23647d58f65c1cddbc22e16fda2bafa6e85, hopefully that sticks!
https://github.com/llvm/llvm-project/pull/98016
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://li
Author: Constantin Kronbichler
Date: 2024-07-11T13:26:24-04:00
New Revision: 0171e23647d58f65c1cddbc22e16fda2bafa6e85
URL:
https://github.com/llvm/llvm-project/commit/0171e23647d58f65c1cddbc22e16fda2bafa6e85
DIFF:
https://github.com/llvm/llvm-project/commit/0171e23647d58f65c1cddbc22e16fda2bafa6
AaronBallman wrote:
I think adding `-std=c11` to the `RUN` line should help; it at least removes
the "is a C11 extension" diagnostics. (I guess this builder isn't defaulting to
C17 for some reason?)
https://github.com/llvm/llvm-project/pull/98016
___
AaronBallman wrote:
Okay, the Windows issue seems to have gone away with a full rebuild, which
makes *way* more sense to me. :-) So I think it's just the
`llvm-clang-x86_64-sie-ubuntu-fast` issue that needs to be resolved.
https://github.com/llvm/llvm-project/pull/98016
___
AaronBallman wrote:
I've reverted the changes in 9f283bfb9e66d57fefeb3a28318ec40081fa9a24 because
of the bot breakage. Oddly, I am seeing a different failure on Windows locally:
```
FAIL: Clang :: Sema/undefined-internal-basic.c (1 of 1)
TEST 'Clang :: Sema/undefined-interna
Author: Aaron Ballman
Date: 2024-07-11T13:07:06-04:00
New Revision: 9f283bfb9e66d57fefeb3a28318ec40081fa9a24
URL:
https://github.com/llvm/llvm-project/commit/9f283bfb9e66d57fefeb3a28318ec40081fa9a24
DIFF:
https://github.com/llvm/llvm-project/commit/9f283bfb9e66d57fefeb3a28318ec40081fa9a24.diff
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/98016
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
I filed https://github.com/llvm/llvm-project/issues/98504 to track the
remaining issue.
https://github.com/llvm/llvm-project/pull/98016
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/
https://github.com/AaronBallman approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/98016
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -842,8 +842,8 @@ class LLVM_LIBRARY_VISIBILITY NaClTargetInfo : public
OSTargetInfo {
} else if (Triple.getArch() == llvm::Triple::mipsel) {
// Handled on mips' setDataLayout.
} else {
- assert(Triple.getArch() == llvm::Triple::le32);
- this->resetDa
https://github.com/AaronBallman approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/97585
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -3165,7 +3165,17 @@ bool Lexer::LexEndOfFile(Token &Result, const char
*CurPtr) {
// C99 5.1.1.2p2: If the file is non-empty and didn't end in a newline, issue
// a pedwarn.
- if (CurPtr != BufferStart && (CurPtr[-1] != '\n' && CurPtr[-1] != '\r')) {
+ if (CurPtr !=
@@ -8955,6 +8960,36 @@ unsigned clang_Cursor_isExternalSymbol(CXCursor C,
CXString *language,
return 0;
}
+enum CX_BinaryOperatorKind clang_Cursor_getBinaryOpcode(CXCursor C) {
+ if (C.kind != CXCursor_BinaryOperator &&
+ C.kind != CXCursor_CompoundAssignOperator) {
+
@@ -8955,6 +8960,36 @@ unsigned clang_Cursor_isExternalSymbol(CXCursor C,
CXString *language,
return 0;
}
+enum CX_BinaryOperatorKind clang_Cursor_getBinaryOpcode(CXCursor C) {
+ if (C.kind != CXCursor_BinaryOperator &&
+ C.kind != CXCursor_CompoundAssignOperator) {
+
@@ -8955,6 +8960,36 @@ unsigned clang_Cursor_isExternalSymbol(CXCursor C,
CXString *language,
return 0;
}
+enum CX_BinaryOperatorKind clang_Cursor_getBinaryOpcode(CXCursor C) {
+ if (C.kind != CXCursor_BinaryOperator &&
+ C.kind != CXCursor_CompoundAssignOperator) {
+
@@ -2181,6 +2193,60 @@ def from_cursor_result(res, fn, args):
res._tu = args[0]._tu
return res
+class BinaryOperator(BaseEnumeration):
+"""
+Describes the BinaryOperator of a declaration
+"""
+
+# The unique kind objects, index by id.
+_kind
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/98489
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman commented:
Thank you for picking this back up! Hopefully @Endilll can comment on the
python bits, but the changes generally LGTM aside from some very minor nits.
One thing that should be added is a release note (in
`clang/docs/ReleaseNotes.rst` so users know abo
Martin =?utf-8?q?Storsj=C3=B6?=
Message-ID:
In-Reply-To:
https://github.com/AaronBallman approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/98478
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org
@@ -3165,7 +3165,17 @@ bool Lexer::LexEndOfFile(Token &Result, const char
*CurPtr) {
// C99 5.1.1.2p2: If the file is non-empty and didn't end in a newline, issue
// a pedwarn.
- if (CurPtr != BufferStart && (CurPtr[-1] != '\n' && CurPtr[-1] != '\r')) {
+ if (CurPtr !=
https://github.com/AaronBallman commented:
The only other unreserved name I could find in the file is:
https://github.com/llvm/llvm-project/blob/d9c26b9d560f4362503b8f0ec97a52a0a36a57ce/clang/lib/Headers/avx512fp16intrin.h#L99
(uses `h`)
so we might as well fix this at the same time. We should
@@ -203,6 +203,12 @@ def FmaF16F128 : Builtin, F16F128MathTemplate {
let Prototype = "T(T, T, T)";
}
+def Fmaf16 : Builtin, F16F128MathTemplate {
AaronBallman wrote:
Why is this needed when we have:
https://github.com/llvm/llvm-project/blob/a3913a19185e351
AaronBallman wrote:
> This is generally looking great, and I think it's ready to go as soon as you
> can finish the tests. (You said you weren't able to update all the tests —
> did you have questions about the remaining tests?)
>
> I did have a thought, though. Are we confident that the in-me
AaronBallman wrote:
> Oh that makes sense so
>
> ```
> static void f();
> void *k = _Generic(&f, void (*)(void) : 0, default : f);
> ```
>
> should be ok since it is not in the result expression?
Correct, that's a good test case to add! Similarly, it would be good to add one
like:
```
void *k
@@ -0,0 +1,10 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s -pedantic-errors
AaronBallman wrote:
```suggestion
// RUN: %clang_cc1 -fsyntax-only -verify %s -Wno-pointer-arith -pedantic-errors
```
https://github.com/llvm/llvm-project/pull/98016
_
@@ -0,0 +1,10 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s -std=c23 -pedantic-errors
+
+// expected-no-diagnostics
+
+static int f(void);
+
+int main(void)
+{
+typeof(f()) x;
AaronBallman wrote:
```suggestion
typeof(&f) x;
```
https://github.com/llvm/
@@ -0,0 +1,10 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s -pedantic-errors
+
+// expected-no-diagnostics
+
+static int f(void);
+
+int main(void)
+{
+int x = sizeof f();
AaronBallman wrote:
```suggestion
int x = sizeof(f);
```
https://github.com/llvm
@@ -0,0 +1,10 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s -pedantic-errors
AaronBallman wrote:
```suggestion
// RUN: %clang_cc1 -fsyntax-only -verify %s -Wno-pointer-arith -pedantic-errors
```
https://github.com/llvm/llvm-project/pull/98016
_
@@ -0,0 +1,12 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s -pedantic-errors
+
+static void *f(void); // expected-error {{function 'f' has internal linkage
but is not defined}}
+
+int main(void)
+{
+int j = _Generic(&f, void *(*)(void): 10, default: 20);
+// expected-no
@@ -554,6 +554,9 @@ Attribute Changes in Clang
Improvements to Clang's diagnostics
---
+- Clang now emits an error instead of a warning for `undefined_internal`
AaronBallman wrote:
```suggestion
- Clang now emits an error inste
@@ -0,0 +1,11 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s -pedantic-errors
AaronBallman wrote:
```suggestion
// RUN: %clang_cc1 -fsyntax-only -verify %s -Wno-unused -pedantic-errors
```
because the point of the test is the error about internal linkage, not ab
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/98016
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman commented:
I think the test cases should all be combined into a single file -- we don't
stop issuing diagnostics after the first one, so it should be fine to put them
all together into one file.
https://github.com/llvm/llvm-project/pull/98016
___
AaronBallman wrote:
> For the other two I had something similar but that still misses this point:
> — part of the expression in a generic association that is not the result
> expression of its generic
> selection
> But that might also be because I don't understand this point well enough. I
> do
AaronBallman wrote:
@budimirarandjelovicsyrmia -- do you need someone to land these changes on your
behalf?
https://github.com/llvm/llvm-project/pull/70307
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/
@@ -0,0 +1,45 @@
+// RUN: %clang_cc1 %s -verify -fno-builtin -Werror=comment -Wno-error=abi
-Wfatal-errors=assume -Wno-fatal-errors=assume
+
+#define diagnose_if(...) __attribute__((diagnose_if(__VA_ARGS__)))
+
+template
+void diagnose_if_wcomma() diagnose_if(b, "oh no", "warnin
https://github.com/AaronBallman approved this pull request.
LGTM, thank you for the fix!
https://github.com/llvm/llvm-project/pull/98102
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,45 @@
+// RUN: %clang_cc1 %s -verify -fno-builtin -Werror=comment -Wno-error=abi
-Wfatal-errors=assume -Wno-fatal-errors=assume
+
+#define diagnose_if(...) __attribute__((diagnose_if(__VA_ARGS__)))
+
+template
+void diagnose_if_wcomma() diagnose_if(b, "oh no", "warnin
@@ -0,0 +1,45 @@
+// RUN: %clang_cc1 %s -verify -fno-builtin -Werror=comment -Wno-error=abi
-Wfatal-errors=assume -Wno-fatal-errors=assume
+
+#define diagnose_if(...) __attribute__((diagnose_if(__VA_ARGS__)))
+
+template
+void diagnose_if_wcomma() diagnose_if(b, "oh no", "warnin
@@ -0,0 +1,45 @@
+// RUN: %clang_cc1 %s -verify -fno-builtin -Werror=comment -Wno-error=abi
-Wfatal-errors=assume -Wno-fatal-errors=assume
+
+#define diagnose_if(...) __attribute__((diagnose_if(__VA_ARGS__)))
+
+template
+void diagnose_if_wcomma() diagnose_if(b, "oh no", "warnin
https://github.com/AaronBallman commented:
Sorry for the delay in review!
This seems like the right direction to go, in general. As @erichkeane, it's a
bit hard to review due to the whitespace-only changes and changes to
`__is_trivially_equality_comparable`, you should remove those changes or
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/70976
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -686,6 +686,8 @@ Improvements to Clang's diagnostics
- Clang no longer emits a "no previous prototype" warning for Win32 entry
points under ``-Wmissing-prototypes``.
Fixes #GH94366.
+- Clang now diagnoses non-C++11 integer constant expressions. Fixes #GH59863
---
701 - 800 of 3411 matches
Mail list logo
