@@ -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
@@ -59,7 +59,7 @@ constexpr bool test() {
{
// bidi
-int buffer[2] = {1, 2};
+int buffer[3] = {1, 2, 3};
AaronBallman wrote:
Thanks! I kind of figured that was the case, but it wasn't clear whether the
test should change like this or not.
@ld
https://github.com/AaronBallman approved this pull request.
I think this is correct; if it turns out to be an issue for HLSL, we can cross
that bridge when we come to it.
https://github.com/llvm/llvm-project/pull/147306
___
cfe-commits mailing list
cf
AaronBallman wrote:
> I THINK this is right, but we also need to have a codegen test to make sure
> we don't try to do goofiness with these.
I was thinking the ast-dump test sufficed because it shows that we set the
underlying type to non-atomic in the AST. But I can certainly add a codegen
t
@@ -17152,6 +17152,13 @@ bool Sema::CheckEnumUnderlyingType(TypeSourceInfo *TI)
{
SourceLocation UnderlyingLoc = TI->getTypeLoc().getBeginLoc();
QualType T = TI->getType();
+ // C++0x 7.2p2: The type-specifier-seq of an enum-base shall name an
+ // integral type; any cv
@@ -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
@@ -547,6 +547,15 @@ static void DoEmitAvailabilityWarning(Sema &S,
AvailabilityResult K,
return;
}
case AR_Deprecated:
+// Suppress -Wdeprecated-declarations in purely implicit special-member
functions.
+if (auto *MD = dyn_cast_if_present(S.getCurFunctionDecl
https://github.com/AaronBallman requested changes to this pull request.
Actually, the changes still LGTM, but let's hold off on landing the changes
until we give WG21 a chance to weigh in. It's possible we'll end up converging
and not need to have different behaviors.
https://github.com/llvm/l
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/147285
___
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/141133
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
> Hi all! So given the discussion above and that @erichkeane also okayed this,
> can we finally proceed with this PR? I'd like to note that after discussing
> it for the past month and a half, it still seems like we have no idea what
> the ideal solution to the more-general
AaronBallman wrote:
> My understanding is that "recoverable" in this context means we can actually
> generate sensible IR for the construct. So no errors, except for warnings
> promoted to errors (or certain errors which don't impact IRGen/CFG analysis).
> And if that isn't what isUnrecoverabl
AaronBallman wrote:
> LGTM, but it would be great to get someone familiar with MS side of things to
> take a look.
>
> @rnk is there anything else we need to worry about?
@rnk is out on vacation, so I'd say we're good to go.
https://github.com/llvm/llvm-project/pull/146620
___
https://github.com/AaronBallman approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/146620
___
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/147308
___
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/147275
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -4111,7 +4111,10 @@ static ActionResult
getPatternForClassTemplateSpecialization(
if (Ambiguous) {
// Partial ordering did not produce a clear winner. Complain.
Inst.Clear();
- ClassTemplateSpec->setInvalidDecl();
+
+ if (!S.isS
https://github.com/AaronBallman commented:
Awesome! We just need @xlauko to explicitly approve and then we're good to go!
https://github.com/llvm/llvm-project/pull/147365
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cg
https://github.com/AaronBallman approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/147503
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -477,3 +477,10 @@ namespace P2361 {
}
alignas(int) struct AlignAsAttribute {}; // expected-error {{misplaced
attributes; expected attributes here}}
+
+namespace GH147217 {
+ [[clang::annotate(#)]] void a();// expected-error {{'#' is not allowed
in an attribute argume
@@ -678,6 +678,8 @@ Improvements to Clang's diagnostics
- Clang now accepts ``@tparam`` comments on variable template partial
specializations. (#GH144775)
+- Clang now rejects ``#`` operators in attribute argument lists. (#GH147217)
AaronBallman wrote:
```s
@@ -477,3 +477,8 @@ namespace P2361 {
}
alignas(int) struct AlignAsAttribute {}; // expected-error {{misplaced
attributes; expected attributes here}}
+
+namespace GH147217 {
+ [[clang::annotate(#)]] void a(); // expected-error {{'#' is not allowed
in attribute argument
AaronBallman wrote:
> Thansk for the explainer! That gives me something to test, I will try a
> cross-compile with GCC and see if I can reproduce it locally.
>
> > It's not immediately obvious to me why the host compiler would make any
> > difference on this particular PR ...
>
> We are chang
https://github.com/AaronBallman approved this pull request.
LGTM, thank you!
https://github.com/llvm/llvm-project/pull/144619
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
> This patch fixes an issue where Microsoft-specific layout attributes, such as
> __declspec(empty_bases), were ignored during CUDA/HIP device compilation on a
> Windows host. This caused a critical memory layout mismatch between host and
> device objects, breaking librarie
AaronBallman wrote:
> No idea why it blew up on that particular s390x buildbot. @AaronBallman Any
> ideas?
Err, I have no idea, I've never seen that sort of behavior before!
https://github.com/llvm/llvm-project/pull/146844
___
cfe-commits mailing lis
@@ -747,6 +747,10 @@ Bug Fixes in This Version
- Fixed an infinite recursion when checking constexpr destructors. (#GH141789)
- Fixed a crash when a malformed using declaration appears in a ``constexpr``
function. (#GH144264)
- Fixed a bug when use unicode character name in ma
@@ -276,6 +276,10 @@ def err_expected_while : Error<"expected 'while' in
do/while loop">;
def err_expected_semi_after_stmt : Error<"expected ';' after %0 statement">;
def err_expected_semi_after_expr : Error<"expected ';' after expression">;
+def warn_expected_stmt_before_sem
@@ -830,6 +830,8 @@ def err_ms_property_expected_comma_or_rparen : Error<
"expected ',' or ')' at end of property accessor list">;
def err_ms_property_initializer : Error<
"property declaration cannot have a default member initializer">;
+def err_invalid_attribute_argument
@@ -488,6 +488,13 @@ unsigned Parser::ParseAttributeArgsCommon(
bool AttributeHasVariadicIdentifierArg =
attributeHasVariadicIdentifierArg(*AttrName, Form.getSyntax(),
ScopeName);
+ if (Tok.is(tok::hash) || Tok.is(tok::hashhash)) {
AaronBallman wrote
https://github.com/AaronBallman commented:
I think the old code was not handling Microsoft attributes and I think the new
code is also not handling Microsoft attributes, just in a different way.
AIUI, Microsoft attributes are deprecated (https://godbolt.org/z/Ma45KKMvG) and
only used on a decl
https://github.com/AaronBallman approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/143520
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
> In some tentative parses, we would always consider `[` as the start of an
> attribute - only `[[` should be.
>
> Fixes #63880
It is the start of an attribute: Microsoft-style attributes are single bracket
rather than double bracket.
https://github.com/llvm/llvm-project/
@@ -7757,7 +7762,9 @@ void Sema::AddMethodCandidate(
Candidate.Viable = true;
unsigned FirstConvIdx = PO == OverloadCandidateParamOrder::Reversed ? 1 : 0;
- if (ObjectType.isNull())
+ if (IgnoreExplicitObject)
+;
AaronBallman wrote:
How bad is it to
@@ -7876,6 +7883,7 @@ static void AddMethodTemplateCandidateImmediately(
// function template are combined with the set of non-template candidate
// functions.
TemplateDeductionInfo Info(CandidateSet.getLocation());
+ auto Method = cast(MethodTmpl->getTemplatedDecl()
https://github.com/AaronBallman approved this pull request.
The changes look correct to me, but I added Eli and Alexey for some other
opinions to be sure.
https://github.com/llvm/llvm-project/pull/147163
___
cfe-commits mailing list
cfe-commits@lists.
@@ -291,6 +291,14 @@ void DeclInfo::fill() {
TemplateParameters = CTPSD->getTemplateParameters();
break;
}
+ case Decl::VarTemplatePartialSpecialization: {
+const VarTemplatePartialSpecializationDecl *VTPSD =
AaronBallman wrote:
```suggestion
https://github.com/AaronBallman approved this pull request.
LGTM, with a small nit. (Feel free to land once addressed, additional review
not required.)
https://github.com/llvm/llvm-project/pull/147219
___
cfe-commits mailing list
cfe-commits@lists.llv
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/147219
___
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/147284
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
> Can we merge this with private email address?
Community policy is to have public email addresses:
https://llvm.org/docs/DeveloperPolicy.html#email-addresses
https://github.com/llvm/llvm-project/pull/146433
___
cfe-commits mailin
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/147284
>From 926fd7ce1264bd263a9fd46409ec7cc8e2d2db27 Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Mon, 7 Jul 2025 07:47:54 -0400
Subject: [PATCH 1/3] [clang-cl] Support /stdc:latest
cl.exe has /stdc:latest
AaronBallman wrote:
> > You've got the same typo (?) in a bunch of places. You have `/stdc:latest`
> > instead of `/std:clatest`. Same for `/std:c++latest`.
>
> Good catch! Sheesh, fingers. Work!
Those are all addressed. This is what I get for typing `__STDC_*` as often as I
do. :-D
https://
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/147284
___
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/147284
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/147284
>From 926fd7ce1264bd263a9fd46409ec7cc8e2d2db27 Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Mon, 7 Jul 2025 07:47:54 -0400
Subject: [PATCH 1/2] [clang-cl] Support /stdc:latest
cl.exe has /stdc:latest
https://github.com/AaronBallman approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/147286
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
> You've got the same typo (?) in a bunch of places. You have `/stdc:latest`
> instead of `/std:clatest`. Same for `/std:c++latest`.
Good catch! Sheesh, fingers. Work!
https://github.com/llvm/llvm-project/pull/147284
___
cfe-commi
@@ -1450,7 +1450,6 @@ def MicrosoftAnonTag : DiagGroup<"microsoft-anon-tag">;
def MicrosoftCommentPaste : DiagGroup<"microsoft-comment-paste">;
def MicrosoftEndOfFile : DiagGroup<"microsoft-end-of-file">;
def MicrosoftInaccessibleBase : DiagGroup<"microsoft-inaccessible-base">;
@@ -1450,7 +1450,6 @@ def MicrosoftAnonTag : DiagGroup<"microsoft-anon-tag">;
def MicrosoftCommentPaste : DiagGroup<"microsoft-comment-paste">;
def MicrosoftEndOfFile : DiagGroup<"microsoft-end-of-file">;
def MicrosoftInaccessibleBase : DiagGroup<"microsoft-inaccessible-base">;
https://github.com/AaronBallman approved this pull request.
LGTM! My cleverness didn't work out, alas. :-D
https://github.com/llvm/llvm-project/pull/147030
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/l
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/147030
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
1 - 100 of 3312 matches
Mail list logo
