AaronBallman wrote:
The goal of the status page is to convey implementation status to our users,
and so from that perspective I think N/A provides the least information to
users because it basically says "this entry doesn't apply to us". So in these
kinds of cases, `sup` conveys more
https://github.com/AaronBallman commented:
LGTM as far as the code goes, but please add some test coverage for the changes.
https://github.com/llvm/llvm-project/pull/94877
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/94208
___
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.
Given the libc++ experience, let's move forward with this PR as-is. If there's
an issue in practice, we'll disable the tests on changes to Clang at that point.
https://github.com/llvm/llvm-project/pull/94208
AaronBallman wrote:
> FYI in the libc++ CI we've been running the LLDB tests for a few months now
> and I haven't seen a single unrelated failure.
Thanks, that's really useful information!
https://github.com/llvm/llvm-project/pull/94208
___
AaronBallman wrote:
I have no objections in theory, but in practice I remain concerned about the
flakiness of lldb's tests for the impacts on Clang reviewers.
There are timeout failures, but they might be limited to Windows and thus not a
problem with your PR
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/90588
___
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.
Changes LGTM unless @jcranmer-intel still has concerns.
https://github.com/llvm/llvm-project/pull/90588
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
AaronBallman wrote:
I think we should update our documentation:
https://github.com/llvm/llvm-project/blob/b01ac5137c28fa5e1b44a5d850cb7a6ace7d8799/clang/docs/UsersManual.rst?plain=1#L1186
Overall, this seems like a sensible improvement to me and the code changes LG.
AaronBallman wrote:
> @AaronBallman Is the prototype of the implementation here at least sound? Or
> should this go somewhere completely different? Maybe in one of the TSA source
> files?
This is a semantic concern rather than a syntactic one, so I would expect this
to happen in Sema rather
https://github.com/AaronBallman approved this pull request.
LGTM! Do you need someone to land these changes on your behalf?
https://github.com/llvm/llvm-project/pull/94216
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/94216
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/88367
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman commented:
Changes generally LG aside from an update to a test, but this should also have
a release note in `clang/docs/ReleaseNotes.rst` so users know about the new
functionality and the limitations regarding macros.
@@ -533,6 +533,8 @@ __rdtscp(unsigned int *__A) {
/// \see __rdpmc
#define _rdpmc(A) __rdpmc(A)
+;
AaronBallman wrote:
As far as the changes go, that is fine. I do still think we need to change the
underlying comment parsing at some point (not as part of
@@ -107,6 +107,24 @@
///The 2nd source tile. Max size is 1024 Bytes.
#define _tile_cmmrlfp16ps(dst, a, b) __builtin_ia32_tcmmrlfp16ps(dst, a, b)
+/// Perform matrix multiplication of two tiles containing complex elements and
AaronBallman wrote:
Thank you
@@ -89,6 +89,31 @@ class TextTokenRetokenizer {
}
}
+ /// Extract a template type
+ bool lexTemplate(SmallString<32> ) {
AaronBallman wrote:
This should work okay for simple (most) cases, but we should have tests showing
the boundaries, e.g.,
https://github.com/AaronBallman approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/94123
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/94592
___
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/94592
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
I had a nice chat with @ldionne and @nikic today and we touched on the topic of
precommit CI for lldb being triggered from Clang, and that resulted in a change
of opinion and perhaps a better way for me to phrase what I'm after and how it
relates to this PR.
I think that
AaronBallman wrote:
> > One question I have is whether there will be follow-up work for other
> > thread safety attributes (`acquire_capability`, `try_acquire_capability`,
> > etc)?
>
> They already work fine in C so far. But if you are aware of some issues don't
> hesitate to let me know!
AaronBallman wrote:
> > > > > @AaronBallman, to be fair, clang is testing the wasm features in
> > > > > terms of output. So this is wiring up a bunch of tested features that
> > > > > will allow execution. Clang generally does not test execution but
> > > > > output, so we are not creating a
@@ -149,6 +149,63 @@ class TextTokenRetokenizer {
addToken();
}
+ /// Check if this line starts with @par or \par
+ bool startsWithParCommand() {
+unsigned Offset = 1;
+
+/// Skip all whitespace characters at the beginning.
+/// This needs to backtrack
AaronBallman wrote:
> > > @AaronBallman, to be fair, clang is testing the wasm features in terms of
> > > output. So this is wiring up a bunch of tested features that will allow
> > > execution. Clang generally does not test execution but output, so we are
> > > not creating a precedent here
AaronBallman wrote:
> @AaronBallman, to be fair, clang is testing the wasm features in terms of
> output. So this is wiring up a bunch of tested features that will allow
> execution. Clang generally does not test execution but output, so we are not
> creating a precedent here since that PR
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/93430
___
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/93430
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
So are we in a chicken-and-egg situation where we need some support in-tree in
order to have a reason to set up a postcommit test bot but we don't want to
land untested changes?
At the end of the day, if we're claiming support for something, we need it to
be tested and
AaronBallman wrote:
> Following the logic in this argument, would you also say it's appropriate for
> someone to commit an LLVM patch that changes how textual LLVM IR is printed
> in a way that it breaks existing tests in Clang — without updating those
> tests?
Possibly! I'm talking about
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/93966
___
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/93966
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -899,6 +899,8 @@ class Sema;
/// object argument.
bool IgnoreObjectArgument : 1;
+bool TookAddressOfOverload : 1;
AaronBallman wrote:
CC @Endilll -- it might be nice to refactor this code to use
`LLVM_PREFERRED_TYPE`, but also to fix the
@@ -5813,6 +5813,27 @@ static TypoCorrection TryTypoCorrectionForCall(Sema ,
Expr *Fn,
return TypoCorrection();
}
+// [C++26][[expr.unary.op]/p4
+// A pointer to member is only formed when an explicit &
+// is used and its operand is a qualified-id not enclosed in
@@ -999,6 +1001,8 @@ class Sema;
/// Initialization of an object of class type by constructor,
/// using either a parenthesized or braced list of arguments.
CSK_InitByConstructor,
+
+ CSK_AddressOfOverloadSet,
AaronBallman wrote:
Please
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/94118
___
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! Thank you!
https://github.com/llvm/llvm-project/pull/94118
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,7 @@
+// RUN: %clang_cc1 -Wno-return-type -std=c++23 -fsyntax-only -verify %s
+// expected-no-diagnostics
+constexpr int f() { }
+static_assert(__is_same(decltype([] constexpr -> int { }( )), int));
AaronBallman wrote:
We already have such an option,
https://github.com/AaronBallman approved this pull request.
LGTM aside from a small nit with the release notes. Do you need someone to land
this on your behalf?
https://github.com/llvm/llvm-project/pull/89657
___
cfe-commits mailing list
@@ -832,6 +832,7 @@ Bug Fixes to AST Handling
- Fixed malformed AST generated for anonymous union access in templates.
(#GH90842)
- Improved preservation of qualifiers and sugar in `TemplateNames`, including
template keyword.
+- ``forCallable`` now properly preserves
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/89657
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
> I would not agree with this specific wording. We have in the past and will in
> the future revert commits that break existing tests elsewhere in the LLVM
> project. If a patch to Clang breaks an existing test in LLDB, it's up to the
> author of the patch to work with the
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/94347
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/94123
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,7 @@
+// RUN: %clang_cc1 -Wno-return-type -std=c++23 -fsyntax-only -verify %s
+// expected-no-diagnostics
+constexpr int f() { }
+static_assert(__is_same(decltype([] constexpr -> int { }( )), int));
AaronBallman wrote:
For C++23, I think users will
@@ -2487,6 +2477,26 @@ static bool CheckConstexprFunctionBody(Sema ,
const FunctionDecl *Dcl,
return true;
}
+static bool CheckConstexprMissingReturn(Sema ,
+const FunctionDecl *Dcl) {
+ bool IsVoidOrDependentType =
https://github.com/AaronBallman commented:
Thank you for working on this!
https://github.com/llvm/llvm-project/pull/94123
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -671,6 +671,16 @@ void Parser::ParseGNUAttributeArgs(
ParseBoundsAttribute(*AttrName, AttrNameLoc, Attrs, ScopeName, ScopeLoc,
Form);
return;
+ } else if (AttrKind == ParsedAttr::AT_GuardedBy) {
+ParseGuardedByAttribute(*AttrName,
@@ -3330,6 +3340,63 @@ void Parser::DistributeCLateParsedAttrs(Decl *Dcl,
}
}
+/// GuardedBy attributes (e.g., guarded_by):
+/// AttrName '(' expression ')'
+void Parser::ParseGuardedByAttribute(IdentifierInfo ,
+ SourceLocation
https://github.com/AaronBallman commented:
Thank you for working on this!
The changes should come with a release note in clang/docs/ReleaseNotes.rst so
users know about the new functionality.
One question I have is whether there will be follow-up work for other thread
safety attributes
@@ -3330,6 +3340,63 @@ void Parser::DistributeCLateParsedAttrs(Decl *Dcl,
}
}
+/// GuardedBy attributes (e.g., guarded_by):
+/// AttrName '(' expression ')'
+void Parser::ParseGuardedByAttribute(IdentifierInfo ,
+ SourceLocation
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/94216
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/93519
___
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, thank you!
https://github.com/llvm/llvm-project/pull/93519
___
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 it makes a lot of sense for lldb to have a precommit CI pipeline which
tests changes to lldb. I don't think we're at a point where it would make sense
to enable lldb precommit CI testing for changes to clang, though.
For starters, the false
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/94208
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Aaron Ballman
Date: 2024-06-04T11:31:59-04:00
New Revision: b9f1fdcfd9803689461f0c12e04ab1743ad9a030
URL:
https://github.com/llvm/llvm-project/commit/b9f1fdcfd9803689461f0c12e04ab1743ad9a030
DIFF:
https://github.com/llvm/llvm-project/commit/b9f1fdcfd9803689461f0c12e04ab1743ad9a030.diff
@@ -961,6 +961,10 @@ def Wdeprecated : Flag<["-"], "Wdeprecated">,
Group,
HelpText<"Enable warnings for deprecated constructs and define
__DEPRECATED">;
def Wno_deprecated : Flag<["-"], "Wno-deprecated">, Group,
Visibility<[ClangOption, CC1Option]>;
+def
@@ -505,6 +505,9 @@ COMPATIBLE_LANGOPT(IncrementalExtensions, 1, 0, " True if
we want to process sta
BENIGN_LANGOPT(CheckNew, 1, 0, "Do not assume C++ operator new may not return
NULL")
+BENIGN_LANGOPT(CheckConstexprFunctionBodies, 1, 1,
+ "True if we want to
@@ -2469,11 +2469,20 @@ static bool CheckConstexprFunctionBody(Sema ,
const FunctionDecl *Dcl,
// base class sub-objects shall be a constexpr constructor.
//
// Note that this rule is distinct from the "requirements for a constexpr
- // function", so is not checked
@@ -2469,11 +2469,20 @@ static bool CheckConstexprFunctionBody(Sema ,
const FunctionDecl *Dcl,
// base class sub-objects shall be a constexpr constructor.
//
// Note that this rule is distinct from the "requirements for a constexpr
- // function", so is not checked
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/94118
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -430,6 +430,78 @@ static bool interp__builtin_iszero(InterpState , CodePtr
OpPC,
return true;
}
+static bool interp__builtin_signbit(InterpState , CodePtr OpPC,
+const InterpFrame *Frame, const Function
*F,
+
https://github.com/AaronBallman commented:
The changes generally LGTM, but should come with a release note. Do you think
there's a reasonable way to share code between the two constant expression
interpreters in this case?
https://github.com/llvm/llvm-project/pull/94118
https://github.com/AaronBallman unassigned
https://github.com/llvm/llvm-project/pull/94347
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman unassigned
https://github.com/llvm/llvm-project/pull/94347
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman unassigned
https://github.com/llvm/llvm-project/pull/94347
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman unassigned
https://github.com/llvm/llvm-project/pull/94347
___
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! Do you need someone to land this on your behalf?
https://github.com/llvm/llvm-project/pull/87793
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/87793
___
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/94203
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/94203
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/94203
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -282,6 +288,8 @@ namespace {
}
void HandleTranslationUnit(ASTContext ) override {
+ IRGenFinished = true;
AaronBallman wrote:
shouldn't this be set at the end of `HandleTranslationUnit` rather than the
beginning?
@@ -138,6 +138,8 @@ namespace {
assert(!M && "Replacing existing Module?");
M.reset(new llvm::Module(ExpandModuleName(ModuleName, CodeGenOpts), C));
+ IRGenFinished = false;
AaronBallman wrote:
Why is IR gen *finished* when we're just
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/93942
___
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 thank you!
https://github.com/llvm/llvm-project/pull/92767
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Aaron Ballman
Date: 2024-05-31T13:52:13-04:00
New Revision: 68a64812d7bac28412d43a0b4b19bae6db101c48
URL:
https://github.com/llvm/llvm-project/commit/68a64812d7bac28412d43a0b4b19bae6db101c48
DIFF:
https://github.com/llvm/llvm-project/commit/68a64812d7bac28412d43a0b4b19bae6db101c48.diff
AaronBallman wrote:
> In that case I think it might just make sense to ignore the flag in C++11 and
> later then and allow it before C++11.
I think that makes the most sense.
https://github.com/llvm/llvm-project/pull/88265
___
cfe-commits mailing
AaronBallman wrote:
C has Unicode string literals as well: https://godbolt.org/z/chdjYrK9v and so
if we're allowing raw string literals, it makes sense to also allow raw unicode
string literals IMO. I don't think we need to rename the flag though.
https://github.com/AaronBallman approved this pull request.
There are a few minor suggestions from @delcypher that should be addressed, but
overall the changes LGTM (assuming there are no precommit CI surprises after
fixing the merge conflicts).
https://github.com/llvm/llvm-project/pull/93231
https://github.com/AaronBallman commented:
I'd like to understand why we need a flag for this rather than changing the
behavior of `-fbounds-safety`. (I'd like to avoid a proliferation of flags
unless this flag is going to gate more changes in the near future.)
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/92623
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -32,5 +36,87 @@ inline bool isFunctionOrMethodOrBlockForAttrSubject(const
Decl *D) {
return isFuncOrMethodForAttrSubject(D) || llvm::isa(D);
}
+/// Return true if the given decl has a declarator that should have
+/// been processed by Sema::GetTypeForDeclarator.
+inline
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/93966
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -32,5 +36,87 @@ inline bool isFunctionOrMethodOrBlockForAttrSubject(const
Decl *D) {
return isFuncOrMethodForAttrSubject(D) || llvm::isa(D);
}
+/// Return true if the given decl has a declarator that should have
+/// been processed by Sema::GetTypeForDeclarator.
+inline
https://github.com/AaronBallman commented:
Precommit CI failures seem relevant.
https://github.com/llvm/llvm-project/pull/93966
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Timm =?utf-8?q?Bäder?= ,
Timm =?utf-8?q?Bäder?= ,
Timm =?utf-8?q?Bäder?=
Message-ID:
In-Reply-To:
@@ -0,0 +1,112 @@
+//===- MemberPointer.h --*- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Timm =?utf-8?q?B=C3=A4der?= ,
Timm =?utf-8?q?B=C3=A4der?= ,
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/91303
___
cfe-commits
Timm =?utf-8?q?Bäder?= ,
Timm =?utf-8?q?Bäder?= ,
Timm =?utf-8?q?Bäder?=
Message-ID:
In-Reply-To:
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/91303
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
@@ -92,3 +92,43 @@ extern __attribute__((address_space(0))) int
type_attr_test_2; // expec
void invalid_param_fn(__attribute__((address_space(1))) int i); //
expected-error {{parameter may not be qualified with an address space}}
typeof(invalid_param_fn)
https://github.com/AaronBallman commented:
In general, I think this is heading in the right direction. I did have a
suggestion that may be worth considering.
https://github.com/llvm/llvm-project/pull/93503
___
cfe-commits mailing list
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/93503
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -74,8 +74,8 @@ On Unix-like Systems
https://llvm.org/docs/CMake.html#frequently-used-cmake-variables;>frequently
used cmake variables
for more options.
AaronBallman wrote:
[Re: lines 72 to
76]
I think we should update this text at
https://github.com/AaronBallman approved this pull request.
I looked through the review and I think this is generally an improvement. We
may find a need to relax some `const` later, but I did not spot any obvious
concerns.
That said, I'd like @ChuanqiXu9 to give the final sign-off on this as
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/93493
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -501,6 +501,9 @@ Improvements to Clang's diagnostics
- Clang emits a ``-Wparentheses`` warning for expressions with consecutive
comparisons like ``x < y < z``.
Fixes #GH20456.
+- Clang now diagnoses missing format attributes for non-template functions and
+
@@ -0,0 +1,277 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -Wmissing-format-attribute %s
+
+typedef unsigned short char16_t;
+typedef unsigned int char32_t;
+typedef __WCHAR_TYPE__ wchar_t;
+typedef __SIZE_TYPE__ size_t;
+typedef __builtin_va_list va_list;
+
@@ -7131,6 +7138,114 @@ static void handleSwiftAsyncAttr(Sema , Decl *D,
const ParsedAttr ) {
checkSwiftAsyncErrorBlock(S, D, ErrorAttr, AsyncAttr);
}
+// This function is called only if function call is not inside template body.
+// TODO: Add call for function calls
@@ -0,0 +1,277 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -Wmissing-format-attribute %s
+
+typedef unsigned short char16_t;
+typedef unsigned int char32_t;
+typedef __WCHAR_TYPE__ wchar_t;
+typedef __SIZE_TYPE__ size_t;
+typedef __builtin_va_list va_list;
+
1 - 100 of 4911 matches
Mail list logo
