AaronBallman wrote:
Thank you for your patience!
In general, I think adding a new qualifier to Clang needs to come with
significant justification for the implementation and maintenance costs. In this
specific case, those costs are somewhat amortized because we already have the
`__ptrauth` qua
AaronBallman wrote:
> > Perhaps silly initial question: why do we need a whole different qualifier
> > for this? Why can you not write `__ptrauth uintptr_t foo`?
>
> Not a silly question, back when first implemented we spent time thinking
> about this.
>
> The concern was basically `T* __ptra
AaronBallman wrote:
Perhaps silly initial question: why do we need a whole different qualifier for
this? Why can you not write `__ptrauth uintptr_t foo`?
https://github.com/llvm/llvm-project/pull/137580
___
lldb-commits mailing list
lldb-commits@lists
https://github.com/AaronBallman commented:
I think the changes LG, but please wait for our CMake experts (@petrhosek and
@Ericson2314) to review before landing.
https://github.com/llvm/llvm-project/pull/136843
___
lldb-commits mailing list
lldb-commit
@@ -48,14 +48,6 @@ if (LLVM_ENABLE_DOXYGEN)
set(bolt_doxygen_qhp_cust_filter_attrs "")
endif()
- option(LLVM_DOXYGEN_SVG
AaronBallman wrote:
Awesome, thanks!
https://github.com/llvm/llvm-project/pull/136843
@@ -48,14 +48,6 @@ if (LLVM_ENABLE_DOXYGEN)
set(bolt_doxygen_qhp_cust_filter_attrs "")
endif()
- option(LLVM_DOXYGEN_SVG
AaronBallman wrote:
Will removing the option be disruptive (particularly to downstreams)? Do we
need a deprecation period before w
https://github.com/AaronBallman approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/126352
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
AaronBallman wrote:
Thank you for working on cleaning up these APIs! They are definitely a source
of confusion in practice, so paying down this tech debt is great!
> The names for the first two are rather verbose; I’m open to suggestions as to
> better names for these functions since that was
AaronBallman wrote:
> Looks like this change has some compile-time impact even if modules are not
> used:
> https://llvm-compile-time-tracker.com/compare.php?from=edc02351dd11cc4a39b7c541b26b71c6f36c8e55&to=7201cae106260aeb3e97d5291ff30f05076a&stat=instructions:u
> It seems to add about 0.
https://github.com/AaronBallman approved this pull request.
LGTM modulo the request for a helper function (that two reviewers asked for the
same thing is a pretty reasonable indication that we should probably have the
helper, but if you feel strongly about it, I won't block the PR over it).
ht
@@ -14690,6 +14690,13 @@ void Sema::FinalizeDeclaration(Decl *ThisDecl) {
}
}
+ // The result of __builtin_counted_by_ref cannot be assigned to a variable.
+ // It allows leaking and modification of bounds safety information.
+ if (IsBuiltinCountedByRef(VD->getInit())
@@ -14690,6 +14690,13 @@ void Sema::FinalizeDeclaration(Decl *ThisDecl) {
}
}
+ // The result of __builtin_counted_by_ref cannot be assigned to a variable.
+ // It allows leaking and modification of bounds safety information.
+ if (IsBuiltinCountedByRef(VD->getInit())
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/116719
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/AaronBallman commented:
Is there a branch up for this on https://llvm-compile-time-tracker.com/ so that
we've verified that this actually improves performance?
https://github.com/llvm/llvm-project/pull/116719
___
lldb-commits mailin
AaronBallman wrote:
> @AaronBallman you said this has happened before, but I don't see this in
> history. Can you link to the commit to which you're referring?
>
> I only see one other commit
> ([9783f28](https://github.com/llvm/llvm-project/commit/9783f28cbb155e4a8d49c12e1c60ce14dcfaf0c7))
>
https://github.com/AaronBallman approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/114289
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
AaronBallman wrote:
> But if every single Windows developer involved here say that they want LF,
> and they don't want any ambiguity about it? Is it more important to give
> hypothetical users the choice to pick what they like, at the cost of every
> single current developer who do not want th
AaronBallman wrote:
I just had someone in my office hours also running into problems from this
commit. I went to revert the changes myself and I cannot because of merge
conflicts... due to line endings.
@ldrumm -- can you revert these changes ASAP? They're causing significant
problems in prac
AaronBallman wrote:
This seems to have broken precommit CI on Windows:
https://buildkite.com/llvm-project/github-pull-requests/builds/65#0192a01b-d3ac-44ad-abff-e53ac4a206ab
all of the failures look related to line endings, and I noticed that I got a
ton of command line messages of the for
Valentin Clement =?utf-8?b?KOODkOODrOODsw=?=,Renato Golin
Message-ID:
In-Reply-To:
https://github.com/AaronBallman approved this pull request.
LGTM, though we should probably add a release note to
clang/docs/ReleaseNotes.rst so users know that the plugin system got a bit more
functionality.
AaronBallman wrote:
Precommit CI test failures look related:
```
_bk;t=1725284334938 TEST 'LLVM ::
tools/sancov/symbolize.test' FAILED
_bk;t=1725284334938Exit Code: 1
_bk;t=1725284334938
_bk;t=1725284334938Command Output (stderr):
_bk;t=17252
https://github.com/AaronBallman approved this pull request.
Clang bits LGTM
https://github.com/llvm/llvm-project/pull/106505
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/AaronBallman commented:
Thank you for working on this; it's a minor inconsistency, but a needless one
as best I can tell. The changes mostly look good, but there are a bunch of
binary files (.exe) that seem to have changed; do you know why?
https://github.com/llvm/llvm-proje
AaronBallman wrote:
Ping @JDevlieghere for lldb test suite assistance.
As for ORC JIT, [the compiler-rt project](https://compiler-rt.llvm.org/) does
not claim to support Windows to begin with, so it's unclear whether the bot
should not be testing on Windows or whether compiler-rt needs to upda
AaronBallman wrote:
> @AaronBallman could you please review?
>
> I've fixed at least the LLDB tests. There was an actual bug in function
> parameters construction that was revealed by the invariant check.
>
> However, I can't run the whole LLDB suite. Even among the reported failing
> tests,
AaronBallman wrote:
I reverted these changes in 71ff749d6b9aee70c6d26d9781b9f70bf6a8c445 so
@temyurchenko can investigate the issues.
https://github.com/llvm/llvm-project/pull/93913
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lis
Author: Aaron Ballman
Date: 2024-07-01T14:19:37-04:00
New Revision: 71ff749d6b9aee70c6d26d9781b9f70bf6a8c445
URL:
https://github.com/llvm/llvm-project/commit/71ff749d6b9aee70c6d26d9781b9f70bf6a8c445
DIFF:
https://github.com/llvm/llvm-project/commit/71ff749d6b9aee70c6d26d9781b9f70bf6a8c445.diff
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/93913
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
AaronBallman wrote:
Do you need someone to land these changes on your behalf?
https://github.com/llvm/llvm-project/pull/93913
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/93913
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -576,13 +576,18 @@ template static bool
isFirstInExternCContext(T *D) {
return First->isInExternCContext();
}
-static bool isSingleLineLanguageLinkage(const Decl &D) {
- if (const auto *SD = dyn_cast(D.getDeclContext()))
-if (!SD->hasBraces())
- return true;
+
https://github.com/AaronBallman approved this pull request.
LGTM with another small improvement that could be made.
https://github.com/llvm/llvm-project/pull/93913
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin
@@ -2380,7 +2380,7 @@ FunctionDecl *Sema::CreateBuiltin(IdentifierInfo *II,
QualType Type,
}
FunctionDecl *New = FunctionDecl::Create(Context, Parent, Loc, Loc, II, Type,
- /*TInfo=*/nullptr, SC_Extern,
+
@@ -2380,7 +2380,7 @@ FunctionDecl *Sema::CreateBuiltin(IdentifierInfo *II,
QualType Type,
}
FunctionDecl *New = FunctionDecl::Create(Context, Parent, Loc, Loc, II, Type,
- /*TInfo=*/nullptr, SC_Extern,
+
@@ -2380,7 +2380,7 @@ FunctionDecl *Sema::CreateBuiltin(IdentifierInfo *II,
QualType Type,
}
FunctionDecl *New = FunctionDecl::Create(Context, Parent, Loc, Loc, II, Type,
- /*TInfo=*/nullptr, SC_Extern,
+
@@ -6286,7 +6286,7 @@ static FunctionDecl *rewriteBuiltinFunctionDecl(Sema
*Sema, ASTContext &Context,
FunctionDecl *OverloadDecl = FunctionDecl::Create(
Context, Parent, FDecl->getLocation(), FDecl->getLocation(),
FDecl->getIdentifier(), OverloadTy,
- /*TIn
@@ -2380,7 +2380,7 @@ FunctionDecl *Sema::CreateBuiltin(IdentifierInfo *II,
QualType Type,
}
FunctionDecl *New = FunctionDecl::Create(Context, Parent, Loc, Loc, II, Type,
- /*TInfo=*/nullptr, SC_Extern,
+
@@ -576,13 +576,19 @@ template static bool
isFirstInExternCContext(T *D) {
return First->isInExternCContext();
}
-static bool isSingleLineLanguageLinkage(const Decl &D) {
- if (const auto *SD = dyn_cast(D.getDeclContext()))
+static bool isUnbracedLanguageLinkage(const Dec
https://github.com/AaronBallman commented:
I don't want this to be considered a comment which blocks the changes if others
feel strongly in favor of them, but I'm not really convinced we should do this.
The number of problems this patch will solve is approximately zero but the
number of potent
https://github.com/AaronBallman commented:
The changes seem reasonable to me, but there are test failures in
`llvm/utils/lit/tests` that could perhaps be related to your changes.
I think .natvis files should be CRLF (those are used with Visual Studio for
debug visualizers).
https://github.com
https://github.com/AaronBallman approved this pull request.
LGTM, thank you!
https://github.com/llvm/llvm-project/pull/80724
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
AaronBallman wrote:
> Given the problem in [#77753
> (comment)](https://github.com/llvm/llvm-project/pull/77753#issuecomment-1912258038)
> , @cor3ntin , @AaronBallman WDYT about adding new flags to `CXXRecordDecl`,
> saying that constructor/destructor is not really `constexpr` before C++23?
W
AaronBallman wrote:
CC @zyn0217 as the original author of that test case and @HighCommander4 as the
original reviewer.
https://github.com/llvm/llvm-project/pull/68485
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi
AaronBallman wrote:
Hmmm that does look related. I'll revert so we get back to green. CC
@sam-mccall in case he has opinions on how we can ease tension between making
fixes in Clang that impact clangd tests (clangd is a consumer of Clang and we
usually expect consumers to react when their test
AaronBallman wrote:
> Yeah, I'd be happy if anyone with write access could help. I'll create a
> backport issue after the commit.
I've landed the changes, thank you for the fix and the offer to help backport!
https://github.com/llvm/llvm-project/pull/68485
_
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/68485
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
AaronBallman wrote:
LGTM now, thank you for bearing with me! Do you need one of us to commit this
on your behalf?
https://github.com/llvm/llvm-project/pull/68485
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/
@@ -5865,10 +5867,24 @@ RValue CodeGenFunction::EmitCall(QualType CalleeType,
const CGCallee &OrigCallee
break;
}
}
+
+if (const auto *MD =
+dyn_cast_if_present(OCE->getCalleeDecl());
+MD && MD->isStatic())
+ StaticOperator = true
@@ -5865,10 +5867,24 @@ RValue CodeGenFunction::EmitCall(QualType CalleeType,
const CGCallee &OrigCallee
break;
}
}
+
+if (const auto *MD =
+dyn_cast_if_present(OCE->getCalleeDecl());
+MD && MD->isStatic())
+ StaticOperator = true
https://github.com/AaronBallman approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/78330
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/AaronBallman approved this pull request.
LGTM! Thank you for all the hard work on this!
https://github.com/llvm/llvm-project/pull/78041
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/
@@ -6472,7 +6494,20 @@ void CXXNameMangler::mangleValueInTemplateArg(QualType
T, const APValue &V,
Out << "plcvPcad";
Kind = Offset;
} else {
- if (!V.getLValuePath().empty() || V.isLValueOnePastTheEnd()) {
+ // Clang 11 and before mangled an array su
@@ -5401,6 +5409,8 @@ std::string CGDebugInfo::GetName(const Decl *D, bool
Qualified) const {
// feasible some day.
return TA.getAsIntegral().getBitWidth() <= 64 &&
IsReconstitutableType(TA.getIntegralType());
+ case Template
@@ -6472,7 +6494,20 @@ void CXXNameMangler::mangleValueInTemplateArg(QualType
T, const APValue &V,
Out << "plcvPcad";
Kind = Offset;
} else {
- if (!V.getLValuePath().empty() || V.isLValueOnePastTheEnd()) {
+ // Clang 11 and before mangled an array su
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/78041
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -4833,9 +4833,26 @@ void CXXNameMangler::mangleExpression(const Expr *E,
unsigned Arity,
E = cast(E)->getSubExpr();
goto recurse;
- case Expr::SubstNonTypeTemplateParmExprClass:
+ case Expr::SubstNonTypeTemplateParmExprClass: {
+// Mangle a substituted parame
https://github.com/AaronBallman commented:
Ping @rjmccall for Itanium mangling expertise to make sure we're matching the
spec.
There are a few merge conflicts that also cropped up which need to be resolved,
but overall I think this is pretty close to ready to try to re-land. It would
be nice
@@ -2712,9 +2712,22 @@ static void EmitComplexRangeDiag(const Driver &D,
<< EnumComplexRangeToStr(Range1) << EnumComplexRangeToStr(Range2);
}
-static std::string RenderComplexRangeOption(std::string Range) {
+static std::string
+RenderComplexRangeOption(LangOptions::Co
https://github.com/AaronBallman commented:
I think the current changes are reasonable to land for Clang 18 so we get the
fix out to users. I don't have strong opinions on pushing this down into LLVM
or outlining the function like John suggested; either approach is fine by me. I
think outlining
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/78330
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -0,0 +1,119 @@
+// -*- C++ -*-
+//===--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License
@@ -0,0 +1,119 @@
+// -*- C++ -*-
+//===--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License
@@ -0,0 +1,119 @@
+// -*- C++ -*-
+//===--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License
AaronBallman wrote:
> If we land this as-is, it'll tank build time on Windows.
I would like some measurements so we can compare build times on Windows.
https://github.com/llvm/llvm-project/pull/75711
___
lldb-commits mailing list
lldb-commits@lists.ll
@@ -898,8 +895,9 @@ void Sema::DiagnoseTemplateParameterShadow(SourceLocation
Loc, Decl *PrevDecl) {
// Make this a warning when MSVC compatibility is requested.
unsigned DiagId = getLangOpts().MSVCCompat ? diag::ext_template_param_shadow
https://github.com/AaronBallman approved this pull request.
I like the behavior of this and the changes LGTM, but please give @ErichKeane a
chance to weigh in as templates code owner before landing.
https://github.com/llvm/llvm-project/pull/71264
___
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/71264
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -460,6 +463,14 @@ class FormatSpecifier {
FieldWidth = Amt;
}
+ void setExplicitlyFixedSize(unsigned s) {
+ExplicitlyFixedSize = s;
AaronBallman wrote:
```suggestion
void setExplicitlyFixedSize(unsigned S) {
ExplicitlyFixedSize = S;
```
h
@@ -286,7 +286,33 @@
clang::analyze_format_string::ParseLengthModifier(FormatSpecifier &FS,
lmKind = LengthModifier::AsInt3264;
break;
case 'w':
- lmKind = LengthModifier::AsWide; ++I; break;
+ ++I;
+ if (I == E) return false;
+ if (*I == 'f
@@ -537,8 +557,12 @@ ArgType PrintfSpecifier::getScalarArgType(ASTContext &Ctx,
ArgType(Ctx.getPointerDiffType(), "ptrdiff_t"));
case LengthModifier::AsAllocate:
case LengthModifier::AsMAllocate:
- case LengthModifier::AsWide:
return ArgTyp
@@ -286,7 +286,33 @@
clang::analyze_format_string::ParseLengthModifier(FormatSpecifier &FS,
lmKind = LengthModifier::AsInt3264;
break;
case 'w':
- lmKind = LengthModifier::AsWide; ++I; break;
+ ++I;
+ if (I == E) return false;
+ if (*I == 'f
@@ -286,7 +286,33 @@
clang::analyze_format_string::ParseLengthModifier(FormatSpecifier &FS,
lmKind = LengthModifier::AsInt3264;
break;
case 'w':
- lmKind = LengthModifier::AsWide; ++I; break;
+ ++I;
+ if (I == E) return false;
+ if (*I == 'f
@@ -286,7 +286,33 @@
clang::analyze_format_string::ParseLengthModifier(FormatSpecifier &FS,
lmKind = LengthModifier::AsInt3264;
break;
case 'w':
- lmKind = LengthModifier::AsWide; ++I; break;
+ ++I;
+ if (I == E) return false;
+ if (*I == 'f
@@ -1464,6 +1467,21 @@ class AnnotatingParser {
}
}
+ void parseEmbedDirective() {
+if (CurrentToken && CurrentToken->is(tok::less)) {
+ next();
+ while (CurrentToken) {
+// Mark tokens up to the trailing line comments as implicit string
+/
AaronBallman wrote:
> I guess I'd consider the "mental model" here to be that (notionally) `#embed`
> is preprocessed by expanding to `#embed_base64`, which is handled by the
> compiler proper, not the preprocessor. Yes, that's not entirely true in the
> implementation, but it seems like a rea
AaronBallman wrote:
> I'm somewhat concerned about the default for `-E` being to explode `#embed`
> into the comma-separated raw integers. Even with moderately-sized embeds, I
> think it'll generate unusably-bloated output. The human-readability of a big
> list of integers is not better than e
AaronBallman wrote:
> Your reasoning works until we have a crash that relies on `#embed` and/or its
> contents.
Agreed, that's the "downsides" I mentioned.
> From what I saw triaging old crashes, crash submitters are conscious if they
> work with proprietary code they can't share even a fragm
AaronBallman wrote:
> I'd also like to highlight the use case of diagnostic for compiler crashes.
> IIRC preprocessed source to attach to an issue is produced with
> `-frewrite-includes`, so we might want to change its behavior for `#embed`.
> This might be a good use case for `#embed_base64`.
AaronBallman wrote:
> @AaronBallman Can you describe your current plan how driver options are going
> to behave in the light of `#embed`?
I'm flexible with how we proceed, so if others have different ideas, feel free
to suggest them! But my initial inclination is:
* `--embed-dir=` as a way to
https://github.com/AaronBallman converted_to_draft
https://github.com/llvm/llvm-project/pull/68620
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/70349
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -569,4 +569,12 @@ void AnnotateIgnoreWritesEnd(const char *file, int line);
#define LLVM_NO_PROFILE_INSTRUMENT_FUNCTION
#endif
+/// \macro LLVM_PREFERRED_TYPE
+/// Adjust type of bit-field in debug info.
+#if __has_attribute(preferred_type)
AaronBallman wro
https://github.com/AaronBallman approved this pull request.
LGTM aside from a nit with the new macro (feel free to fix when landing).
https://github.com/llvm/llvm-project/pull/70349
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://list
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/70341
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/70341
>From f068b471efa81d60d1d6e2c98da56be58958a015 Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Thu, 26 Oct 2023 10:53:06 -0400
Subject: [PATCH 1/2] Diagnose use of VLAs in a coroutine
Fixes https://githu
AaronBallman wrote:
> > > Is there a way to have Visual Studio change the display format of the
> > > enum values?
> >
> >
> > Sort of. You can specify you want to view values in hex and then you'll get
> > `EK_ParenAggInitMember (0x0015)` instead of `EK_ParenAggInitMember
> > (21)`, but
AaronBallman wrote:
> Is there a way to have Visual Studio change the display format of the enum
> values?
Sort of. You can specify you want to view values in hex and then you'll get
`EK_ParenAggInitMember (0x0015)` instead of `EK_ParenAggInitMember (21)`,
but that all the more formatting
AaronBallman wrote:
> What IDE are you using for the screenshot above?
Visual Studio
> The issue you might run into is that IDE might only be showing the value
> string and not the summary string. XCode and Visual Studio code will show the
> value if there is one _and_ the summary if there i
AaronBallman wrote:
Making sure I'm following along properly. For context, this is the debug
experience I'm most used to:
It sounds like you're saying we shouldn't change the enum formatter to d
@@ -1,4 +1,5 @@
// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
UTC_ARGS: --version 3
+// RUN: %clang_cc1 -triple=x86_64 -verify -ffreestanding -std=c2x %s
AaronBallman wrote:
This triple is the same as the one below (c2x and c23 a
@@ -23,6 +23,7 @@
#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 202311L
#define __STDC_VERSION_STDCKDINT_H__ 202311L
+#endif
AaronBallman wrote:
GCC exposes this value in all C and C++ language modes, so we should go ahead
and remove the `#if` entirel
AaronBallman wrote:
I'm not qualified to provide much of a review, but I'm in support of the
change, thank you for the patch!
https://github.com/llvm/llvm-project/pull/69815
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.
AaronBallman wrote:
> I am not sure how to keep only the `llvm-project//Filename` path except
> by hard-coding. Or how about only keeping the base file name? This could
> limit it to within 80 characters.
I'd recommend using this API:
https://github.com/llvm/llvm-project/blob/2f23666ae7e4
@@ -59,4 +60,8 @@ void llvm::emitSourceFileHeader(StringRef Desc, raw_ostream
&OS) {
printLine(OS, Prefix, ' ', Suffix);
printLine(OS, "\\*===", '-', "===*/");
OS << '\n';
+
+ // Print the path of source file
+ if (!Record.getInputFilename().empty())
+OS << "// Gen
https://github.com/AaronBallman approved this pull request.
LGTM (fine to land without tests as it only adds comments to generated header
files)
https://github.com/llvm/llvm-project/pull/65744
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
AaronBallman wrote:
> > @tru I'd ask @AaronBallman. My vote would be to reformat.
>
> Not as a requirement for this patch, I imagine?
If we wanted to reformat the file as an NFC commit (before or after this
patch), that would be fine. But let's please not reformat as part of this patch
(that
Author: Aaron Ballman
Date: 2022-10-14T08:37:08-04:00
New Revision: 7349bc34836b73518ca3e9366019ef20094f2525
URL:
https://github.com/llvm/llvm-project/commit/7349bc34836b73518ca3e9366019ef20094f2525
DIFF:
https://github.com/llvm/llvm-project/commit/7349bc34836b73518ca3e9366019ef20094f2525.diff
Author: Aaron Ballman
Date: 2022-09-28T13:39:48-04:00
New Revision: c5983963de7a6fb4dce0c7232905cc66c7b52030
URL:
https://github.com/llvm/llvm-project/commit/c5983963de7a6fb4dce0c7232905cc66c7b52030
DIFF:
https://github.com/llvm/llvm-project/commit/c5983963de7a6fb4dce0c7232905cc66c7b52030.diff
Author: Aaron Ballman
Date: 2022-05-04T09:07:57-04:00
New Revision: 2df9bd30e4a0669297529fce79ffa5655de99395
URL:
https://github.com/llvm/llvm-project/commit/2df9bd30e4a0669297529fce79ffa5655de99395
DIFF:
https://github.com/llvm/llvm-project/commit/2df9bd30e4a0669297529fce79ffa5655de99395.diff
Author: Aaron Ballman
Date: 2022-05-04T08:42:52-04:00
New Revision: 6234313c6d28158645395ae325840ae3c31e6539
URL:
https://github.com/llvm/llvm-project/commit/6234313c6d28158645395ae325840ae3c31e6539
DIFF:
https://github.com/llvm/llvm-project/commit/6234313c6d28158645395ae325840ae3c31e6539.diff
1 - 100 of 111 matches
Mail list logo
