https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/136323
>From 3beecb29772e13c6a1a41877e5e8cbbfb17a88f2 Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Fri, 18 Apr 2025 12:26:36 -0400
Subject: [PATCH 1/5] Control analysis-based diagnostics with #pra
@@ -2493,9 +2493,10 @@ class sema::AnalysisBasedWarnings::InterProceduralData {
CalledOnceInterProceduralData CalledOnceData;
};
-static unsigned isEnabled(DiagnosticsEngine &D, unsigned diag) {
- return (unsigned)!D.isIgnored(diag, SourceLocation());
-}
+template
+static
@@ -2504,23 +2505,37 @@ sema::AnalysisBasedWarnings::AnalysisBasedWarnings(Sema
&s)
NumUninitAnalysisVariables(0), MaxUninitAnalysisVariablesPerFunction(0),
NumUninitAnalysisBlockVisits(0),
MaxUninitAnalysisBlockVisitsPerFunction(0) {
+}
+
+// We need this he
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/136323
>From 3beecb29772e13c6a1a41877e5e8cbbfb17a88f2 Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Fri, 18 Apr 2025 12:26:36 -0400
Subject: [PATCH 1/4] Control analysis-based diagnostics with #pra
@@ -2493,35 +2493,44 @@ class sema::AnalysisBasedWarnings::InterProceduralData {
CalledOnceInterProceduralData CalledOnceData;
};
-static unsigned isEnabled(DiagnosticsEngine &D, unsigned diag) {
- return (unsigned)!D.isIgnored(diag, SourceLocation());
+static bool isEnable
@@ -2493,35 +2493,44 @@ class sema::AnalysisBasedWarnings::InterProceduralData {
CalledOnceInterProceduralData CalledOnceData;
};
-static unsigned isEnabled(DiagnosticsEngine &D, unsigned diag) {
- return (unsigned)!D.isIgnored(diag, SourceLocation());
+static bool isEnable
@@ -1202,6 +1202,30 @@ Clang also allows you to push and pop the current
warning state. This is
particularly useful when writing a header file that will be compiled by
other people, because you don't know what warning flags they build with.
+Note that the following diagnostic
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/136323
>From 3beecb29772e13c6a1a41877e5e8cbbfb17a88f2 Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Fri, 18 Apr 2025 12:26:36 -0400
Subject: [PATCH 1/2] Control analysis-based diagnostics with #pra
@@ -0,0 +1,77 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -Werror=unreachable-code-aggressive %s
+
+// Test that analysis-based warnings honor #pragma diagnostic controls. These
+// diagnostics are triggered at the end of a function body, so the pragma needs
+// to be enabled thr
@@ -1202,6 +1202,30 @@ Clang also allows you to push and pop the current
warning state. This is
particularly useful when writing a header file that will be compiled by
other people, because you don't know what warning flags they build with.
+Note that the following diagnostic
AaronBallman wrote:
> > Do we need a deprecation period for this change? This will break anyone
> > using the old names in scripts and whatnot.
> > Also, the changes will need something in the release notes so users know
> > about the new names.
>
> Is there a specific way to mark flags as dep
AaronBallman wrote:
> > @cor3ntin I question if `-Wloop-analysis` should be completely rewritten
> > using dataflow analysis, rather than AST based matching.
>
> That's an interesting idea, but I don't think that should stop us from
> landing this improvement. Maybe we want to open an issue fo
8f2 Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Fri, 18 Apr 2025 12:26:36 -0400
Subject: [PATCH] Control analysis-based diagnostics with #pragma
Previously, analysis-based diagnostics (like -Wconsumed) had to be
enabled at file scope in order to be run at the end of each function
body. T
https://github.com/AaronBallman commented:
So I think the things that are missing are:
1) If `Insert` or `Remove` is true, we should diagnose those as being
deprecated and recommend using `disable-insert` or `disable-remove` instead.
2) A release note should be added to clang-tools-extra/docs/R
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/136182
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman created
https://github.com/llvm/llvm-project/pull/136182
I put this under -Wunitialized because that's the same group it's under in GCC.
Fixes #41104
>From a195528d6db796b8925be3d43802ced6d931a9a2 Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date
@@ -2336,16 +2336,9 @@ bool Type::isArithmeticType() const {
}
bool Type::hasBooleanRepresentation() const {
- if (isBooleanType())
-return true;
-
- if (const EnumType *ET = getAs())
-return ET->getDecl()->getIntegerType()->isBooleanType();
-
- if (const AtomicType
@@ -2336,16 +2336,9 @@ bool Type::isArithmeticType() const {
}
bool Type::hasBooleanRepresentation() const {
- if (isBooleanType())
-return true;
-
- if (const EnumType *ET = getAs())
-return ET->getDecl()->getIntegerType()->isBooleanType();
-
- if (const AtomicType
Timm =?utf-8?q?B=C3=A4der?=
Message-ID:
In-Reply-To:
https://github.com/AaronBallman approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/117671
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cg
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/135407
>From c7e0132617ab01c12b393876b39381171996b793 Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Fri, 11 Apr 2025 13:03:07 -0400
Subject: [PATCH 1/6] Disable -fdollars-in-identifiers by default
Cl
Author: Aaron Ballman
Date: 2025-04-17T07:36:48-04:00
New Revision: a84a6f7dd68b218757e192fe21a806c80ef0b63d
URL:
https://github.com/llvm/llvm-project/commit/a84a6f7dd68b218757e192fe21a806c80ef0b63d
DIFF:
https://github.com/llvm/llvm-project/commit/a84a6f7dd68b218757e192fe21a806c80ef0b63d.diff
AaronBallman wrote:
> hi @AaronBallman, no unfortunately we didn't make any progress here, and I
> just verified that reproducer from [#118480
> (comment)](https://github.com/llvm/llvm-project/pull/118480#issuecomment-2538988006)
> is still triggering the issue (with -std=c++20).
Internal val
AaronBallman wrote:
> > Can you do the JSONNodeDumper as well so the two stay somewhat in-sync?
>
> Looks like that goes through `APValue::printPretty()`, so nothing to do for
> that.
Ah, good to know, thanks!
https://github.com/llvm/llvm-project/pull/136130
__
https://github.com/AaronBallman approved this pull request.
LGTM assuming precommit CI is happy too.
https://github.com/llvm/llvm-project/pull/136130
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinf
AaronBallman wrote:
> > > ping, is this still a problem?
> >
> >
> > yes, this is still happening. but I am currently lacking cycles to dig
> > deeper into expression evaluation to see if this is the right fix given the
> > reproducer. @VitaNuo was to take a look with some limited capacity, b
https://github.com/AaronBallman commented:
Can you do the JSONNodeDumper as well so the two stay somewhat in-sync?
https://github.com/llvm/llvm-project/pull/136130
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/m
https://github.com/AaronBallman approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/135938
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Aaron Ballman
Date: 2025-04-17T07:32:12-04:00
New Revision: 4bd9b9e9adf9db1a326e2f2fa616c714beb83c4f
URL:
https://github.com/llvm/llvm-project/commit/4bd9b9e9adf9db1a326e2f2fa616c714beb83c4f
DIFF:
https://github.com/llvm/llvm-project/commit/4bd9b9e9adf9db1a326e2f2fa616c714beb83c4f.diff
@@ -8623,6 +8624,13 @@ inline bool Type::isIntegralOrEnumerationType() const {
inline bool Type::isBooleanType() const {
if (const auto *BT = dyn_cast(CanonicalType))
return BT->getKind() == BuiltinType::Bool;
+ if (const EnumType *ET = dyn_cast(CanonicalType)) {
---
https://github.com/AaronBallman approved this pull request.
LGTM! Precommit CI failures appear to be unrelated.
https://github.com/llvm/llvm-project/pull/135957
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mail
@@ -2336,16 +2336,9 @@ bool Type::isArithmeticType() const {
}
bool Type::hasBooleanRepresentation() const {
- if (isBooleanType())
-return true;
-
- if (const EnumType *ET = getAs())
-return ET->getDecl()->getIntegerType()->isBooleanType();
-
- if (const AtomicType
@@ -8623,6 +8624,13 @@ inline bool Type::isIntegralOrEnumerationType() const {
inline bool Type::isBooleanType() const {
if (const auto *BT = dyn_cast(CanonicalType))
return BT->getKind() == BuiltinType::Bool;
+ if (const EnumType *ET = dyn_cast(CanonicalType)) {
+//
Author: Aaron Ballman
Date: 2025-04-17T07:13:31-04:00
New Revision: c536967af123c30b43f186133e8719e0090f24a6
URL:
https://github.com/llvm/llvm-project/commit/c536967af123c30b43f186133e8719e0090f24a6
DIFF:
https://github.com/llvm/llvm-project/commit/c536967af123c30b43f186133e8719e0090f24a6.diff
AaronBallman wrote:
> We should disable the warning if we're preprocessing asm, which should mostly
> solve the issue with warnings.
Effectively checking for `LangOpts.DollarIdents || LangOpts.AsmPreprocessor`?
Or do you think `DollarIdents` should be true if `AsmPreprocessor` is true?
https:
AaronBallman wrote:
> > IMO, we are better served by a warning diagnostic if we detect these are
> > misused. `ParseCXXCondition` (or the C equivalent, but since you are
> > returning bool it seems you're not concerned about C?) might be a good
> > place to set a variable to enable the warning
AaronBallman wrote:
> Doesn't the Linux kernel use it for syscall names? Might be wrong on this.
CC @nathanchance @nickdesaulniers for more information, but even if the kernel
does, is it a significant imposition to pass `-fdollars-in-identifiers` to
enable the extension explicitly?
https://g
@@ -1284,7 +1284,11 @@ void StmtPrinter::VisitSourceLocExpr(SourceLocExpr
*Node) {
}
void StmtPrinter::VisitEmbedExpr(EmbedExpr *Node) {
- llvm::report_fatal_error("Not implemented");
+ // Embed parameters are not reflected in the AST, so there is no way to print
--
@@ -4049,5 +4050,13 @@ void Preprocessor::HandleEmbedDirective(SourceLocation
HashLoc, Token &EmbedTok,
if (Callbacks)
Callbacks->EmbedDirective(HashLoc, Filename, isAngled, MaybeFileRef,
*Params);
- HandleEmbedDirectiveImpl(HashLoc, *Param
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/135957
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman commented:
Can fix up the formatting issues found by precommit CI, and the change should
also come with a release note.
https://github.com/llvm/llvm-project/pull/135957
___
cfe-commits mailing list
cfe-commits@lists.llv
AaronBallman wrote:
> It appears that gcc only disallows '$' in identifiers in C++26 mode. Not sure
> how relevant that is to clang.
> [bugzilla](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110343) Or am I
> misreading that thread?
I get the same reading, but I am not certain we want to foll
AaronBallman wrote:
> If you don't want to do anything fancy, can you just add a warning in
> Lexer::LexTokenInternal if we see a '$' (where we set the token type to
> tok::unknown)? That should be easy to implement, and have zero impact on
> lexer performance.
Okay, that's pretty reasonable.
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/135407
>From c7e0132617ab01c12b393876b39381171996b793 Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Fri, 11 Apr 2025 13:03:07 -0400
Subject: [PATCH 1/5] Disable -fdollars-in-identifiers by default
Cl
https://github.com/AaronBallman requested changes to this pull request.
> This patch adds support for GCC bound member functions extension:
> https://gcc.gnu.org/onlinedocs/gcc/Bound-member-functions.html
>
> Related issue: #22495 Closes #82727
I think this requires an RFC justifying carrying
https://github.com/AaronBallman approved this pull request.
LGTM! We could do further coding style adjustments if we wanted (particularly
around naming conventions), but I don't insist; this is still forward progress.
Thank you!
https://github.com/llvm/llvm-project/pull/135861
@@ -44,3 +44,5 @@
// ERR-AARCH64_32: error: unsupported argument 'small' to option '-mcmodel='
for target 'aarch64_32-unknown-linux'
// ERR-LOONGARCH64-PLT-EXTREME: error: invalid argument '-mcmodel=extreme' not
allowed with '-fplt'
+
+// CHECK: error: unsupported argument '
@@ -1,5 +1,5 @@
// RUN: not %clang -### -c --target=i686 -mcmodel=medium %s 2>&1 | FileCheck
--check-prefix=ERR-MEDIUM %s
-// RUN: %clang --target=x86_64 -### -c -mcmodel=tiny %s 2>&1 | FileCheck
--check-prefix=TINY %s
+// RUN: not %clang --target=x86_64 -### -c -mcmodel=tiny %
@@ -7,7 +7,7 @@
#define foo`bar /* expected-error {{whitespace required after macro name}} */
#define foo2!bar /* expected-warning {{whitespace recommended after macro
name}} */
-#define foo3$bar /* expected-error {{'$' in identifier}} */
+#define foo3$bar /* expected-er
AaronBallman wrote:
> @AaronBallman Were you able to manually cherry-pick this one?
Yup! That was handled in https://github.com/llvm/llvm-project/pull/135798 thank
you!
https://github.com/llvm/llvm-project/pull/135660
___
cfe-commits mailing list
cfe
AaronBallman wrote:
> So the changes needed to move this patch forward are to only perform the
> attribute check when we're checking for a valid redefinition, not type
> compatibility in general. A follow-up to improve upon this can do the layout
> check when looking for compatibility. Alterna
AaronBallman wrote:
> > What if we add unsigned clang_getCStringLength(CXString); which gets the
> > length but not the contents? Do we need to package pointer and size
> > together?
>
> Where do we store the length, if we can't add a new field to `CXString`, and
> we can't use `private_flags
AaronBallman wrote:
> Yes please. :-) And thanks very much.
You're welcome, thanks for bringing the issue up and sticking with me until I
understood it. :-D I've posted https://github.com/llvm/llvm-project/pull/135798
to backport to 20.x
https://github.com/llvm/llvm-project/pull/86131
___
AaronBallman wrote:
> `CXString::private_flags` only has 2 bits used. Could we use the rest for the
> size? Would it be enough?
I'd be a bit uncomfortable with that. It would work, but it means we're never
able to add any new private flags in the future.
> There's also the possibility to not
AaronBallman wrote:
> > ping, is this still a problem?
>
> yes, this is still happening. but I am currently lacking cycles to dig deeper
> into expression evaluation to see if this is the right fix given the
> reproducer. @VitaNuo was to take a look with some limited capacity, but I
> think s
@@ -717,6 +717,12 @@ bool Sema::checkMustTailAttr(const Stmt *St, const Attr
&MTA) {
return false;
}
+ if (const FunctionDecl *CalleeDecl = CE->getDirectCallee();
+ CalleeDecl && CalleeDecl->hasAttr()) {
+Diag(St->getBeginLoc(), diag::err_musttail_mismatch) <<
https://github.com/AaronBallman approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/116785
___
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! The precommit CI failure appears to be unrelated.
https://github.com/llvm/llvm-project/pull/100830
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/135660
___
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/135791
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -24,7 +24,7 @@ int templateFunction(T value)
__attribute__((annotate("works")));
// CHECK: ClassDecl=Test:3:7 (Definition) Extent=[3:1 - 17:2]
// CHECK-NEXT: CXXAccessSpecifier=:4:1 (Definition) Extent=[4:1 - 4:8]
-// CHECK-NEXT: CXXMethod=aMethod:5:51 Extent=[5:3 - 5:60]
@@ -2,3 +2,26 @@
_Alignas(int) struct c1; // expected-warning {{'_Alignas' attribute ignored}}
alignas(int) struct c1; // expected-warning {{'alignas' attribute ignored}}
+
+
+__attribute__(()) [[]] alignas(int) int a; // expected-none TODO: actually
this line should be an er
@@ -3062,13 +3062,16 @@ class Parser : public CodeCompletionHandler {
bool CouldBeBitField = false);
Decl *ParseHLSLBuffer(SourceLocation &DeclEnd);
- void MaybeParseMicrosoftAttributes(ParsedAttributes &Attrs) {
+ bool MaybeParseMicrosoftAttrib
@@ -1,5 +1,5 @@
// REQUIRES: x86-registered-target
-// RUN: %clang_cc1 %s -triple i386-apple-darwin10 -fasm-blocks -emit-llvm -o -
| FileCheck %s
+// RUN: %clang_cc1 %s -triple i386-apple-darwin10 -fdollars-in-identifiers
-fasm-blocks -emit-llvm -o - | FileCheck %s
https://github.com/AaronBallman approved this pull request.
This LGTM, are you happy with it @erichkeane?
https://github.com/llvm/llvm-project/pull/134465
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/li
AaronBallman wrote:
> > I'm confused -- how is there existing code depending on a builtin which
> > doesn't yet exist in Clang? Are we copying these builtins from somewhere
> > else?
>
> This is part of the pointer authentication support we are upstreaming, all of
> which has been in use for
AaronBallman wrote:
/cherry-pick d0e4af8a88dc7a0377677000d0c92104ff215347
https://github.com/llvm/llvm-project/pull/135660
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
> I put up #135660 for review, thank you for bringing this up!
@pdimov should now be resolved via d0e4af8a88dc7a0377677000d0c92104ff215347; do
you need this backported to Clang 20 I suppose?
https://github.com/llvm/llvm-project/pull/86131
___
https://github.com/AaronBallman milestoned
https://github.com/llvm/llvm-project/pull/135660
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rom fa878e011da7a04ff53ce706b8a9a4f16f82fc18 Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Tue, 15 Apr 2025 10:36:48 -0400
Subject: [PATCH] Allow some attributes on declarations after definitions
The deprecated, maybe_unused, and nodiscard standard attributes may all
be applied to a redeclaration afte
AaronBallman wrote:
> LGTM. Or should I say, "Thanks, I hate it".
>
> Do you know how likely it is WG14 come up with a good solution for "arbitrary
> function pointer" ?
The last we heard on this topic was
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2230.htm which was discussed
in Brno
@@ -4036,6 +4036,7 @@ LangOptions getFormattingLangOpts(const FormatStyle
&Style) {
LangOpts.MicrosoftExt = 1;// To get kw___try, kw___finally.
LangOpts.DeclSpecKeyword = 1; // To get __declspec.
LangOpts.C99 = 1; // To get kw_restrict for non-underscore-prefixed res
AaronBallman wrote:
> > If we're going to do this, I think we need better diagnostics. Just
> > straight disabling this is going to give very confusing diagnostics to
> > anyone actually using dollar-signs in identifiers.
> > Some ideas:
> > ```
> > * We can give a warning if we see a "$" adjac
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/135407
>From c7e0132617ab01c12b393876b39381171996b793 Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Fri, 11 Apr 2025 13:03:07 -0400
Subject: [PATCH 1/4] Disable -fdollars-in-identifiers by default
Cl
@@ -0,0 +1,33 @@
+// RUN: %clang_cc1 %s -triple x86_64-windows -fsyntax-only
-Wcast-function-type -Wno-cast-function-type-strict -verify=windows
+// RUN: %clang_cc1 %s -triple x86_64-windows -fsyntax-only
-Wcast-function-type -Wno-cast-function-type-strict -x c++ -verify=windows
@@ -732,6 +732,16 @@
CodeGenTypes::arrangeBuiltinFunctionDeclaration(CanQualType resultType,
RequiredArgs::All);
}
+const CGFunctionInfo &
+CodeGenTypes::arrangeSYCLKernelCallerDeclaration(QualType resultType,
+
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/135660
>From 1e9fce88cc5e1d4f75e7126a394ec8f9440b8d63 Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Mon, 14 Apr 2025 15:21:04 -0400
Subject: [PATCH 1/2] Silence -Wcast-function-type warnings on idioma
https://github.com/AaronBallman approved this pull request.
LGTM, thank you for the cleanup! The behavioral changes all seem defensible to
me. Should those have a release note?
https://github.com/llvm/llvm-project/pull/135561
___
cfe-commits mailing l
AaronBallman wrote:
I put up https://github.com/llvm/llvm-project/pull/135660 for review, thank you
for bringing this up!
https://github.com/llvm/llvm-project/pull/86131
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cg
-project/pull/86131
>From 1e9fce88cc5e1d4f75e7126a394ec8f9440b8d63 Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Mon, 14 Apr 2025 15:21:04 -0400
Subject: [PATCH] Silence -Wcast-function-type warnings on idiomatic Windows
code
On Windows, GetProcAddress() is the API used to dynamically l
AaronBallman wrote:
> @erichkeane @AaronBallman This is my first time participating in an open
> source project.
Welcome!
> I would like to ask if you have the same opinion so far. I have revised many
> versions over and over again. I just hope that the requirements can be
> clarified.
FWI
@@ -717,6 +717,13 @@ bool Sema::checkMustTailAttr(const Stmt *St, const Attr
&MTA) {
return false;
}
+ if (const FunctionDecl *CalleeDecl = CE->getDirectCallee();
+ CalleeDecl && CalleeDecl->hasAttr()) {
+Diag(St->getBeginLoc(), diag::err_musttail_mismatch) <<
AaronBallman wrote:
Ah, derp, the issue was me not passing `-Wextra` (sorry!). Hmm, yeah, this does
seem like a case we probably want to suppress, for similar reasons as we do for
`dlsym`.
https://github.com/llvm/llvm-project/pull/86131
___
cfe-commi
@@ -0,0 +1,17 @@
+// RUN: %clang_cc1 -verify -fsyntax-only %s
+
+int __attribute__((not_tail_called)) foo1(int a) {
+return a + 1;
+}
+
+
+int foo2(int a) {
+[[clang::musttail]]
+return foo1(a); // expected-error {{cannot perform a tail call to
function 'foo1' bec
@@ -0,0 +1,17 @@
+// RUN: %clang_cc1 -verify -fsyntax-only %s
+
+int __attribute__((not_tail_called)) foo1(int a) {
+return a + 1;
+}
+
+
+int foo2(int a) {
+[[clang::musttail]]
+return foo1(a); // expected-error {{cannot perform a tail call to
function 'foo1' bec
AaronBallman wrote:
> Since you aren't diagnosing reinterpret-casting a function pointer from
> `void*`, because this would warn on idiomatic POSIX code (`dlsym` returns
> `void*`), it seemed to me that you'd be interested in not warning on
> idiomatic Windows code (`GetProcAddress` returns `F
https://github.com/AaronBallman commented:
Do we need a deprecation period for this change? This will break anyone using
the old names in scripts and whatnot.
Also, the changes will need something in the release notes so users know about
the new names.
https://github.com/llvm/llvm-project/pul
https://github.com/AaronBallman approved this pull request.
LGTM, thanks!
https://github.com/llvm/llvm-project/pull/134398
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -458,6 +458,8 @@ def warn_compat_pp_embed_directive : Warning<
InGroup, DefaultIgnore;
def err_pp_embed_dup_params : Error<
"cannot specify parameter '%0' twice in the same '#embed' directive">;
+def err_pp_embed_device_file : Error<
+ "device files are not yet supporte
AaronBallman wrote:
> > > I just noticed there's no documentation for
> > > `__builtin_virtual_member_address()` so I'm addressing that.
> > > Due to code drift and time I realized that they disagree as to whether
> > > they should take `C*` or `C&` so I'm going to make them both accept
> > >
AaronBallman wrote:
> This warning creates issues under Windows, where reinterpret-casting from
> FARPROC to the actual function type is common.
>
> #92738
> [boostorg/interprocess#259](https://github.com/boostorg/interprocess/issues/259)
>
> Reinterpret-casting a function pointer to another
AaronBallman wrote:
> If we're going to do this, I think we need better diagnostics. Just straight
> disabling this is going to give very confusing diagnostics to anyone actually
> using dollar-signs in identifiers.
>
> Some ideas:
>
> * We can give a warning if we see a "$" adjacent to a
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/135407
>From c7e0132617ab01c12b393876b39381171996b793 Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Fri, 11 Apr 2025 13:03:07 -0400
Subject: [PATCH 1/3] Disable -fdollars-in-identifiers by default
Cl
AaronBallman wrote:
> @AaronBallman do you have any further requests or changes for this PR?
The only outstanding issue I know of is:
https://github.com/llvm/llvm-project/pull/100830/files#r2039375386
https://github.com/llvm/llvm-project/pull/100830
@@ -717,6 +717,12 @@ bool Sema::checkMustTailAttr(const Stmt *St, const Attr
&MTA) {
return false;
}
+ if (const FunctionDecl *CalleeDecl = CE->getDirectCallee();
+ CalleeDecl && CalleeDecl->hasAttr()) {
+Diag(St->getBeginLoc(), diag::err_musttail_mismatch) <<
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/135407
>From c7e0132617ab01c12b393876b39381171996b793 Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Fri, 11 Apr 2025 13:03:07 -0400
Subject: [PATCH 1/2] Disable -fdollars-in-identifiers by default
Cl
@@ -717,6 +717,12 @@ bool Sema::checkMustTailAttr(const Stmt *St, const Attr
&MTA) {
return false;
}
+ if (const FunctionDecl *CalleeDecl = CE->getDirectCallee();
+ CalleeDecl && CalleeDecl->hasAttr()) {
+Diag(St->getBeginLoc(), diag::err_musttail_mismatch) <<
n Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Fri, 11 Apr 2025 13:03:07 -0400
Subject: [PATCH] Disable -fdollars-in-identifiers by default
Clang used to enable -fdollars-in-identifiers by default for
compatibility with GCC. However, this is no longer a conforming
extension after WG21 P2558R2
Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Fri, 11 Apr 2025 09:55:04 -0400
Subject: [PATCH] Fix failed assertions with invalid #embed parameters
If the invalid parameter was not the last parameter given, we would
fail to skip to the end of the directive and trip a failed assertion.
Fi
https://github.com/AaronBallman approved this pull request.
LGTM assuming precommit CI comes back green. Thank you!
https://github.com/llvm/llvm-project/pull/135370
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/
AaronBallman wrote:
> > on Windows we could use something like COM1 on Windows.
>
> How would that look like?
`#embed "COM1" limit(1)`
But when I try that on my Windows machine, I get a file not found error.
Perhaps try `#embed "NUL" limit(1)`?
https://github.com/llvm/llvm-project/pull/13537
1 - 100 of 5135 matches
Mail list logo
