AaronBallman wrote:
One concern I have is about compile time performance impacts; the implicit
fallthrough diagnostics require building a CFG and that can be expensive. It
may be worth putting up a branch on https://llvm-compile-time-tracker.com/ to
see how it impacts compile times
https://gi
@@ -0,0 +1,155 @@
+==
+Clang-Change-Namespace
+==
+
+.. contents::
+
+.. toctree::
+ :maxdepth: 1
+
+:program:`clang-change-namespace` can be used to change the surrounding
+namespaces of class/function definitions.
+
+Classes/functions in
@@ -0,0 +1,155 @@
+==
+Clang-Change-Namespace
+==
+
+.. contents::
+
+.. toctree::
+ :maxdepth: 1
+
+:program:`clang-change-namespace` can be used to change the surrounding
+namespaces of class/function definitions.
+
+Classes/functions in
@@ -0,0 +1,155 @@
+==
+Clang-Change-Namespace
AaronBallman wrote:
```suggestion
clang-change-namespace
```
https://github.com/llvm/llvm-project/pull/148277
___
cfe-commits mailing list
cfe-commits@l
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/148277
___
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 working on the documentation for this, it's really appreciated! I
had a few questions, but in general this is looking good.
https://github.com/llvm/llvm-project/pull/148277
___
cfe-commits maili
@@ -0,0 +1,59 @@
+// RUN: clang-repl "int i = 10;" 'extern "C" int printf(const char*,...);' \
+// RUN:'auto r1 = printf("i = %d\n", i);' | FileCheck
--check-prefix=CHECK-DRIVER %s
+// UNSUPPORTED: system-aix
+// CHECK-DRIVER: i = 10
+// RUN: cat %s | clang-repl -Xcc
@@ -3,9 +3,80 @@
// RUN: cat %s | clang-repl -Xcc -xc | FileCheck %s
// RUN: cat %s | clang-repl -Xcc -std=c++11 | FileCheck %s
-// Fails with `Symbols not found: [ __clang_Interpreter_SetValueNoAlloc ]`.
// UNSUPPORTED: hwasan
+
+char c = 'a'; c
+// CHECK: (char) 'a'
+
c
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/148701
___
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/148701
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -6298,10 +6304,43 @@ static bool isImmediateSinkBlock(const CFGBlock *Blk) {
// at least for now, but once we have better support for exceptions,
// we'd need to carefully handle the case when the throw is being
// immediately caught.
- if (llvm::any_of(*Blk, [](const
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/149357
___
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/149357
Libclang is a wrapper around the Clang frontend, and frontends are not
security-sensitive components of the LLVM project. However, libclang is often
embedded in people's downstream tools, so it's best to m
@@ -1,7 +1,7 @@
// RUN: %clang_cc1 -fsyntax-only -Wno-strict-prototypes -verify %s
void f() {
- int *ptr = malloc(sizeof(int) * 10); // expected-error{{call to undeclared
library function 'malloc' with type}} \
+ int *ptr = malloc(sizeof(int) * 10); // expected-error{{call
@@ -22,7 +22,7 @@ void_typedef f2_helper(void);
static void f2(void *buf) {
F12_typedef* x;
x = f2_helper();
- memcpy((&x[1]), (buf), 1); // expected-warning{{call to undeclared library
function 'memcpy' with type 'void *(void *, const void *}} \
+ memcpy((&x[1]), (buf),
https://github.com/AaronBallman created
https://github.com/llvm/llvm-project/pull/149314
The previous text was "implicitly declaring library function 'exp' with
type 'double (double)'" which helpfully mentioned the type. However, it
was also confusing because an implicit function declaration in
@@ -300,16 +640,17 @@ llvm::Expected
Interpreter::ExtractValueFromExpr(Expr *E) {
using namespace clang;
// Temporary rvalue struct that need special care.
-REPL_EXTERNAL_VISIBILITY void *
+REPL_EXTERNAL_VISIBILITY extern "C" void *
AaronBallman wrote:
That
AaronBallman wrote:
/cherry-pick 7e0fde0c2f6b0b9d727ce9196956b36e91961ac4
https://github.com/llvm/llvm-project/pull/149190
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman milestoned
https://github.com/llvm/llvm-project/pull/149190
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -300,16 +640,17 @@ llvm::Expected
Interpreter::ExtractValueFromExpr(Expr *E) {
using namespace clang;
// Temporary rvalue struct that need special care.
-REPL_EXTERNAL_VISIBILITY void *
+REPL_EXTERNAL_VISIBILITY extern "C" void *
AaronBallman wrote:
IIRC,
@@ -0,0 +1,59 @@
+// RUN: clang-repl "int i = 10;" 'extern "C" int printf(const char*,...);' \
+// RUN:'auto r1 = printf("i = %d\n", i);' | FileCheck
--check-prefix=CHECK-DRIVER %s
+// UNSUPPORTED: system-aix
+// CHECK-DRIVER: i = 10
+// RUN: cat %s | clang-repl -Xcc
https://github.com/AaronBallman approved this pull request.
LGTM, thanks for the quick fix!
https://github.com/llvm/llvm-project/pull/149079
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-com
AaronBallman wrote:
> > > Seems like this should have a release note?
> >
> >
> > What is the bar for a change to be release noted? This change is pretty
> > much "make clang-scan-deps less likely to crash" and personally I don't
> > think it deserves a release note.
>
> If a user can see di
AaronBallman wrote:
> @andykaylor @AaronBallman What do you think about making the warnings about
> complex range behave as described above? Any feedback would be greatly
> appreciated.
CC @zahiraam @jcranmer-intel for additional opinion
My first thought is that this is an improvement, but th
https://github.com/AaronBallman commented:
Ugh, sorry for the delayed review! I had a comment several days ago but forgot
to hit Submit. :-/
https://github.com/llvm/llvm-project/pull/147959
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https
@@ -30,11 +30,16 @@ SanitizerSpecialCaseList::create(const
std::vector &Paths,
std::unique_ptr
SanitizerSpecialCaseList::createOrDie(const std::vector &Paths,
- llvm::vfs::FileSystem &VFS) {
+ llvm::vfs
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/147959
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
> @AaronBallman Do you happen to know if there’s precedent for this?
We recently started [documenting our
guarantees](https://clang.llvm.org/docs/LibClang.html#abi-and-api-stability),
and I think this falls under "Removing an explicitly deprecated API after a
suitably long
@@ -3,9 +3,80 @@
// RUN: cat %s | clang-repl -Xcc -xc | FileCheck %s
// RUN: cat %s | clang-repl -Xcc -std=c++11 | FileCheck %s
-// Fails with `Symbols not found: [ __clang_Interpreter_SetValueNoAlloc ]`.
// UNSUPPORTED: hwasan
+
+char c = 'a'; c
+// CHECK: (char) 'a'
+
c
@@ -3,9 +3,80 @@
// RUN: cat %s | clang-repl -Xcc -xc | FileCheck %s
// RUN: cat %s | clang-repl -Xcc -std=c++11 | FileCheck %s
-// Fails with `Symbols not found: [ __clang_Interpreter_SetValueNoAlloc ]`.
// UNSUPPORTED: hwasan
+
+char c = 'a'; c
+// CHECK: (char) 'a'
+
c
@@ -3,9 +3,80 @@
// RUN: cat %s | clang-repl -Xcc -xc | FileCheck %s
// RUN: cat %s | clang-repl -Xcc -std=c++11 | FileCheck %s
-// Fails with `Symbols not found: [ __clang_Interpreter_SetValueNoAlloc ]`.
// UNSUPPORTED: hwasan
+
+char c = 'a'; c
+// CHECK: (char) 'a'
+
c
@@ -0,0 +1,59 @@
+// RUN: clang-repl "int i = 10;" 'extern "C" int printf(const char*,...);' \
+// RUN:'auto r1 = printf("i = %d\n", i);' | FileCheck
--check-prefix=CHECK-DRIVER %s
+// UNSUPPORTED: system-aix
+// CHECK-DRIVER: i = 10
+// RUN: cat %s | clang-repl -Xcc
AaronBallman wrote:
I think this should have an
[RFC](https://llvm.org/docs/DeveloperPolicy.html#proposing-major-changes-rfcs)
which explains what needs these extensions are solving. The fully-qualified
name sounds like a use case for reflection, and neither macro seems to have a
purpose in C
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/148018
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1083,6 +1085,92 @@ void SemaHLSL::ActOnFinishRootSignatureDecl(
bool SemaHLSL::handleRootSignatureElements(
ArrayRef Elements) {
+ // Define some common error handling functions
+ bool HadError = false;
+ auto ReportError = [this, &HadError](SourceLocation Loc, uint
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/148881
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -4397,6 +4397,9 @@ def ext_ms_impcast_fn_obj : ExtWarn<
"implicit conversion between pointer-to-function and pointer-to-object is a "
"Microsoft extension">, InGroup;
+def warn_imp_constructor_pointer_to_bool : Warning<
+"implicit conversion from %0 to %1 calls %q2;
https://github.com/AaronBallman approved this pull request.
So long as @philnik777 is okay with the libc++ changes, this LGTM
https://github.com/llvm/llvm-project/pull/143667
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.or
https://github.com/AaronBallman created
https://github.com/llvm/llvm-project/pull/148881
This fixes a failed assertion with an operator call expression which comes from
a macro expansion when performing analysis for nullability attributes.
Fixes #138371
>From f1afcc9aeefc352de338fa62eb0fbf122
AaronBallman wrote:
It looks like precommit CI found a relevant failure:
```
TEST 'Clang Tools :: clang-query/trailing-comma.c' FAILED
Exit Code: 1
Command Output (stdout):
--
# shell parser error on RUN: at line 14: clang-query -c "$(echo "ma
AaronBallman wrote:
Hello all! There was a request to hold a Clang Area Team discussion about this
topic, which is scheduled for [Thur Jul 17 at 4pm Eastern
Time](https://www.timeanddate.com/worldclock/converter.html?iso=20250717T20&p1=1440&p2=1241&p3=4747&p4=195).
Link to the meeting tele
@@ -0,0 +1,59 @@
+// RUN: clang-repl "int i = 10;" 'extern "C" int printf(const char*,...);' \
+// RUN:'auto r1 = printf("i = %d\n", i);' | FileCheck
--check-prefix=CHECK-DRIVER %s
+// UNSUPPORTED: system-aix
+// CHECK-DRIVER: i = 10
+// RUN: cat %s | clang-repl -Xcc
@@ -250,17 +254,35 @@ const ASTContext &Value::getASTContext() const {
return getInterpreter().getASTContext();
}
-void Value::dump() const { print(llvm::outs()); }
+void Value::dump() { print(llvm::outs()); }
void Value::printType(llvm::raw_ostream &Out) const {
- Out <
@@ -3,9 +3,80 @@
// RUN: cat %s | clang-repl -Xcc -xc | FileCheck %s
// RUN: cat %s | clang-repl -Xcc -std=c++11 | FileCheck %s
-// Fails with `Symbols not found: [ __clang_Interpreter_SetValueNoAlloc ]`.
// UNSUPPORTED: hwasan
+
+char c = 'a'; c
+// CHECK: (char) 'a'
+
c
@@ -3,9 +3,80 @@
// RUN: cat %s | clang-repl -Xcc -xc | FileCheck %s
// RUN: cat %s | clang-repl -Xcc -std=c++11 | FileCheck %s
-// Fails with `Symbols not found: [ __clang_Interpreter_SetValueNoAlloc ]`.
// UNSUPPORTED: hwasan
+
+char c = 'a'; c
+// CHECK: (char) 'a'
+
c
@@ -3,9 +3,80 @@
// RUN: cat %s | clang-repl -Xcc -xc | FileCheck %s
// RUN: cat %s | clang-repl -Xcc -std=c++11 | FileCheck %s
-// Fails with `Symbols not found: [ __clang_Interpreter_SetValueNoAlloc ]`.
// UNSUPPORTED: hwasan
+
+char c = 'a'; c
+// CHECK: (char) 'a'
+
c
@@ -3,9 +3,80 @@
// RUN: cat %s | clang-repl -Xcc -xc | FileCheck %s
// RUN: cat %s | clang-repl -Xcc -std=c++11 | FileCheck %s
-// Fails with `Symbols not found: [ __clang_Interpreter_SetValueNoAlloc ]`.
// UNSUPPORTED: hwasan
+
+char c = 'a'; c
+// CHECK: (char) 'a'
+
c
https://github.com/AaronBallman commented:
Precommit CI found some crashing issues that will need to be addressed, and I
had some more testing requests to make sure we handle basics properly.
https://github.com/llvm/llvm-project/pull/148701
___
cfe-co
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/148701
___
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! 8 declarator chunks is actually quite a bit, I suspect 4 is a more
sensible default for the average TU. 2 might be a bit too few for what I'd
suspect is the average use case.
https://github.com/llvm/llvm-project/pull/148788
https://github.com/AaronBallman approved this pull request.
LGTM, thank you!
https://github.com/llvm/llvm-project/pull/148726
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -18,18 +18,341 @@
#include "clang/Frontend/CompilerInstance.h"
#include "clang/Interpreter/Interpreter.h"
#include "clang/Interpreter/Value.h"
+#include "clang/Lex/Preprocessor.h"
#include "clang/Sema/Lookup.h"
#include "clang/Sema/Sema.h"
#include "llvm/Support/Error.h
@@ -200,6 +192,24 @@ class Interpreter {
llvm::SmallVector ValuePrintingInfo;
std::unique_ptr JITBuilder;
+
+ /// @}
+ /// @name Value and pretty printing support
+ /// @{
+
+ std::string ValueDataToString(const Value &V);
AaronBallman wrote:
Why is `
@@ -416,6 +416,8 @@ Interpreter::Interpreter(std::unique_ptr
Instance,
return;
}
}
+
+ ValuePrintingInfo.resize(4);
AaronBallman wrote:
Can you explain why this is needed?
https://github.com/llvm/llvm-project/pull/148701
@@ -250,17 +254,35 @@ const ASTContext &Value::getASTContext() const {
return getInterpreter().getASTContext();
}
-void Value::dump() const { print(llvm::outs()); }
+void Value::dump() { print(llvm::outs()); }
void Value::printType(llvm::raw_ostream &Out) const {
- Out <
@@ -119,9 +119,9 @@ class REPL_EXTERNAL_VISIBILITY Value {
~Value();
void printType(llvm::raw_ostream &Out) const;
- void printData(llvm::raw_ostream &Out) const;
- void print(llvm::raw_ostream &Out) const;
- void dump() const;
+ void printData(llvm::raw_ostream &Out);
@@ -0,0 +1,10 @@
+// RUN: clang-query -c "match \
+// RUN: functionDecl( \
+// RUN: hasName( \
+// RUN: \"foo\", \
+// RUN: ), \
+// RUN: ) \
+// RUN: " %s -- | FileCheck %s
+
+// CHECK: trailing-comma.c:10:1: note: "root" binds here
Aaro
https://github.com/AaronBallman commented:
Yeah, I think I'm okay with this. It's a bit different from C++, but the
difference seems sufficiently useful and the amount of pain with switching
between the two DSLs seems pretty minimal.
I did have a request for some additional test coverage thoug
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/148018
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman commented:
In general, the functional changes are looking reasonable. It's still missing
all of the sema tests though, as well as a release note.
https://github.com/llvm/llvm-project/pull/141846
___
cfe-commits mailing
@@ -0,0 +1,190 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -fsanitize=kcfi
-o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -fsanitize=kcfi
-x c++ -o - %s | FileCheck %s --check-prefixes=CHECK,MEMBER
+// RUN: %clang_cc
@@ -5259,19 +5276,22 @@ class FunctionProtoType final
/// the various bits of extra information about a function prototype.
struct ExtProtoInfo {
FunctionType::ExtInfo ExtInfo;
+Qualifiers TypeQuals;
+RefQualifierKind RefQualifier = RQ_None;
+ExceptionSpecIn
@@ -4689,6 +4704,7 @@ class FunctionType : public Type {
struct alignas(void *) FunctionTypeArmAttributes {
/// Any AArch64 SME ACLE type attributes that need to be propagated
/// on declarations and function pointers.
+LLVM_PREFERRED_TYPE(uint16_t)
--
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/141846
___
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/144408
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman commented:
In general, I think the changes LG, though I leave it to @Sirraide to give
final sign off since he had previous requests.
https://github.com/llvm/llvm-project/pull/142541
___
cfe-commits mailing list
cfe-comm
@@ -2833,8 +2834,37 @@ CFGBlock *CFGBuilder::VisitCallExpr(CallExpr *C,
AddStmtChoice asc) {
if (!FD->isVariadic())
findConstructionContextsForArguments(C);
-if (FD->isNoReturn() || C->isBuiltinAssumeFalse(*Context))
- NoReturn = true;
+if (!NoReturn)
+
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/148090
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
I think the new plan forward makes sense. But also: thank you to everyone on
this thread for the excellent collaboration on identifying an issue, getting
the previous incarnation reverted, and discussing a good path forward. :-)
https://github.com/llvm/llvm-project/pull/143
AaronBallman wrote:
> Thanks for the suggestions Aaron, applied them both and refreshed the branch
> (it doesn't stay fresh for long it seems 😄)
>
> When it comes to `[[gnu::`, options seems to be
>
> * Leave as-is, no change: no error, no warning but string is dropped
>
> * Align wit
https://github.com/AaronBallman approved this pull request.
LGTM! Thank you for the fix!
https://github.com/llvm/llvm-project/pull/148552
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commit
https://github.com/AaronBallman commented:
Thanks for the PR! I think we need to think about this a little bit; my concern
is that folks often use clang-query to write queries they'll eventually be
using in clang-tidy checks. However, the tidy checks are using the C++ DSL
which won't support t
https://github.com/AaronBallman approved this pull request.
LGTM aside from a nit with the comments (sorry for causing that confusion in
the first place).
https://github.com/llvm/llvm-project/pull/148090
___
cfe-commits mailing list
cfe-commits@lists.
@@ -2902,28 +2902,41 @@ static void handleWarnUnusedResult(Sema &S, Decl *D,
const ParsedAttr &AL) {
}
StringRef Str;
- if (AL.isStandardAttributeSyntax() && !AL.getScopeName()) {
-// The standard attribute cannot be applied to variable declarations such
-// as
@@ -2902,28 +2902,41 @@ static void handleWarnUnusedResult(Sema &S, Decl *D,
const ParsedAttr &AL) {
}
StringRef Str;
- if (AL.isStandardAttributeSyntax() && !AL.getScopeName()) {
-// The standard attribute cannot be applied to variable declarations such
-// as
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/148090
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
> > I suppose another option is to use a regex in the test to accept either
> > form of canonicalization with a comment that lit tests are sometimes run
> > from network mounts and that's why the test is the way it is.
>
> I mean, at that point we can just delete the test e
AaronBallman wrote:
> > Windows doesn't have `/tmp` for example. I don't think we have any
> > [substitutions](https://llvm.org/docs/CommandGuide/lit.html#substitutions)
> > for getting the temp directory.
>
> Ah, I meant non-windows systems (I thought `REQUIRES: shell` already meant
> non-wi
AaronBallman wrote:
> We could try that (assuming that `/tmp` exists on every system but I sure
> hope so); it might run into issues if we somehow pick a file/directory name
> that something else is already using, but that’s probably not too likely.
Windows doesn't have `/tmp` for example. I d
AaronBallman wrote:
> Given the scale of the patch, it's not surprising if it undergoes some
> revert-reapplies cycles after the initial commit.
>
> To reduce the churn, would it be possible to ask google (and other major
> downstream clients) to test it internally before we merge? @AaronBallm
AaronBallman wrote:
I don't think we have a way to support that. I looked through lit to see what
kind of `REQUIRES` support we have and we can target systems and such, but I
don't see any built-in support for non-network mounts.
The only suggestion I have might be terrible, but you could writ
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/147802
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
Another concrete reason for why this should default to an error for `_Atomic`
is https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p0943r6.html
In the C++ version of `stdatomic.h`, there's a `#define _Atomic(x)
std::atomic` which exists for shared header files betwee
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/147802
>From e65fa6bdd251ceef52e11ff8ee856058e8e3c47a Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Wed, 9 Jul 2025 14:40:00 -0400
Subject: [PATCH 1/9] [C23] Accept an _Atomic underlying type
The underlying
@@ -9364,6 +9364,14 @@ def warn_atomic_implicit_seq_cst : Warning<
InGroup>, DefaultIgnore;
def err_atomic_unsupported : Error<
"atomic types are not supported in '%0'">;
+def warn_cv_stripped_in_enum : Warning<
+ "%select{'const' and 'volatile' qualifiers|'const' qualifie
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/147802
>From e65fa6bdd251ceef52e11ff8ee856058e8e3c47a Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Wed, 9 Jul 2025 14:40:00 -0400
Subject: [PATCH 1/8] [C23] Accept an _Atomic underlying type
The underlying
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/147802
>From e65fa6bdd251ceef52e11ff8ee856058e8e3c47a Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Wed, 9 Jul 2025 14:40:00 -0400
Subject: [PATCH 1/7] [C23] Accept an _Atomic underlying type
The underlying
@@ -9364,6 +9364,14 @@ def warn_atomic_implicit_seq_cst : Warning<
InGroup>, DefaultIgnore;
def err_atomic_unsupported : Error<
"atomic types are not supported in '%0'">;
+def warn_cv_stripped_in_enum : Warning<
+ "%select{'const' and 'volatile' qualifiers|'const' qualifie
AaronBallman wrote:
> > > > avior due to the silent stripping. Given that an atomic type is not the
> > > > same as its underlying type (in terms of ABI or semantics) I think we
> > > > should diagnose the behavior with at least a warning. I could even be
> > > > convinced it should be a warni
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/147802
>From e65fa6bdd251ceef52e11ff8ee856058e8e3c47a Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Wed, 9 Jul 2025 14:40:00 -0400
Subject: [PATCH 1/6] [C23] Accept an _Atomic underlying type
The underlying
AaronBallman wrote:
> > avior due to the silent stripping. Given that an atomic type is not the
> > same as its underlying type (in terms of ABI or semantics) I think we
> > should diagnose the behavior with at least a warning. I could even be
> > convinced it should be a warning which default
@@ -17563,6 +17573,16 @@ Sema::ActOnTag(Scope *S, unsigned TagSpec, TagUseKind
TUK, SourceLocation KWLoc,
UPPC_FixedUnderlyingType))
EnumUnderlying = Context.IntTy.getTypePtr();
+ // If the underlying type is atomic, we n
@@ -2022,8 +2022,14 @@ Decl *TemplateDeclInstantiator::VisitEnumDecl(EnumDecl
*D) {
DeclarationName());
if (!NewTI || SemaRef.CheckEnumUnderlyingType(NewTI))
Enum->setIntegerType(SemaRef.Context.IntTy);
- else
@@ -174,10 +174,11 @@ def note_constexpr_heap_alloc_limit_exceeded : Note<
def note_constexpr_this : Note<
"%select{|implicit }0use of 'this' pointer is only allowed within the "
"evaluation of a call to a 'constexpr' member function">;
-def access_kind : TextSubstitution<
https://github.com/AaronBallman approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/147711
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -265,7 +265,7 @@ namespace const_modify {
namespace null {
constexpr int test(int *p) {
-return *p = 123; // expected-note {{assignment to dereferenced null
pointer}}
+return *p = 123; // expected-note {{read of dereferenced null pointer}}
AaronB
@@ -17563,6 +17573,16 @@ Sema::ActOnTag(Scope *S, unsigned TagSpec, TagUseKind
TUK, SourceLocation KWLoc,
UPPC_FixedUnderlyingType))
EnumUnderlying = Context.IntTy.getTypePtr();
+ // If the underlying type is atomic, we n
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/147802
>From e65fa6bdd251ceef52e11ff8ee856058e8e3c47a Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Wed, 9 Jul 2025 14:40:00 -0400
Subject: [PATCH 1/4] [C23] Accept an _Atomic underlying type
The underlying
@@ -59,7 +59,7 @@ constexpr bool test() {
{
// bidi
-int buffer[2] = {1, 2};
+int buffer[3] = {1, 2, 3};
AaronBallman wrote:
I'd think that as well, but the fact that it passed when it should fail means
we should double-check. :-D I don't have
AaronBallman wrote:
> If a function has a deferred diagnostic, it should prevent codegen of that
> function, yes.
Deferred errors only, though, right? Do we know if there are any cases where we
defer the diagnostic because we may later decide it's *not* an error and thus
codegen would be fine
1 - 100 of 3363 matches
Mail list logo
