Author: aaronballman
Date: Mon Dec 4 12:46:43 2017
New Revision: 319694
URL: http://llvm.org/viewvc/llvm-project?rev=319694&view=rev
Log:
Switch from C++1z to C++17; corresponds to r319688 in Clang.
Modified:
lldb/trunk/source/Plugins/Language/CPlusPlus/CPlusPlusNameParser.cpp
Modified: lld
On Wed, Oct 5, 2016 at 7:40 PM, Galina Kistanova via cfe-commits
wrote:
> Hello everyone,
>
> Below are some buildbot numbers for the last week of 9/25/2016 - 10/1/2016.
>
> Please see the same data in attached csv files:
Can we please fix the clang-tools-sphinx-docs builder or take it
offline en
On Wed, Nov 18, 2015 at 1:40 PM, Galina Kistanova via cfe-commits
wrote:
> Hello everyone,
>
> Here are some buildbot statistics you may found interesting. I will be
> adding more statistics.
> My goal is to publish metrics to help with keeping the buildbot
> infrastructure healthy and improving i
On Tue, Jul 26, 2016 at 8:14 PM, Galina Kistanova via cfe-commits
wrote:
> Hello everyone,
>
> Below are some buildbot numbers for the week of 7/10/2016 - 7/16/2016.
>
> Please see the same data in attached csv files:
>
> The longest time each builder was red during the week;
> "Status change rati
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
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
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
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:
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
@@ -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
@@ -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,
+
@@ -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,
+
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,
+
@@ -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 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
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 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
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
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
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
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:
> 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'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:
> 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
@@ -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
+/
@@ -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
@@ -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
@@ -460,6 +463,14 @@ class FormatSpecifier {
FieldWidth = Amt;
}
+ void setExplicitlyFixedSize(unsigned s) {
+ExplicitlyFixedSize = s;
AaronBallman wrote:
```suggestion
void setExplicitlyFixedSize(unsigned S) {
ExplicitlyFixedSize = S;
```
h
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
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
___
@@ -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
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
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
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
@@ -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
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
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 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
Author: Aaron Ballman
Date: 2021-12-06T13:30:15-05:00
New Revision: 1f257accd713a8e302d3fdd2cac615a303295c42
URL:
https://github.com/llvm/llvm-project/commit/1f257accd713a8e302d3fdd2cac615a303295c42
DIFF:
https://github.com/llvm/llvm-project/commit/1f257accd713a8e302d3fdd2cac615a303295c42.diff
@@ -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
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
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
@@ -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
@@ -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
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
@@ -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 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/
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
@@ -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
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/
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:
> 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
_
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:
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:
> 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
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
Author: Danny Mösch
Date: 2022-03-23T10:10:20-04:00
New Revision: a749e3295df4aee18a0ad723875a6501f30ac744
URL:
https://github.com/llvm/llvm-project/commit/a749e3295df4aee18a0ad723875a6501f30ac744
DIFF:
https://github.com/llvm/llvm-project/commit/a749e3295df4aee18a0ad723875a6501f30ac744.diff
L
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
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
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.
@@ -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
@@ -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
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
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:
> 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:
> > > 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
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
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 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
@@ -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 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
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
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-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: 2020-11-16T14:23:04-05:00
New Revision: 1941d9651cc90948fa442584eec09bdb0cf01a33
URL:
https://github.com/llvm/llvm-project/commit/1941d9651cc90948fa442584eec09bdb0cf01a33
DIFF:
https://github.com/llvm/llvm-project/commit/1941d9651cc90948fa442584eec09bdb0cf01a33.diff
Author: Aaron Ballman
Date: 2020-11-16T14:39:34-05:00
New Revision: fa72ce346c5f81ef96901fce0b6b23fa4faaa33e
URL:
https://github.com/llvm/llvm-project/commit/fa72ce346c5f81ef96901fce0b6b23fa4faaa33e
DIFF:
https://github.com/llvm/llvm-project/commit/fa72ce346c5f81ef96901fce0b6b23fa4faaa33e.diff
On Tue, Jan 7, 2020 at 2:57 PM John McCall via cfe-commits
wrote:
>
> On Tue, Jan 7, 2020 at 1:44 PM Aaron Ballman via Phabricator
> wrote:
> > aaron.ballman added inline comments.
> >
> >
> >
> > Comment at: cfe/trunk/lib/AST/Mangle.cpp:127
> > +// do not add a "\01" prefix.
On Tue, Jan 7, 2020 at 3:13 PM John McCall wrote:
>
> On Tue, Jan 7, 2020 at 3:02 PM Aaron Ballman wrote:
> > On Tue, Jan 7, 2020 at 2:57 PM John McCall via cfe-commits
> > wrote:
> > > On Tue, Jan 7, 2020 at 1:44 PM Aaron Ballman via Phabricator
> > > wrote:
> > > > Sorry to dredge up an old r
On Tue, Jan 7, 2020 at 3:40 PM John McCall wrote:
>
> On Tue, Jan 7, 2020 at 3:18 PM Aaron Ballman wrote:
> > It seems like GCC doesn't do good things when trying to link two
> > functions with empty asm labels but Clang does seem to do something
> > reasonable. I can't quite tell whether this is
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:
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
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:
> 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:
> @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
@@ -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 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
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
1 - 100 of 111 matches
Mail list logo
