[Lldb-commits] [clang] [compiler-rt] [libcxx] [lldb] [llvm] Rename Sanitizer Coverage => Coverage Sanitizer (PR #106505)
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=1725284334938--
_bk;t=1725284334938RUN: at line 2:
/var/lib/buildkite-agent/builds/linux-56-59b8f5d88-c4bpt-1/llvm-project/github-pull-requests/build/bin/sancov
-symbolize -strip_path_prefix="llvm/"
/var/lib/buildkite-agent/builds/linux-56-59b8f5d88-c4bpt-1/llvm-project/github-pull-requests/llvm/test/tools/sancov/Inputs/test-linux_x86_64
/var/lib/buildkite-agent/builds/linux-56-59b8f5d88-c4bpt-1/llvm-project/github-pull-requests/llvm/test/tools/sancov/Inputs/test-linux_x86_64.0.sancov
|
/var/lib/buildkite-agent/builds/linux-56-59b8f5d88-c4bpt-1/llvm-project/github-pull-requests/build/bin/FileCheck
/var/lib/buildkite-agent/builds/linux-56-59b8f5d88-c4bpt-1/llvm-project/github-pull-requests/llvm/test/tools/sancov/symbolize.test
--check-prefixes=CHECK,STRIP
_bk;t=1725284334938+
/var/lib/buildkite-agent/builds/linux-56-59b8f5d88-c4bpt-1/llvm-project/github-pull-requests/build/bin/sancov
-symbolize -strip_path_prefix=llvm/
/var/lib/buildkite-agent/builds/linux-56-59b8f5d88-c4bpt-1/llvm-project/github-pull-requests/llvm/test/tools/sancov/Inputs/test-linux_x86_64
/var/lib/buildkite-agent/builds/linux-56-59b8f5d88-c4bpt-1/llvm-project/github-pull-requests/llvm/test/tools/sancov/Inputs/test-linux_x86_64.0.sancov
_bk;t=1725284334938+
/var/lib/buildkite-agent/builds/linux-56-59b8f5d88-c4bpt-1/llvm-project/github-pull-requests/build/bin/FileCheck
/var/lib/buildkite-agent/builds/linux-56-59b8f5d88-c4bpt-1/llvm-project/github-pull-requests/llvm/test/tools/sancov/symbolize.test
--check-prefixes=CHECK,STRIP
_bk;t=1725284334938/var/lib/buildkite-agent/builds/linux-56-59b8f5d88-c4bpt-1/llvm-project/github-pull-requests/llvm/test/tools/sancov/symbolize.test:13:13:
error: CHECK-NEXT: expected string not found in input
_bk;t=1725284334938CHECK-NEXT: "binary-hash":
"BB3CDD5045AED83906F6ADCC1C4DAF7E2596A6B5",
_bk;t=1725284334938^
_bk;t=1725284334938:8:4: note: scanning from here
_bk;t=1725284334938 ],
_bk;t=1725284334938 ^
_bk;t=1725284334938:9:2: note: possible intended match here
_bk;t=1725284334938 "binary-hash": "A13A863C18DD4DA9E926DB113A369DA45AE33134",
_bk;t=1725284334938 ^
_bk;t=1725284334938
_bk;t=1725284334938Input file:
_bk;t=1725284334938Check file:
/var/lib/buildkite-agent/builds/linux-56-59b8f5d88-c4bpt-1/llvm-project/github-pull-requests/llvm/test/tools/sancov/symbolize.test
_bk;t=1725284334938
_bk;t=1725284334938-dump-input=help explains the following input dump.
_bk;t=1725284334938
_bk;t=1725284334938Input was:
_bk;t=1725284334938<<
_bk;t=1725284334938 1: {
_bk;t=1725284334938 2: "covered-points": [
_bk;t=1725284334938 3: "4e132b",
_bk;t=1725284334938 4: "4e1472",
_bk;t=1725284334938 5: "4e1520",
_bk;t=1725284334938 6: "4e1553",
_bk;t=1725284334938 7: "4e1586"
_bk;t=1725284334938 8: ],
_bk;t=1725284334938next:13'0X error: no match found
_bk;t=1725284334938 9: "binary-hash":
"A13A863C18DD4DA9E926DB113A369DA45AE33134",
_bk;t=1725284334938next:13'0
_bk;t=1725284334938next:13'1 ?
possible intended match
_bk;t=1725284334938 10: "point-symbol-info": {
_bk;t=1725284334938next:13'0
_bk;t=1725284334938 11: "test/tools/sancov/Inputs/test.cpp": {
_bk;t=1725284334938next:13'0
_bk;t=1725284334938 12: "bar(std::string)": {
_bk;t=1725284334938next:13'0 ~~~
_bk;t=1725284334938 13: "4e132b": "12:0"
_bk;t=1725284334938next:13'0 ~~
_bk;t=1725284334938 14: },
_bk;t=1725284334938next:13'0
_bk;t=1725284334938 .
_bk;t=1725284334938 .
_bk;t=1725284334938 .
_bk;t=1725284334938>>
_bk;t=1725284334938
_bk;t=1725284334938--
_bk;t=1725284334938
_bk;t=1725284334938
_bk;t=1725284334939FAIL: LLVM ::
tools/sancov/symbolize_noskip_dead_files.test (86063 of 96817)
_bk;t=1725284334939 TEST 'LLVM ::
tools/sancov/symbolize_noskip_dead_files.test' FAILED
_bk;t=1725284334939Exit Code: 1
_bk;t=1725284334939
_bk;t=1725284334939Command Output (stderr):
_bk;t=1725284334939--
_bk;t=1725284334939RUN: at line 2:
/var/lib/buildkite-agent/builds/linux-56-59b8f5d88-c4bpt-1/llvm-project/github-pull-requests/build/bin/sancov
-symbolize -skip-dead-fil
[Lldb-commits] [clang] [compiler-rt] [libcxx] [lldb] [llvm] Rename Sanitizer Coverage => Coverage Sanitizer (PR #106505)
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
[Lldb-commits] [clang] [compiler-rt] [libcxx] [lldb] [llvm] Rename Sanitizer Coverage => Coverage Sanitizer (PR #106505)
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-project/pull/106505 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [lldb] [clang][AST] fix ast-print of extern with >=2 declarators, fixed, fixed (PR #98795)
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 update their support claims. CC @vitalybuka for more opinions/help on this one (my preference is for Windows to be a first-class citizen with compiler-rt, but if nobody is willing to do the maintenance work, we should not let bots failing when testing compiler-rt on Windows be a blocking concern). https://github.com/llvm/llvm-project/pull/98795 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [lldb] [clang][AST] fix ast-print of extern with >=2 declarators, fixed, fixed (PR #98795)
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, some are «unsupported» on my machine. Even without my changes, a lot > of LLDB tests are unsupported or failing, I guess some were killed by > oom-killer. On the first attempt, @gulfemsavrun suggested to run the LLDB > test suite on this PR. I would be glad, if that offer is still on. CC @JDevlieghere > Regarding the orc-rt test failures: I tried building one of the failing > objects and I can't reproduce the failure. Perhaps, because the tests are run > on Windows and I'm running on Linux? It would be very helpful if @Prabhuk > could run the failing command on a debug build. CC @lhames https://github.com/llvm/llvm-project/pull/98795 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [lldb] [clang][AST] fix ast-print of extern with >=2 declarators, fixed (PR #93913)
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://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 71ff749 - Revert "[clang][AST] fix ast-print of extern with >=2 declarators"
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
LOG: Revert "[clang][AST] fix ast-print of extern with >=2 declarators"
This reverts commit 48f13d48a88c14acbaea7c3ee05018bb173fb360.
It broke some external bots:
https://green.lab.llvm.org/job/llvm.org/view/LLDB/job/as-lldb-cmake/6805/console
https://logs.chromium.org/logs/fuchsia/buildbucket/cr-buildbucket/8743609724828014497/+/u/clang/build/stdout
Added:
Modified:
clang/lib/AST/Decl.cpp
clang/lib/AST/DeclPrinter.cpp
clang/lib/Sema/SemaDecl.cpp
clang/lib/Sema/SemaExpr.cpp
lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
lldb/source/Plugins/ExpressionParser/Clang/NameSearchContext.cpp
Removed:
clang/test/AST/ast-print-language-linkage.cpp
diff --git a/clang/lib/AST/Decl.cpp b/clang/lib/AST/Decl.cpp
index ff3325543919f..16ed6d88d1cb1 100644
--- a/clang/lib/AST/Decl.cpp
+++ b/clang/lib/AST/Decl.cpp
@@ -576,16 +576,13 @@ template static bool
isFirstInExternCContext(T *D) {
return First->isInExternCContext();
}
-static bool isUnbracedLanguageLinkage(const DeclContext *DC) {
- if (const auto *SD = dyn_cast_if_present(DC))
-return !SD->hasBraces();
+static bool isSingleLineLanguageLinkage(const Decl &D) {
+ if (const auto *SD = dyn_cast(D.getDeclContext()))
+if (!SD->hasBraces())
+ return true;
return false;
}
-static bool hasUnbracedLanguageLinkage(const Decl &D) {
- return isUnbracedLanguageLinkage(D.getDeclContext());
-}
-
static bool isDeclaredInModuleInterfaceOrPartition(const NamedDecl *D) {
if (auto *M = D->getOwningModule())
return M->isInterfaceOrPartition();
@@ -647,7 +644,7 @@ LinkageComputer::getLVForNamespaceScopeDecl(const NamedDecl
*D,
if (Var->getStorageClass() != SC_Extern &&
Var->getStorageClass() != SC_PrivateExtern &&
- !hasUnbracedLanguageLinkage(*Var))
+ !isSingleLineLanguageLinkage(*Var))
return LinkageInfo::internal();
}
@@ -2121,12 +2118,6 @@ VarDecl::VarDecl(Kind DK, ASTContext &C, DeclContext *DC,
"ParmVarDeclBitfields too large!");
static_assert(sizeof(NonParmVarDeclBitfields) <= sizeof(unsigned),
"NonParmVarDeclBitfields too large!");
-
- // The unbraced `extern "C"` invariant is that the storage class
- // specifier is omitted in the source code, i.e. SC_None (but is,
- // implicitly, `extern`).
- assert(!isUnbracedLanguageLinkage(DC) || SC == SC_None);
-
AllBits = 0;
VarDeclBits.SClass = SC;
// Everything else is implicitly initialized to false.
@@ -2310,7 +2301,7 @@ VarDecl::isThisDeclarationADefinition(ASTContext &C)
const {
// A declaration directly contained in a linkage-specification is treated
// as if it contains the extern specifier for the purpose of determining
// the linkage of the declared name and whether it is a definition.
- if (hasUnbracedLanguageLinkage(*this))
+ if (isSingleLineLanguageLinkage(*this))
return DeclarationOnly;
// C99 6.9.2p2:
@@ -3036,12 +3027,6 @@ FunctionDecl::FunctionDecl(Kind DK, ASTContext &C,
DeclContext *DC,
DeclContext(DK), redeclarable_base(C), Body(), ODRHash(0),
EndRangeLoc(NameInfo.getEndLoc()), DNLoc(NameInfo.getInfo()) {
assert(T.isNull() || T->isFunctionType());
-
- // The unbraced `extern "C"` invariant is that the storage class
- // specifier is omitted in the source code, i.e. SC_None (but is,
- // implicitly, `extern`).
- assert(!isUnbracedLanguageLinkage(DC) || S == SC_None);
-
FunctionDeclBits.SClass = S;
FunctionDeclBits.IsInline = isInlineSpecified;
FunctionDeclBits.IsInlineSpecified = isInlineSpecified;
diff --git a/clang/lib/AST/DeclPrinter.cpp b/clang/lib/AST/DeclPrinter.cpp
index b8e0ef1b40358..26773a69ab9ac 100644
--- a/clang/lib/AST/DeclPrinter.cpp
+++ b/clang/lib/AST/DeclPrinter.cpp
@@ -633,7 +633,7 @@ static void printExplicitSpecifier(ExplicitSpecifier ES,
llvm::raw_ostream &Out,
Out << Proto;
}
-static void maybePrintTagKeywordIfSupressingScopes(PrintingPolicy &Policy,
+static void MaybePrintTagKeywordIfSupressingScopes(PrintingPolicy &Policy,
QualType T,
llvm::raw_ostream &Out) {
StringRef prefix = T->isClassType() ? "class "
@@ -643,22 +643,6 @@ static void
maybePrintTagKeywordIfSupressingScopes(PrintingPolicy &Policy,
Out << prefix;
}
-/// Return the language of the linkage spec of `D`, if applicable.
-///
-/// \Return - "C" if `D` has been declared with unbraced `extern "C"`
-/// - "C++" if `D` has been declared with unbraced `extern "C++"`
[Lldb-commits] [clang] [lldb] [clang][AST] fix ast-print of extern with >=2 declarators, fixed (PR #93913)
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
[Lldb-commits] [clang] [lldb] [clang][AST] fix ast-print of extern with >=2 declarators, fixed (PR #93913)
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
[Lldb-commits] [clang] [lldb] [clang][AST] fix ast-print of extern with >=2 declarators, fixed (PR #93913)
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
[Lldb-commits] [clang] [lldb] [clang][AST] fix ast-print of extern with >=2 declarators, fixed (PR #93913)
@@ -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;
+static bool isUnbracedLanguageLinkage(const DeclContext *DC) {
+ if (!DC)
+return false;
+ if (const auto *SD = dyn_cast(DC))
+return !SD->hasBraces();
return false;
}
AaronBallman wrote:
```suggestion
if (const auto *SD = dyn_cast_if_present(DC))
return !SD->hasBraces();
return false;
}
```
Sorry for not noticing this earlier, but we can simplify even further this way.
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
[Lldb-commits] [clang] [lldb] [clang][AST] fix ast-print of extern with >=2 declarators, fixed (PR #93913)
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/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [lldb] [clang][AST] fix ast-print of extern with >=2 declarators, fixed (PR #93913)
@@ -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, + /*TInfo=*/nullptr, SC_None, AaronBallman wrote: I think I've come around to being okay with these changes, thank you! 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
[Lldb-commits] [clang] [lldb] [clang][AST] fix ast-print of extern with >=2 declarators, fixed (PR #93913)
@@ -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, + /*TInfo=*/nullptr, SC_None, AaronBallman wrote: Ah, you're right, it's only *objects* declared at local scope that have no linkage (the following paragraph), not *functions*. 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
[Lldb-commits] [clang] [lldb] [clang][AST] fix ast-print of extern with >=2 declarators, fixed (PR #93913)
@@ -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, + /*TInfo=*/nullptr, SC_None, AaronBallman wrote: > You are right, I also paid attention to that issue. However, when a storage > class specifier is omitted for a function, it's storage class is implicitly > supposed to be extern. Thus, it's fine. That's not actually correct -- the declaration of a function at block scope should definitely *not* be extern, it should have no linkage: https://godbolt.org/z/81fMaPaTq > Furthermore, the meaning of this field according to the documentation > comments is not for the actual storage duration or linkage, but for the > storage-class specifier as present in the source code. Since builtins aren't > really present in the source code, it seems further reasonable to omit a > specifier. Builtins should behave as-if they were declared in a header file that was included in the TU, and so they typically would be marked as `extern`. 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
[Lldb-commits] [clang] [lldb] [clang][AST] fix ast-print of extern with >=2 declarators, fixed (PR #93913)
@@ -6286,7 +6286,7 @@ static FunctionDecl *rewriteBuiltinFunctionDecl(Sema *Sema, ASTContext &Context, FunctionDecl *OverloadDecl = FunctionDecl::Create( Context, Parent, FDecl->getLocation(), FDecl->getLocation(), FDecl->getIdentifier(), OverloadTy, - /*TInfo=*/nullptr, SC_Extern, Sema->getCurFPFeatures().isFPConstrained(), + /*TInfo=*/nullptr, SC_None, Sema->getCurFPFeatures().isFPConstrained(), AaronBallman wrote: Same concern here as above. 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
[Lldb-commits] [clang] [lldb] [clang][AST] fix ast-print of extern with >=2 declarators, fixed (PR #93913)
@@ -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, + /*TInfo=*/nullptr, SC_None, AaronBallman wrote: This change looks suspicious to me -- this is creating a builtin function, which should be modeled as an extern. In C++, you seem to be relying on the language linkage being sufficient for that, but C has no notion of language linkage and so I worry that the declaration for the builtin will be incorrectly handled in C. 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
[Lldb-commits] [clang] [lldb] [clang][AST] fix ast-print of extern with >=2 declarators, fixed (PR #93913)
@@ -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 DeclContext *DC) {
+ if (!DC)
+return false;
+ if (const auto *SD = dyn_cast(DC))
if (!SD->hasBraces())
return true;
AaronBallman wrote:
```suggestion
return !SD->hasBraces();
```
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
[Lldb-commits] [clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)
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 potential issues it will introduce is definitely nonzero. We've already seen one such problem come up during review and I expect there will be more, but also, this makes potential merge conflicts for downstreams (of the potentially frustrating variety because tools don't make line ending merge conflicts easy to spot). It feels like a lot of churn for little benefit, even in the long term. Note, the changes to clang-format-vs should likely all be reverted. .sln is a Microsoft Visual Studio solution file, as are many of the others. Also, it's a bit funny to have .bat files without CRLF endings given that they run on Windows. I have no idea whether Visual Studio will be happy with .natvis files having non-Windows line endings. Realistically, each one of these files needs to be considered individually and that's a tall order for reviewers. https://github.com/llvm/llvm-project/pull/86318 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)
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/llvm/llvm-project/pull/86318 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [libcxx] [clang] [lldb] [lld] [mlir] [flang] [llvm] [compiler-rt] [clang] Fix unexpected `-Wconstant-logical-operand` in C23 (PR #80724)
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
[Lldb-commits] [llvm] [flang] [clang] [libcxx] [clang-tools-extra] [compiler-rt] [lld] [lldb] [libc] [Clang][C++23] Implement P2448R2: Relaxing some constexpr restrictions (PR #77753)
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? Would it make sense to change `DefaultedDestructorIsConstexpr` so it's not a one-bit boolean value but is instead a 2-bit enumeration so we can have `Yes`, `No`, `NotUntilCpp23` as values for it? Then we're not adding related flags but keeping the logic in a single flag? https://github.com/llvm/llvm-project/pull/77753 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [libunwind] [compiler-rt] [libcxx] [clang-tools-extra] [libcxxabi] [libc] [lld] [openmp] [mlir] [flang] [llvm] [clang] [lldb] [clang] static operators should evaluate object argument (P
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-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [libcxxabi] [clang] [libc] [compiler-rt] [lldb] [flang] [openmp] [libcxx] [libunwind] [llvm] [mlir] [clang-tools-extra] [lld] [clang] static operators should evaluate object argument (P
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 tests break due to conforming and correct changes in Clang). I mostly want to be mindful of the new contributor experience, as in this case. 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
[Lldb-commits] [libcxx] [llvm] [mlir] [libcxxabi] [clang] [compiler-rt] [openmp] [flang] [lld] [clang-tools-extra] [libc] [lldb] [libunwind] [clang] static operators should evaluate object argument (P
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 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [libc] [mlir] [compiler-rt] [openmp] [clang-tools-extra] [clang] [libcxx] [flang] [libunwind] [libcxxabi] [lld] [lldb] [llvm] [clang] static operators should evaluate object argument (P
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
[Lldb-commits] [libcxx] [llvm] [mlir] [libcxxabi] [clang] [compiler-rt] [openmp] [flang] [lld] [clang-tools-extra] [libc] [lldb] [libunwind] [clang] static operators should evaluate object argument (P
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/mailman/listinfo/lldb-commits
[Lldb-commits] [libcxx] [llvm] [mlir] [libcxxabi] [clang] [compiler-rt] [openmp] [flang] [lld] [clang-tools-extra] [libc] [lldb] [libunwind] [clang] static operators should evaluate object argument (P
@@ -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;
}
- EmitCallArgs(Args, dyn_cast(FnType), E->arguments(),
- E->getDirectCallee(), /*ParamsToSkip*/ 0, Order);
+ if (StaticOperator) {
+// If we're calling a static operator, we need to emit the object argument
+// and ignore it.
+EmitIgnoredExpr(E->getArg(0));
+
+EmitCallArgs(Args, dyn_cast(FnType),
+ drop_begin(E->arguments(), 1), E->getDirectCallee(),
+ /*ParamsToSkip=*/0, Order);
+ } else
+EmitCallArgs(Args, dyn_cast(FnType), E->arguments(),
+ E->getDirectCallee(), /*ParamsToSkip=*/0, Order);
AaronBallman wrote:
Ah, thank you Eli! I missed that this was a params vs args issue.
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
[Lldb-commits] [libcxx] [libcxxabi] [lldb] [libunwind] [clang-tools-extra] [libc] [mlir] [compiler-rt] [clang] [lld] [llvm] [openmp] [flang] [clang] static operators should evaluate object argument (P
@@ -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;
}
- EmitCallArgs(Args, dyn_cast(FnType), E->arguments(),
- E->getDirectCallee(), /*ParamsToSkip*/ 0, Order);
+ if (StaticOperator) {
+// If we're calling a static operator, we need to emit the object argument
+// and ignore it.
+EmitIgnoredExpr(E->getArg(0));
+
+EmitCallArgs(Args, dyn_cast(FnType),
+ drop_begin(E->arguments(), 1), E->getDirectCallee(),
+ /*ParamsToSkip=*/0, Order);
+ } else
+EmitCallArgs(Args, dyn_cast(FnType), E->arguments(),
+ E->getDirectCallee(), /*ParamsToSkip=*/0, Order);
AaronBallman wrote:
I think that suggests there's still a problem; we should not have to manually
drop the arguments when there's a parameter explicitly for that. I think what's
happening is that there's a mismatch between static call operator prototypes
and the checking logic in `EmitCallArgs`. CC @efriedma-quic @rjmccall
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
[Lldb-commits] [libcxxabi] [llvm] [clang-tools-extra] [lldb] [flang] [clang] [libunwind] [libcxx] [lld] [libc] [compiler-rt] Fix a bug in Smith's algorithm used in complex div. (PR #78330)
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
[Lldb-commits] [lldb] [clang-tools-extra] [clang] [c++20] P1907R1: Support for generalized non-type template arguments of scalar type. (PR #78041)
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/listinfo/lldb-commits
[Lldb-commits] [lldb] [clang-tools-extra] [clang] [c++20] P1907R1: Support for generalized non-type template arguments of scalar type. (PR #78041)
@@ -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 subject to array-to-pointer decay
+ // as if it were the declaration itself.
+ bool IsArrayToPointerDecayMangledAsDecl = false;
+ if (TopLevel && Ctx.getLangOpts().getClangABICompat() <=
+ LangOptions::ClangABI::Ver11) {
+QualType BType = B.getType();
+IsArrayToPointerDecayMangledAsDecl =
+BType->isArrayType() && V.getLValuePath().size() == 1 &&
+V.getLValuePath()[0].getAsArrayIndex() == 0 &&
+Ctx.hasSimilarType(T, Ctx.getDecayedType(BType));
+ }
+
AaronBallman wrote:
Thank you for the details!
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
[Lldb-commits] [clang-tools-extra] [clang] [lldb] [c++20] P1907R1: Support for generalized non-type template arguments of scalar type. (PR #78041)
@@ -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 TemplateArgument::StructuralValue:
+return false;
AaronBallman wrote:
Ping @dwblaikie
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
[Lldb-commits] [lldb] [clang] [clang-tools-extra] [c++20] P1907R1: Support for generalized non-type template arguments of scalar type. (PR #78041)
@@ -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 subject to array-to-pointer decay
+ // as if it were the declaration itself.
+ bool IsArrayToPointerDecayMangledAsDecl = false;
+ if (TopLevel && Ctx.getLangOpts().getClangABICompat() <=
+ LangOptions::ClangABI::Ver11) {
+QualType BType = B.getType();
+IsArrayToPointerDecayMangledAsDecl =
+BType->isArrayType() && V.getLValuePath().size() == 1 &&
+V.getLValuePath()[0].getAsArrayIndex() == 0 &&
+Ctx.hasSimilarType(T, Ctx.getDecayedType(BType));
+ }
+
AaronBallman wrote:
I'm surprised by the Clang 11 part: I would have expected this patch to only be
changing Clang 17 to Clang 18 behavior, right? Should this code be updated for
Clang 17 instead of Clang 11?
Also, there's no test coverage for these changes.
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
[Lldb-commits] [lldb] [clang-tools-extra] [clang] [c++20] P1907R1: Support for generalized non-type template arguments of scalar type. (PR #78041)
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
[Lldb-commits] [clang-tools-extra] [lldb] [clang] [c++20] P1907R1: Support for generalized non-type template arguments of scalar type. (PR #78041)
@@ -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 parameter the same way we mangle the template
+// argument.
+auto *SNTTPE = cast(E);
+if (auto *CE = dyn_cast(SNTTPE->getReplacement())) {
+ // Pull out the constant value and mangle it as a template argument.
+ QualType ParamType = SNTTPE->getParameterType(Context.getASTContext());
+ if (CE->hasAPValueResult())
+mangleValueInTemplateArg(ParamType, CE->getResultAsAPValue(), false,
+ /*NeedExactType=*/true);
+ else
+mangleValueInTemplateArg(ParamType, CE->getAPValueResult(), false,
+ /*NeedExactType=*/true);
AaronBallman wrote:
```suggestion
assert(CE->hasAPValueResult() && "expected the NTTP to have an APValue");
mangleValueInTemplateArg(ParamType, CE->getAPValueResult(), false,
/*NeedExactType=*/true);
```
By the time we get here, we had better have an `APValue` result object already,
but also `hasAPValueResult()` is looking at the `APValueKind` bitfield while
`getResultAsAPValue()` is checking the `ResultKind` bitfield.
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
[Lldb-commits] [clang] [lldb] [clang-tools-extra] [c++20] P1907R1: Support for generalized non-type template arguments of scalar type. (PR #78041)
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 if we could get this in before the Clang 18 branch next Tue if possible (no pressure though). 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
[Lldb-commits] [libcxxabi] [libc] [compiler-rt] [flang] [llvm] [lld] [libunwind] [clang] [lldb] [clang-tools-extra] [libcxx] Fix a bug in Smith's algorithm used in complex div. (PR #78330)
@@ -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::ComplexRangeKind Range) {
std::string ComplexRangeStr = "-complex-range=";
- ComplexRangeStr += Range;
+ switch (Range) {
+ case LangOptions::ComplexRangeKind::CX_Full:
+ComplexRangeStr += "full";
+break;
+ case LangOptions::ComplexRangeKind::CX_Limited:
+ComplexRangeStr += "limited";
+break;
+ case LangOptions::ComplexRangeKind::CX_Fortran:
+ComplexRangeStr += "fortran";
+break;
+ case LangOptions::ComplexRangeKind::CX_None:
+ComplexRangeStr = "";
AaronBallman wrote:
Is it valid to pass `-complex-range=` without anything after the equals sign?
Based on how this is called, I think this case should be an assertion instead,
WDYT?
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
[Lldb-commits] [libcxx] [clang] [libc] [libcxxabi] [libunwind] [compiler-rt] [lld] [clang-tools-extra] [flang] [lldb] [llvm] Fix a bug in Smith's algorithm used in complex div. (PR #78330)
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 the function might make sense but I don't think it's a requirement either (perhaps add a FIXME comment suggesting it?). 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
[Lldb-commits] [llvm] [libcxxabi] [libc] [clang-tools-extra] [libunwind] [lldb] [libcxx] [clang] [lld] [flang] [compiler-rt] Fix a bug in Smith's algorithm used in complex div. (PR #78330)
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
[Lldb-commits] [lld] [llvm] [libunwind] [compiler-rt] [libcxx] [clang-tools-extra] [libc] [libcxxabi] [flang] [lldb] [mlir] [clang] [libc++][numeric] P0543R3: Saturation arithmetic (PR #77967)
@@ -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-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef _LIBCPP___NUMERIC_SATURATION_ARITHMETIC_H
+#define _LIBCPP___NUMERIC_SATURATION_ARITHMETIC_H
+
+#include <__concepts/arithmetic.h>
+#include <__config>
+#include <__type_traits/decay.h>
+#include <__utility/cmp.h>
+#include
+
+#if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
+# pragma GCC system_header
+#endif
+
+_LIBCPP_BEGIN_NAMESPACE_STD
+
+#if _LIBCPP_STD_VER >= 26
+
+template
+concept __libcpp_standard_integer = __libcpp_unsigned_integer> ||
__libcpp_signed_integer>;
+
+template <__libcpp_standard_integer _Tp>
+_LIBCPP_HIDE_FROM_ABI constexpr _Tp add_sat(_Tp __x, _Tp __y) noexcept {
+ if (_Tp __sum; !__builtin_add_overflow(__x, __y, &__sum))
AaronBallman wrote:
It seems reasonable enough to punt on it for now, especially if there needs to
be a larger discussion. For example, `numeric_limits` may have some extra
complexity for its implementation, IO stream formatting, etc...
https://github.com/llvm/llvm-project/pull/77967
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [mlir] [libcxx] [llvm] [libunwind] [libcxxabi] [libc] [lldb] [compiler-rt] [lld] [clang-tools-extra] [flang] [libc++][numeric] P0543R3: Saturation arithmetic (PR #77967)
@@ -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-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef _LIBCPP___NUMERIC_SATURATION_ARITHMETIC_H
+#define _LIBCPP___NUMERIC_SATURATION_ARITHMETIC_H
+
+#include <__concepts/arithmetic.h>
+#include <__config>
+#include <__type_traits/decay.h>
+#include <__utility/cmp.h>
+#include
+
+#if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
+# pragma GCC system_header
+#endif
+
+_LIBCPP_BEGIN_NAMESPACE_STD
+
+#if _LIBCPP_STD_VER >= 26
+
+template
+concept __libcpp_standard_integer = __libcpp_unsigned_integer> ||
__libcpp_signed_integer>;
+
+template <__libcpp_standard_integer _Tp>
+_LIBCPP_HIDE_FROM_ABI constexpr _Tp add_sat(_Tp __x, _Tp __y) noexcept {
+ if (_Tp __sum; !__builtin_add_overflow(__x, __y, &__sum))
AaronBallman wrote:
You'll probably want to add test coverage for `_BitInt` as well given that it's
an extension Clang supports in C++.
https://github.com/llvm/llvm-project/pull/77967
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lld] [llvm] [compiler-rt] [libcxx] [libunwind] [flang] [clang] [mlir] [clang-tools-extra] [libc] [lldb] [libcxxabi] [libc++][numeric] P0543R3: Saturation arithmetic (PR #77967)
@@ -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-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef _LIBCPP___NUMERIC_SATURATION_ARITHMETIC_H
+#define _LIBCPP___NUMERIC_SATURATION_ARITHMETIC_H
+
+#include <__concepts/arithmetic.h>
+#include <__config>
+#include <__type_traits/decay.h>
+#include <__utility/cmp.h>
+#include
+
+#if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
+# pragma GCC system_header
+#endif
+
+_LIBCPP_BEGIN_NAMESPACE_STD
+
+#if _LIBCPP_STD_VER >= 26
+
+template
+concept __libcpp_standard_integer = __libcpp_unsigned_integer> ||
__libcpp_signed_integer>;
+
+template <__libcpp_standard_integer _Tp>
+_LIBCPP_HIDE_FROM_ABI constexpr _Tp add_sat(_Tp __x, _Tp __y) noexcept {
+ if (_Tp __sum; !__builtin_add_overflow(__x, __y, &__sum))
AaronBallman wrote:
`__builtin_add_overflow` already works with 128-bit integers:
https://godbolt.org/z/non8eMTfj, as well as bit-precise integers:
https://godbolt.org/z/dxs7h4G5b so I'm not certain there are Clang changes
needed?
https://github.com/llvm/llvm-project/pull/77967
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [libcxx] [lld] [lldb] [compiler-rt] [clang-tools-extra] [openmp] [mlir] [llvm] [flang] [clang] Add `intrin0.h` header to mimic `intrin0.h` used by MSVC STL for clang-cl (PR #757
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.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [llvm] [libcxxabi] [lld] [clang-tools-extra] [clang] [openmp] [libc] [libcxx] [libunwind] [lldb] [mlir] [flang] [Clang][Sema] Don't say "is declared here" for invalid template locations
@@ -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
: diag::err_template_param_shadow;
- Diag(Loc, DiagId) << cast(PrevDecl)->getDeclName();
- Diag(PrevDecl->getLocation(), diag::note_template_param_here);
+ NamedDecl *ND = cast(PrevDecl);
AaronBallman wrote:
```suggestion
const auto *ND = cast(PrevDecl);
```
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
[Lldb-commits] [llvm] [lldb] [mlir] [libc] [libcxx] [openmp] [libunwind] [clang-tools-extra] [flang] [libcxxabi] [lld] [clang] [Clang][Sema] Don't say "is declared here" for invalid template locations
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 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [libcxxabi] [libc] [mlir] [clang] [libunwind] [libcxx] [clang-tools-extra] [openmp] [lldb] [lld] [llvm] [flang] [Clang][Sema] Don't say "is declared here" for invalid template locations
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
[Lldb-commits] [clang] [lldb] [libc] [clang-tools-extra] [lld] [libcxx] [llvm] [libunwind] [flang] [compiler-rt] Fix clang to recognize new C23 modifiers %w and %wf when printing (PR #71771)
@@ -460,6 +463,14 @@ class FormatSpecifier {
FieldWidth = Amt;
}
+ void setExplicitlyFixedSize(unsigned s) {
+ExplicitlyFixedSize = s;
AaronBallman wrote:
```suggestion
void setExplicitlyFixedSize(unsigned S) {
ExplicitlyFixedSize = S;
```
https://github.com/llvm/llvm-project/pull/71771
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [compiler-rt] [lld] [lldb] [libunwind] [flang] [llvm] [libcxx] [libc] [clang-tools-extra] [clang] Fix clang to recognize new C23 modifiers %w and %wf when printing (PR #71771)
@@ -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') {
+lmKind = LengthModifier::AsWideFast;
+++I;
+ } else {
+lmKind = LengthModifier::AsWide;
+ }
+
+ if (I == E) return false;
+ int s = 0;
+ while (unsigned(*I - '0') <= 9) {
+s = 10 * s + unsigned(*I - '0');
+++I;
+ }
+
+ // s == 0 is MSVCRT case, like l but only for c, C, s, S, or Z on windows
+ // s != 0 for b, d, i, o, u, x, or X when a size followed(like 8, 16, 32
or 64)
+ if (s != 0) {
+std::set supported_list {8, 16, 32, 64};
+if (supported_list.count(s) == 0) {
+ return false;
+}
AaronBallman wrote:
```suggestion
if (supported_list.count(s) == 0)
return false;
```
https://github.com/llvm/llvm-project/pull/71771
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [flang] [libunwind] [clang-tools-extra] [libcxx] [clang] [libc] [compiler-rt] [llvm] [lld] Fix clang to recognize new C23 modifiers %w and %wf when printing (PR #71771)
@@ -537,8 +557,12 @@ ArgType PrintfSpecifier::getScalarArgType(ASTContext &Ctx, ArgType(Ctx.getPointerDiffType(), "ptrdiff_t")); case LengthModifier::AsAllocate: case LengthModifier::AsMAllocate: - case LengthModifier::AsWide: return ArgType::Invalid(); + case LengthModifier::AsWide: + case LengthModifier::AsWideFast: +int s = getExplicitlyFixedSize(); +bool fast = LM.getKind() == LengthModifier::AsWideFast ? true : false; +return clang::analyze_format_string::wToArgType(s, fast, Ctx); AaronBallman wrote: ```suggestion int S = getExplicitlyFixedSize(); bool Fast = LM.getKind() == LengthModifier::AsWideFast ? true : false; return clang::analyze_format_string::wToArgType(S, Fast, Ctx); ``` Same below. https://github.com/llvm/llvm-project/pull/71771 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [flang] [compiler-rt] [libunwind] [libcxx] [clang] [lld] [clang-tools-extra] [lldb] [libc] [llvm] Fix clang to recognize new C23 modifiers %w and %wf when printing (PR #71771)
@@ -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') {
+lmKind = LengthModifier::AsWideFast;
+++I;
+ } else {
+lmKind = LengthModifier::AsWide;
+ }
+
+ if (I == E) return false;
+ int s = 0;
+ while (unsigned(*I - '0') <= 9) {
+s = 10 * s + unsigned(*I - '0');
+++I;
+ }
+
+ // s == 0 is MSVCRT case, like l but only for c, C, s, S, or Z on windows
+ // s != 0 for b, d, i, o, u, x, or X when a size followed(like 8, 16, 32
or 64)
+ if (s != 0) {
AaronBallman wrote:
Should we return false in the case `s == 0`?
It would be good to add test coverage for parsing failures.
https://github.com/llvm/llvm-project/pull/71771
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [compiler-rt] [lld] [libcxx] [llvm] [clang] [lldb] [libc] [clang-tools-extra] [flang] Fix clang to recognize new C23 modifiers %w and %wf when printing (PR #71771)
@@ -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') {
+lmKind = LengthModifier::AsWideFast;
+++I;
+ } else {
+lmKind = LengthModifier::AsWide;
+ }
+
+ if (I == E) return false;
+ int s = 0;
+ while (unsigned(*I - '0') <= 9) {
+s = 10 * s + unsigned(*I - '0');
+++I;
+ }
+
+ // s == 0 is MSVCRT case, like l but only for c, C, s, S, or Z on windows
+ // s != 0 for b, d, i, o, u, x, or X when a size followed(like 8, 16, 32
or 64)
+ if (s != 0) {
+std::set supported_list {8, 16, 32, 64};
AaronBallman wrote:
Excellent, thank you (all) for the feedback! It sounds like we've got consensus
on a direction to move forward after this patch is finished.
https://github.com/llvm/llvm-project/pull/71771
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [compiler-rt] [libc] [lld] [lldb] [clang-tools-extra] [llvm] [flang] [libcxx] [clang] Fix clang to recognize new C23 modifiers %w and %wf when printing (PR #71771)
@@ -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') {
+lmKind = LengthModifier::AsWideFast;
+++I;
+ } else {
+lmKind = LengthModifier::AsWide;
+ }
+
+ if (I == E) return false;
+ int s = 0;
+ while (unsigned(*I - '0') <= 9) {
+s = 10 * s + unsigned(*I - '0');
+++I;
+ }
+
+ // s == 0 is MSVCRT case, like l but only for c, C, s, S, or Z on windows
+ // s != 0 for b, d, i, o, u, x, or X when a size followed(like 8, 16, 32
or 64)
+ if (s != 0) {
+std::set supported_list {8, 16, 32, 64};
AaronBallman wrote:
Thanks for the feedback! I did some research of my own to see what the
landscape looks like and here's what I found.
1) Support for these types came in
https://github.com/llvm/llvm-project/commit/55c9877b664c1bc6614ad588f376ef41fe6ab4ca
and there was no discussion on the patch
(https://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20091109/023777.html)
before it landed with post-commit review saying it looked good
(https://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20091116/024219.html)
and no justification beyond wanting a generalized algorithm.
2) There is hardware which supports 48-bit ints
(https://en.wikipedia.org/wiki/48-bit_computing), 36-bit ints
(https://en.wikipedia.org/wiki/36-bit_computing), 24-bit ints
(https://en.wikipedia.org/wiki/24-bit_computing), etc. A lot of it is older
hardware, but as examples, x86-64 uses a 48-bit addressing scheme, OpenCL
supports intrinsics for 24-bit multiplication, UniSys has a 36-bit system they
were selling as of 2015...
3) There's not evidence people are using stdint.h to serve those needs. For
example:
https://sourcegraph.com/search?q=context:global+int48_t+-file:.*clang.*+-file:.*stdint.*+-file:.*int48_t.*&patternType=standard&sm=1&groupBy=repo
shows that most uses are either a custom C++ data type, use of an underlying
non-basic int type, or bit-fields. I don't think I spotted a single use of
`int48_t` that came from stdint.h.
https://sourcegraph.com/search?q=context:global+int24_t+-file:.*clang.*+-file:.*stdint.*+-file:.*int24_t.*&patternType=standard&sm=1&groupBy=repo
shows similarly for `int24_t`.
4) The code which defines the underlying macros used by stdint.h is here:
https://github.com/llvm/llvm-project/blob/29a0f3ec2b47630ce229953fe7250e741b6c10b6/clang/lib/Frontend/InitPreprocessor.cpp#L220
and it uses `TargetInfo::getTypeWidth()` to determine the width generically.
We have no targets
(https://github.com/llvm/llvm-project/tree/main/clang/lib/Basic/Targets) which
define bit widths other than 8, 16, 32, 64, or 128. So Clang itself doesn't
support those odd types yet.
Based on this and your details above, I think we should ignore these odd types
for format strings on the assumption they're just not used. As for removing
them from `stdint.h`, I think that is reasonable to explore given that we have
no targets defining those widths (and so we should never be defining those
macros to begin with); the algorithm remains general, we just drop the extra
cruft from stdint.h. I don't think this should cause any issues.
CC @jrtc27 @jyknight for some extra opinions.
https://github.com/llvm/llvm-project/pull/71771
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang-tools-extra] [flang] [clang] [compiler-rt] [libcxx] [llvm] [lldb] [libc] ✨ [Sema, Lex, Parse] Preprocessor embed in C and C++ (and Obj-C and Obj-C++ by-proxy) (PR #68620)
@@ -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
+// literals.
+if (CurrentToken->isNot(tok::comment) &&
+!CurrentToken->TokenText.startswith("//")) {
+ CurrentToken->setType(TT_ImplicitStringLiteral);
AaronBallman wrote:
Thanks! When you get to the point of working on this, I'm happy to review/help
how I can.
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
[Lldb-commits] [clang-tools-extra] [libcxx] [libc] [llvm] [lldb] [compiler-rt] [clang] [flang] ✨ [Sema, Lex, Parse] Preprocessor embed in C and C++ (and Obj-C and Obj-C++ by-proxy) (PR #68620)
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 reasonable way to think about it. > (similar in feel to `#pragma` which is also not purely preprocessor, despite > starting with `#`.) I don't see `#pragma` as being similar -- there is no sequence of preprocessed tokens to emit for a pragma, but there is for `#embed`. In fact, it is described specifically in terms of expansion (6.10.3p7): > The expansion of a #embed directive is a token sequence formed from the list > of integer constant expressions described below. The group of tokens for each integer constant expression in the list is separated in the token sequence from the group of tokens for the previous integer constant expression in the list by a comma. The sequence neither begins nor ends in a comma. If the list of integer constant expressions is empty, the token sequence is empty. The directive is replaced by its expansion and, with the presence of certain embed parameters, additional or replacement token sequences. So it's not so much that it's not actually true in the implementation details, it's that it's not actually true by specification either. 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
[Lldb-commits] [flang] [llvm] [lldb] [clang-tools-extra] [libc] [clang] [compiler-rt] [libcxx] ✨ [Sema, Lex, Parse] Preprocessor embed in C and C++ (and Obj-C and Obj-C++ by-proxy) (PR #68620)
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 embedded base64 -- and actually, seems > more of a pain to decode. > > I think the most user-friendly behavior would be: > > * `-E`: convert `#embed "file"` into `#embed_base64 > "base64-file-contents"`. This preserves the property of the output not > depending on other files, but doesn't make it hugely-bloated. > > * `-E -dE`: preserve any `#embed` directive as-is, referring to the > external file. > > * Potentially another `-d?` mode to explode `#embed` into the raw > integers (like you had proposed for the default behavior) -- though I'm not > sure that's really going to be useful. I agree with you that the exploded list of integers will potentially add a lot of content to the preprocessed output. However, the behavior of `-E` has always been to produce a fully preprocessed representation of the original source; your design breaks that. A significant use case for `-E` is as a way to debug surprising preprocessor behavior. So it depends on *why* you're using `-E` as to whether the contents are salient or not. Perhaps your approach is still reasonable, but I would personally find it to be a surprising change from the usual expectations. In some situations, I suspect the preprocessed data may not be crucial to explode out. e.g., as a braced initializer for an array. But there are other situations where the base64 data is not useful. e.g., as an initializer for a structure, as a list of arguments to a function, etc. I anticipate use to predominately be in an initializer lists for an array but we have no actual usage experience with the feature either. That's why I lean towards "do the most expected thing by default" which would be to emit the actual list of integers even if it's large. 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
[Lldb-commits] [llvm] [compiler-rt] [clang] [libcxx] [clang-tools-extra] [lldb] [libc] [flang] ✨ [Sema, Lex, Parse] Preprocessor embed in C and C++ (and Obj-C and Obj-C++ by-proxy) (PR #68620)
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 fragment of, and not so > rarely reduce crash by themselves. I'm not fond of the idea on giving up on > every embed-related crash, because there is a risk (which I'm not estimating > high), that submitter forgot to check their otherwise open code for sensitive > information. This doesn't help us ironing out bugs in `#embed` implementation > in the long run. I think folks are conscious of that because 1) it's been a known issue with header files for ages and 2) header files are textual prose that you can often read to see it's sensitive (e.g., a notice in a comment at the top of the file). I don't think either of those hold true for `#embed` though. Further, I think leaking source code is a different kind of issue than leaking credentials stored in a binary blob in some ways -- they're both leaks, but leaked header code isn't usually immediately exploitable by itself. > One might say that additional back-and-forth with crash submitter is not too > big of a deal, and it would be, if we haven't had ever-growing backlog of > issues, some dating back more than a decade. Our existing workflow that > allows people to drop attachments on us and forget about it has proven itself > useful in the very long run. So I'd like us to keep this. I agree that it would be nice to have, but I think we need to think very carefully about the behavior here. I think `#embed` usage will be quite a bit different from `#include` usage in the wild; I'd rather we err on the side of caution until we have a more clear understanding of usage patterns in the wild. (Again, I'm flexible here -- if we think my concerns aren't realistic ones, then that changes my opinions.) 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
[Lldb-commits] [clang] [libc] [clang-tools-extra] [flang] [llvm] [libcxx] [compiler-rt] [lldb] ✨ [Sema, Lex, Parse] Preprocessor embed in C and C++ (and Obj-C and Obj-C++ by-proxy) (PR #68620)
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`. I'm wary of this for privacy reasons. Including header files makes a lot of sense because there's almost no chance a reproducer will be useful without those header files. I don't think the same is true with `#embed` though it certainly is plausible. And header files can contain sensitive information, so the problem of leaking sensitive details already exists. However, with include files, you can tell at a glance if you're pulling in sensitive information because everything is textual code. I think `#embed` is a bit different in that it seems likely to contain sensitive information that would be hard to spot if it was base64 encoded; you'd need more contextual information from the code to determine what is being embedded. I think the safer approach for users would be `-E -dE` mode where the resource isn't embedded. The downside to this is: you can't immediately pass the script to Clang because the `#embed` directives likely won't find the correct file, so triage may need to reduce the test case to remove the directive. But given that we want reduced test cases anyway, maybe that's reasonable? 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
[Lldb-commits] [lldb] [libc] [compiler-rt] [libcxx] [llvm] [flang] [clang-tools-extra] [clang] ✨ [Sema, Lex, Parse] Preprocessor embed in C and C++ (and Obj-C and Obj-C++ by-proxy) (PR #68620)
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 specify a search path for `<>` and `""` embedded resources; the quoted form will search the current directory similar to how it behaves for `#include`. I do not envision needing a "system" embedded resources directory, but should such a need arise, we can consider something like `--embed-system=` to support it. * `-E -dE` as a way to preprocess to a file without exploding the contents of the embedded resource into the preprocessed output (that output could become very large). Then the options for determining makefile dependencies can be updated to consider embedded resources are a dependency and tools like distcc can hopefully cope from there. * As a follow-up, I might consider adding a directive `#embed_base64` that holds base64 encoded file contents of the resource to be embedded. Then we can add `-E -dE64` (or some other option name) to preprocess from `#embed ` to `#embed_base64 ` for times when it's not plausible to keep the source and the resource separately. I don't envision that being a directive users would use directly, but instead only for rewriting purposes. Ideally, GCC and Clang can agree on what and how we surface the command line features. 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
[Lldb-commits] [flang] [libcxx] [lldb] [compiler-rt] [libc] [clang] [clang-tools-extra] [llvm] ✨ [Sema, Lex, Parse] Preprocessor embed in C and C++ (and Obj-C and Obj-C++ by-proxy) (PR #68620)
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
[Lldb-commits] [libcxx] [flang] [compiler-rt] [clang] [lld] [lldb] [llvm] [libc] [clang-tools-extra] [clang][NFC] Annotate `Type` bit-fields with `clang::preferred_type` (PR #70349)
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
[Lldb-commits] [lld] [compiler-rt] [flang] [libcxx] [llvm] [libc] [clang] [clang-tools-extra] [lldb] [clang][NFC] Annotate `Type` bit-fields with `clang::preferred_type` (PR #70349)
@@ -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 wrote: ```suggestion #if LLVM_HAS_CPP_ATTRIBUTE(clang::preferred_type) ``` or leave the condition as-is and change the expansion to using `__attribute__(())` instead. Just making sure they both match up. (If we're using this from C interfaces, then we probably want to use the GNU-style spelling.) 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
[Lldb-commits] [llvm] [clang-tools-extra] [lld] [libc] [clang] [libcxx] [lldb] [compiler-rt] [flang] [clang][NFC] Annotate `Type` bit-fields with `clang::preferred_type` (PR #70349)
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://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Diagnose use of VLAs in a coroutine (PR #70341)
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
[Lldb-commits] [lldb] Diagnose use of VLAs in a coroutine (PR #70341)
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://github.com/llvm/llvm-project/issues/65858
---
.../clang/Basic/DiagnosticSemaKinds.td| 2 ++
clang/include/clang/Sema/ScopeInfo.h | 8 +
clang/lib/Sema/SemaCoroutine.cpp | 5
clang/lib/Sema/SemaType.cpp | 18
clang/test/SemaCXX/coroutine-vla.cpp | 29 +++
5 files changed, 56 insertions(+), 6 deletions(-)
create mode 100644 clang/test/SemaCXX/coroutine-vla.cpp
diff --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index a673ce726d6c220..453bd8a9a340425 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -166,6 +166,8 @@ def ext_vla_folded_to_constant : ExtWarn<
InGroup;
def err_vla_unsupported : Error<
"variable length arrays are not supported for %select{the current
target|'%1'}0">;
+def err_vla_in_coroutine_unsupported : Error<
+ "variable length arrays in a coroutine are not supported">;
def note_vla_unsupported : Note<
"variable length arrays are not supported for the current target">;
diff --git a/clang/include/clang/Sema/ScopeInfo.h
b/clang/include/clang/Sema/ScopeInfo.h
index 02b22af89ff035d..b2f6e3289f41fce 100644
--- a/clang/include/clang/Sema/ScopeInfo.h
+++ b/clang/include/clang/Sema/ScopeInfo.h
@@ -189,6 +189,9 @@ class FunctionScopeInfo {
/// First SEH '__try' statement in the current function.
SourceLocation FirstSEHTryLoc;
+ /// First use of a VLA within the current function.
+ SourceLocation FirstVLALoc;
+
private:
/// Used to determine if errors occurred in this function or block.
DiagnosticErrorTrap ErrorTrap;
@@ -473,6 +476,11 @@ class FunctionScopeInfo {
FirstSEHTryLoc = TryLoc;
}
+ void setHasVLA(SourceLocation VLALoc) {
+if (FirstVLALoc.isInvalid())
+ FirstVLALoc = VLALoc;
+ }
+
bool NeedsScopeChecking() const {
return !HasDroppedStmt && (HasIndirectGoto || HasMustTail ||
(HasBranchProtectedScope &&
HasBranchIntoScope));
diff --git a/clang/lib/Sema/SemaCoroutine.cpp b/clang/lib/Sema/SemaCoroutine.cpp
index d2b0922a4bb9c4c..e1f3b5acb3cadec 100644
--- a/clang/lib/Sema/SemaCoroutine.cpp
+++ b/clang/lib/Sema/SemaCoroutine.cpp
@@ -1198,6 +1198,11 @@ void Sema::CheckCompletedCoroutineBody(FunctionDecl *FD,
Stmt *&Body) {
if (FD->hasAttr())
Diag(FD->getLocation(), diag::warn_always_inline_coroutine);
+ // We don't allow use of VLAs within a coroutine, so diagnose if we've seen
+ // a VLA in the body of this function.
+ if (Fn->FirstVLALoc.isValid())
+Diag(Fn->FirstVLALoc, diag::err_vla_in_coroutine_unsupported);
+
// [stmt.return.coroutine]p1:
// A coroutine shall not enclose a return statement ([stmt.return]).
if (Fn->FirstReturnLoc.isValid()) {
diff --git a/clang/lib/Sema/SemaType.cpp b/clang/lib/Sema/SemaType.cpp
index 28b81c1768a3004..dea77fae4cadb59 100644
--- a/clang/lib/Sema/SemaType.cpp
+++ b/clang/lib/Sema/SemaType.cpp
@@ -2706,12 +2706,18 @@ QualType Sema::BuildArrayType(QualType T,
ArrayType::ArraySizeModifier ASM,
}
}
- if (T->isVariableArrayType() && !Context.getTargetInfo().isVLASupported()) {
-// CUDA device code and some other targets don't support VLAs.
-bool IsCUDADevice = (getLangOpts().CUDA && getLangOpts().CUDAIsDevice);
-targetDiag(Loc,
- IsCUDADevice ? diag::err_cuda_vla : diag::err_vla_unsupported)
-<< (IsCUDADevice ? CurrentCUDATarget() : 0);
+ if (T->isVariableArrayType()) {
+if (!Context.getTargetInfo().isVLASupported()) {
+ // CUDA device code and some other targets don't support VLAs.
+ bool IsCUDADevice = (getLangOpts().CUDA && getLangOpts().CUDAIsDevice);
+ targetDiag(Loc,
+ IsCUDADevice ? diag::err_cuda_vla : diag::err_vla_unsupported)
+ << (IsCUDADevice ? CurrentCUDATarget() : 0);
+} else if (sema::FunctionScopeInfo *FSI = getCurFunction()) {
+ // VLAs are supported on this target, but we may need to do delayed
+ // checking that the VLA is not being used within a coroutine.
+ FSI->setHasVLA(Loc);
+}
}
// If this is not C99, diagnose array size modifiers on non-VLAs.
diff --git a/clang/test/SemaCXX/coroutine-vla.cpp
b/clang/test/SemaCXX/coroutine-vla.cpp
new file mode 100644
index 000..176e35f346e2b45
--- /dev/null
+++ b/clang/test/SemaCXX/coroutine-vla.cpp
@@ -0,0 +1,29 @@
+// RUN: %clang_cc1 %s -std=c++20 -fsyntax-only -Wno-vla-cxx-extension -verify
+#include "Inputs/std-coroutine.h"
+
+struct promise;
+
+struct coroutine : std::coroutine_handle {
+ using promise_type = ::promise;
+};
+
+stru
[Lldb-commits] [lldb] [lldb] Add value to enumerator dump (PR #69815)
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 changes you can get in the debug > > view. > > How is Visual Studio getting access to LLDB when debugging? Is it using the > lldb-vscode debug adaptor protocol from the VS Code stuff? I'm sorry for the confusion! I didn't mean to imply that I was using lldb through Visual Studio, only that I'm used to my debugger showing me both pieces of information at the same time instead of making me ask it twice, and I support lldb doing something similar. https://github.com/llvm/llvm-project/pull/69815 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add value to enumerator dump (PR #69815)
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 changes you can get in the debug view. https://github.com/llvm/llvm-project/pull/69815 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add value to enumerator dump (PR #69815)
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 is one. If there is no value > (structs and class instances have no values), then they show the summary only. Ah that could explain it. I'm used to seeing the value and the summary when both are available. https://github.com/llvm/llvm-project/pull/69815 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add value to enumerator dump (PR #69815)
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 display `Enum (1)`, it should continue to display just `Enum`. But the summary could be changed for enumerations so it says `(1)`, so that both pieces of information would appear in the debugger by default? https://github.com/llvm/llvm-project/pull/69815 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Update stdckdint.h and make it available in pre-C23 modes. (PR #69649)
@@ -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 are aliases), did you mean to use `-std=c11` or something along those lines? https://github.com/llvm/llvm-project/pull/69649 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Update stdckdint.h and make it available in pre-C23 modes. (PR #69649)
@@ -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` entirely and just always define the macro. https://github.com/llvm/llvm-project/pull/69649 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add value to enumerator dump (PR #69815)
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.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [llvm][tblgen] Add `SourcePath` for `emitSourceFileHeader` (PR #65744)
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/2f23666ae7e434a222a67ac6499d118035ab7903/llvm/include/llvm/Support/Path.h#L357 to get the base filename from the path, and then print just the base filename. https://github.com/llvm/llvm-project/pull/65744 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [llvm][tblgen] Add `SourcePath` for `emitSourceFileHeader` (PR #65744)
@@ -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 << "// Generated from: " << Record.getInputFilename() << "\n\n";
AaronBallman wrote:
Good question! I was thinking it would give just the base file name, not the
full path to the file:
https://github.com/llvm/llvm-project/blob/aa8f5e6156821aec1fed595f2e13d69655ec3311/llvm/lib/TableGen/Main.cpp#L115
-- that looks like it will generate whatever was given on the command line,
which could very well be a full path.
https://github.com/llvm/llvm-project/pull/65744
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [llvm][tblgen] Add `SourcePath` for `emitSourceFileHeader` (PR #65744)
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 https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [llvm][tblgen] Add `SourcePath` for `emitSourceFileHeader` (PR #65744)
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 makes code archeology much harder). https://github.com/llvm/llvm-project/pull/65744 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 7349bc3 - Speculatively fix the lldb test bots
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
LOG: Speculatively fix the lldb test bots
This should fix the issue found by:
https://lab.llvm.org/buildbot/#/builders/68/builds/41100
Added:
Modified:
lldb/test/API/commands/expression/expr_inside_lambda/TestExprInsideLambdas.py
Removed:
diff --git
a/lldb/test/API/commands/expression/expr_inside_lambda/TestExprInsideLambdas.py
b/lldb/test/API/commands/expression/expr_inside_lambda/TestExprInsideLambdas.py
index 9b8937aaa0c23..aa7c01c055fc2 100644
---
a/lldb/test/API/commands/expression/expr_inside_lambda/TestExprInsideLambdas.py
+++
b/lldb/test/API/commands/expression/expr_inside_lambda/TestExprInsideLambdas.py
@@ -112,7 +112,7 @@ def test_expr_inside_lambda(self):
" 'base_var'"))
self.expectExprError("local_var", ("use of non-static data member
'local_var'"
- " of '' from nested type
'LocalLambdaClass'"))
+ " of '(unnamed class)' from nested
type 'LocalLambdaClass'"))
# Inside non_capturing_method
lldbutil.continue_to_breakpoint(process, bkpt)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] c598396 - Speculatively fix the lldb build
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
LOG: Speculatively fix the lldb build
This should fix the issues found by:
https://lab.llvm.org/buildbot/#/builders/68/builds/40172
Added:
Modified:
lldb/unittests/Symbol/TestTypeSystemClang.cpp
Removed:
diff --git a/lldb/unittests/Symbol/TestTypeSystemClang.cpp
b/lldb/unittests/Symbol/TestTypeSystemClang.cpp
index 4da17cf3610cd..23594340e71b3 100644
--- a/lldb/unittests/Symbol/TestTypeSystemClang.cpp
+++ b/lldb/unittests/Symbol/TestTypeSystemClang.cpp
@@ -726,21 +726,22 @@ TEST_F(TestTypeSystemClang, TestGetTypeClassDeclType) {
TEST_F(TestTypeSystemClang, TestGetTypeClassTypeOf) {
clang::ASTContext &ctxt = m_ast->getASTContext();
- QualType t = ctxt.getTypeOfType(makeConstInt(ctxt));
+ QualType t = ctxt.getTypeOfType(makeConstInt(ctxt), TypeOfKind::Qualified);
EXPECT_EQ(lldb::eTypeClassBuiltin, m_ast->GetTypeClass(t.getAsOpaquePtr()));
}
TEST_F(TestTypeSystemClang, TestGetTypeClassTypeOfExpr) {
clang::ASTContext &ctxt = m_ast->getASTContext();
auto *nullptr_expr = new (ctxt) CXXNullPtrLiteralExpr(ctxt.NullPtrTy,
SourceLocation());
- QualType t = ctxt.getTypeOfExprType(nullptr_expr);
+ QualType t = ctxt.getTypeOfExprType(nullptr_expr, TypeOfKind::Qualified);
EXPECT_EQ(lldb::eTypeClassBuiltin, m_ast->GetTypeClass(t.getAsOpaquePtr()));
}
TEST_F(TestTypeSystemClang, TestGetTypeClassNested) {
clang::ASTContext &ctxt = m_ast->getASTContext();
- QualType t_base = ctxt.getTypeOfType(makeConstInt(ctxt));
- QualType t = ctxt.getTypeOfType(t_base);
+ QualType t_base =
+ ctxt.getTypeOfType(makeConstInt(ctxt), TypeOfKind::Qualified);
+ QualType t = ctxt.getTypeOfType(t_base, TypeOfKind::Qualified);
EXPECT_EQ(lldb::eTypeClassBuiltin, m_ast->GetTypeClass(t.getAsOpaquePtr()));
}
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 2df9bd3 - Do not rely on implicit int for this test
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
LOG: Do not rely on implicit int for this test
This should address failing test bots:
https://lab.llvm.org/buildbot/#/builders/68/builds/31828
Added:
Modified:
lldb/test/API/commands/expression/rdar42038760/main.c
Removed:
diff --git a/lldb/test/API/commands/expression/rdar42038760/main.c
b/lldb/test/API/commands/expression/rdar42038760/main.c
index 98a957faf8bda..2ce1e4ee9aacc 100644
--- a/lldb/test/API/commands/expression/rdar42038760/main.c
+++ b/lldb/test/API/commands/expression/rdar42038760/main.c
@@ -4,7 +4,7 @@ typedef unsigned int uint32_t;
struct S0 {
signed f2;
};
-static g_463 = 0x1561983AL;
+static int g_463 = 0x1561983AL;
void func_1(void)
{
struct S0 l_19;
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 6234313 - Fix failing buildbot for lldb
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
LOG: Fix failing buildbot for lldb
This should address the issue found by:
https://lab.llvm.org/buildbot/#/builders/68/builds/31827
Added:
Modified:
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
Removed:
diff --git a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
index 019cb0c1b8449..cb0e2ed1171f1 100644
--- a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
+++ b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
@@ -510,7 +510,6 @@ static void ParseLangArgs(LangOptions &Opts, InputKind IK,
const char *triple) {
Opts.GNUMode = Std.isGNUMode();
Opts.GNUInline = !Std.isC99();
Opts.HexFloats = Std.hasHexFloats();
- Opts.ImplicitInt = Std.hasImplicitInt();
Opts.WChar = true;
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] a749e32 - Replace links to archived mailing lists by links to Discourse forums
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
LOG: Replace links to archived mailing lists by links to Discourse forums
Added:
Modified:
clang-tools-extra/README.txt
clang/README.txt
clang/www/analyzer/menu.html.incl
clang/www/demo/index.cgi
clang/www/menu.html.incl
compiler-rt/www/menu.html.incl
flang/docs/GettingInvolved.md
libcxx/docs/index.rst
libunwind/docs/index.rst
lldb/docs/index.rst
llvm/docs/Contributing.rst
llvm/docs/ExtendingLLVM.rst
llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl10.rst
Removed:
diff --git a/clang-tools-extra/README.txt b/clang-tools-extra/README.txt
index 9809cc38ccf4f..9c859a052c4b4 100644
--- a/clang-tools-extra/README.txt
+++ b/clang-tools-extra/README.txt
@@ -11,8 +11,8 @@ This repository is only intended to be checked out inside of
a full LLVM+Clang
tree, and in the 'tools/extra' subdirectory of the Clang checkout.
All discussion regarding Clang, Clang-based tools, and code in this repository
-should be held using the standard Clang mailing lists:
- http://lists.llvm.org/mailman/listinfo/cfe-dev
+should be held using the standard Clang forum:
+ https://discourse.llvm.org/c/clang
Code review for this tree should take place on the standard Clang patch and
commit lists:
diff --git a/clang/README.txt b/clang/README.txt
index 91527b094856f..63842d42bc208 100644
--- a/clang/README.txt
+++ b/clang/README.txt
@@ -19,8 +19,8 @@ Clang Static Analyzer:
http://clang-analyzer.llvm.org/
Information on the LLVM project: http://llvm.org/
If you have questions or comments about Clang, a great place to discuss them is
-on the Clang development mailing list:
- http://lists.llvm.org/mailman/listinfo/cfe-dev
+on the Clang forums:
+ https://discourse.llvm.org/c/clang/
If you find a bug in Clang, please file it in the LLVM bug tracker:
http://llvm.org/bugs/
diff --git a/clang/www/analyzer/menu.html.incl
b/clang/www/analyzer/menu.html.incl
index ce24834eb164b..7e97efcdcde01 100644
--- a/clang/www/analyzer/menu.html.incl
+++ b/clang/www/analyzer/menu.html.incl
@@ -32,9 +32,9 @@
- Mailing Lists
+ Mailing List & Forums
-http://lists.llvm.org/mailman/listinfo/cfe-dev";>cfe-dev
+https://discourse.llvm.org/c/clang";>Clang Frontend
Forums
http://lists.llvm.org/mailman/listinfo/cfe-commits";>cfe-commits
diff --git a/clang/www/demo/index.cgi b/clang/www/demo/index.cgi
index 0fded355b67ce..d20a3f9474b5f 100644
--- a/clang/www/demo/index.cgi
+++ b/clang/www/demo/index.cgi
@@ -20,7 +20,7 @@ if ( !-d $ROOT ) { mkdir( $ROOT, 0777 ); }
my $LOGFILE = "$ROOT/log.txt";
my $FORM_URL= 'index.cgi';
my $MAILADDR= 'sa...@nondot.org';
-my $CONTACT_ADDRESS = 'Questions or comments? Email the http://lists.llvm.org/mailman/listinfo/llvm-dev";>LLVM-dev mailing
list.';
+my $CONTACT_ADDRESS = 'Questions or comments? Discuss on the https://discourse.llvm.org";>LLVM forum.';
my $LOGO_IMAGE_URL = 'cathead.png';
my $TIMEOUTAMOUNT = 20;
$ENV{'LD_LIBRARY_PATH'} = '/home/vadve/shared/localtools/fc1/lib/';
diff --git a/clang/www/menu.html.incl b/clang/www/menu.html.incl
index 72c483d273453..372e1492f827e 100755
--- a/clang/www/menu.html.incl
+++ b/clang/www/menu.html.incl
@@ -33,8 +33,7 @@
Communication
-http://lists.llvm.org/mailman/listinfo/cfe-users";>cfe-users
List
-http://lists.llvm.org/mailman/listinfo/cfe-dev";>cfe-dev List
+https://discourse.llvm.org/c/clang";>Clang Forum
http://lists.llvm.org/mailman/listinfo/cfe-commits";>cfe-commits
List
https://github.com/llvm/llvm-project/issues";>Bug Reports
http://planet.clang.org/";>Planet Clang
diff --git a/compiler-rt/www/menu.html.incl b/compiler-rt/www/menu.html.incl
index 9f8273967c73d..e128cc7137e4a 100644
--- a/compiler-rt/www/menu.html.incl
+++ b/compiler-rt/www/menu.html.incl
@@ -10,7 +10,7 @@
Quick Links
-http://lists.llvm.org/mailman/listinfo/llvm-dev";>llvm-dev
+https://discourse.llvm.org";>LLVM Forum
http://lists.llvm.org/mailman/listinfo/llvm-commits";>llvm-commits
http://llvm.org/bugs/";>Bug Reports
https://github.com/llvm/llvm-project/tree/main/compiler-rt/";>Browse
Sources
diff --git a/flang/docs/GettingInvolved.md b/flang/docs/GettingInvolved.md
index ae6f05f7f93b6..efae97ee4b50b 100644
--- a/flang/docs/GettingInvolved.md
+++ b/flang/docs/GettingInvolved.md
@@ -16,12 +16,11 @@ The Flang Project welcomes contributions of all kinds.
Please feel free to join the mailing list or the slack channel for discussions
related to development of Flang.
To understand the status of vari
[Lldb-commits] [lldb] 1f257ac - Speculatively fix the LLDB build bots from 6c75ab5f66b403f7ca67e86aeed3a58abe10570b
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
LOG: Speculatively fix the LLDB build bots from
6c75ab5f66b403f7ca67e86aeed3a58abe10570b
It looks like some renames got missed.
Added:
Modified:
clang/lib/Sema/SemaTemplateDeduction.cpp
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
Removed:
diff --git a/clang/lib/Sema/SemaTemplateDeduction.cpp
b/clang/lib/Sema/SemaTemplateDeduction.cpp
index d527a379c9836..e9636d2b942e8 100644
--- a/clang/lib/Sema/SemaTemplateDeduction.cpp
+++ b/clang/lib/Sema/SemaTemplateDeduction.cpp
@@ -2144,7 +2144,7 @@ static Sema::TemplateDeductionResult
DeduceTemplateArgumentsByTypeMatch(
return Sema::TDK_NonDeducedMismatch;
}
-case Type::DependentExtInt: {
+case Type::DependentBitInt: {
const auto *IP = P->castAs();
if (const auto *IA = A->getAs()) {
diff --git a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
index b1dbc382ff041..9b6327754f6c5 100644
--- a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
+++ b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
@@ -4088,8 +4088,8 @@
TypeSystemClang::GetTypeClass(lldb::opaque_compiler_type_t type) {
return lldb::eTypeClassVector;
case clang::Type::Builtin:
// Ext-Int is just an integer type.
- case clang::Type::ExtInt:
- case clang::Type::DependentExtInt:
+ case clang::Type::BitInt:
+ case clang::Type::DependentBitInt:
return lldb::eTypeClassBuiltin;
case clang::Type::ObjCObjectPointer:
return lldb::eTypeClassObjCObjectPointer;
@@ -4744,8 +4744,8 @@ lldb::Encoding
TypeSystemClang::GetEncoding(lldb::opaque_compiler_type_t type,
// TODO: Set this to more than one???
break;
- case clang::Type::ExtInt:
- case clang::Type::DependentExtInt:
+ case clang::Type::BitInt:
+ case clang::Type::DependentBitInt:
return qual_type->isUnsignedIntegerType() ? lldb::eEncodingUint
: lldb::eEncodingSint;
@@ -5124,8 +5124,8 @@ lldb::Format
TypeSystemClang::GetFormat(lldb::opaque_compiler_type_t type) {
case clang::Type::Vector:
break;
- case clang::Type::ExtInt:
- case clang::Type::DependentExtInt:
+ case clang::Type::BitInt:
+ case clang::Type::DependentBitInt:
return qual_type->isUnsignedIntegerType() ? lldb::eFormatUnsigned
: lldb::eFormatDecimal;
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] fa72ce3 - Another speculative fix for lldb related to ConstexprSpecKind
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 LOG: Another speculative fix for lldb related to ConstexprSpecKind Added: Modified: lldb/source/Plugins/ExpressionParser/Clang/NameSearchContext.cpp Removed: diff --git a/lldb/source/Plugins/ExpressionParser/Clang/NameSearchContext.cpp b/lldb/source/Plugins/ExpressionParser/Clang/NameSearchContext.cpp index c1f9f1dc..829afa5ffcec 100644 --- a/lldb/source/Plugins/ExpressionParser/Clang/NameSearchContext.cpp +++ b/lldb/source/Plugins/ExpressionParser/Clang/NameSearchContext.cpp @@ -78,7 +78,8 @@ clang::NamedDecl *NameSearchContext::AddFunDecl(const CompilerType &type, clang::FunctionDecl *func_decl = FunctionDecl::Create( ast, context, SourceLocation(), SourceLocation(), decl_name, qual_type, nullptr, SC_Extern, isInlineSpecified, hasWrittenPrototype, - isConstexprSpecified ? CSK_constexpr : CSK_unspecified); + isConstexprSpecified ? ConstexprSpecKind::Constexpr + : ConstexprSpecKind::Unspecified); // We have to do more than just synthesize the FunctionDecl. We have to // synthesize ParmVarDecls for all of the FunctionDecl's arguments. To do ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 1941d96 - Speculatively fix the lldb build
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
LOG: Speculatively fix the lldb build
Pick up the changes from 41b65f166b51760f77d0f9e465b3858f46e101f0.
Added:
Modified:
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
Removed:
diff --git a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
index 6e27386a233c..37ad7ff035c0 100644
--- a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
+++ b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
@@ -2030,8 +2030,9 @@ FunctionDecl *TypeSystemClang::CreateFunctionDeclaration(
func_decl->setStorageClass(storage);
func_decl->setInlineSpecified(is_inline);
func_decl->setHasWrittenPrototype(hasWrittenPrototype);
- func_decl->setConstexprKind(isConstexprSpecified ? CSK_constexpr
- : CSK_unspecified);
+ func_decl->setConstexprKind(isConstexprSpecified
+ ? ConstexprSpecKind::Constexpr
+ : ConstexprSpecKind::Unspecified);
SetOwningModule(func_decl, owning_module);
if (func_decl)
decl_ctx->addDecl(func_decl);
@@ -7425,7 +7426,7 @@ clang::CXXMethodDecl
*TypeSystemClang::AddMethodToCXXRecordType(
cxx_dtor_decl->setType(method_qual_type);
cxx_dtor_decl->setImplicit(is_artificial);
cxx_dtor_decl->setInlineSpecified(is_inline);
-cxx_dtor_decl->setConstexprKind(CSK_unspecified);
+cxx_dtor_decl->setConstexprKind(ConstexprSpecKind::Unspecified);
cxx_method_decl = cxx_dtor_decl;
} else if (decl_name == cxx_record_decl->getDeclName()) {
cxx_ctor_decl = clang::CXXConstructorDecl::CreateDeserialized(
@@ -7437,7 +7438,7 @@ clang::CXXMethodDecl
*TypeSystemClang::AddMethodToCXXRecordType(
cxx_ctor_decl->setType(method_qual_type);
cxx_ctor_decl->setImplicit(is_artificial);
cxx_ctor_decl->setInlineSpecified(is_inline);
-cxx_ctor_decl->setConstexprKind(CSK_unspecified);
+cxx_ctor_decl->setConstexprKind(ConstexprSpecKind::Unspecified);
cxx_ctor_decl->setNumCtorInitializers(0);
cxx_ctor_decl->setExplicitSpecifier(explicit_spec);
cxx_method_decl = cxx_ctor_decl;
@@ -7463,7 +7464,7 @@ clang::CXXMethodDecl
*TypeSystemClang::AddMethodToCXXRecordType(
cxx_method_decl->setType(method_qual_type);
cxx_method_decl->setStorageClass(SC);
cxx_method_decl->setInlineSpecified(is_inline);
-cxx_method_decl->setConstexprKind(CSK_unspecified);
+cxx_method_decl->setConstexprKind(ConstexprSpecKind::Unspecified);
} else if (num_params == 0) {
// Conversion operators don't take params...
auto *cxx_conversion_decl =
@@ -7476,7 +7477,7 @@ clang::CXXMethodDecl
*TypeSystemClang::AddMethodToCXXRecordType(
cxx_conversion_decl->setType(method_qual_type);
cxx_conversion_decl->setInlineSpecified(is_inline);
cxx_conversion_decl->setExplicitSpecifier(explicit_spec);
-cxx_conversion_decl->setConstexprKind(CSK_unspecified);
+cxx_conversion_decl->setConstexprKind(ConstexprSpecKind::Unspecified);
cxx_method_decl = cxx_conversion_decl;
}
}
@@ -7489,7 +7490,7 @@ clang::CXXMethodDecl
*TypeSystemClang::AddMethodToCXXRecordType(
cxx_method_decl->setType(method_qual_type);
cxx_method_decl->setInlineSpecified(is_inline);
cxx_method_decl->setStorageClass(SC);
- cxx_method_decl->setConstexprKind(CSK_unspecified);
+ cxx_method_decl->setConstexprKind(ConstexprSpecKind::Unspecified);
}
}
SetMemberOwningModule(cxx_method_decl, cxx_record_decl);
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D67774: [Mangle] Add flag to asm labels to disable '\01' prefixing
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 a case for a diagnostic > > or not. Note the generated assembly in: https://godbolt.org/z/HFfPs6 > > Interesting. I'm glad we do something reasonable, but it's probably best not > to call this supported behavior. > > > > > > Is this bug occurring with real code, or > > > > > is LLDB constructing something bizarre? > > > > > > > > It was a c-reduced test case that we found when doing AST dumping to > > > > JSON, so I think the code was probably real at one point. > > > > > > Unless your reducer is smart enough to try to minimize string > > > literals, which it might be. > > > > Also possible. Regardless, a failed assertion isn't a good outcome. > > Yeah, agreed. In general, allowing empty symbol names seems like it's > just unnecessarily courting all sorts of weird corner cases like this. > > > If we think it's fine to diagnose empty labels, I'm fine with the change. > > I don't know enough about how asm labels are used to have a feeling > > for the correct way to resolve the issue. > > If GCC isn't doing anything reasonable on empty labels, let's just call them > ill-formed and wash our hands of it. Okay, that works for me. Thank you for the guidance (several others agreed on IRC as well)! I'll put together a patch for this shortly. ~Aaron > > John. ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D67774: [Mangle] Add flag to asm labels to disable '\01' prefixing
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 review, but I recently ran into a bug in this > > > > area and am not certain of how to fix it. What should happen if the asm > > > > label is a literal which is empty? > > > > > > The problems here are unique to empty labels, right? > > > > To the best of my knowledge, yes. > > > > > Can we just > > > diagnose this as an error? > > > > I don't think so -- GCC's function attribute documentation seems to > > suggest you should do this with noinline functions (see the docs for > > noinline here > > https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes) > > That's an assembly statement, not a label. Oh! Good catch! 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 a case for a diagnostic or not. Note the generated assembly in: https://godbolt.org/z/HFfPs6 > > > Is this bug occurring with real code, or > > > is LLDB constructing something bizarre? > > > > It was a c-reduced test case that we found when doing AST dumping to > > JSON, so I think the code was probably real at one point. > > Unless your reducer is smart enough to try to minimize string > literals, which it might be. Also possible. Regardless, a failed assertion isn't a good outcome. If we think it's fine to diagnose empty labels, I'm fine with the change. I don't know enough about how asm labels are used to have a feeling for the correct way to resolve the issue. ~Aaron > > John. ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D67774: [Mangle] Add flag to asm labels to disable '\01' prefixing
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.
> > +if (!ALA->getIsLiteralLabel() || ALA->getLabel().startswith("llvm.")) {
> > + Out << ALA->getLabel();
> >
> > Sorry to dredge up an old review, but I recently ran into a bug in this
> > area and am not certain of how to fix it. What should happen if the asm
> > label is a literal which is empty?
>
> The problems here are unique to empty labels, right?
To the best of my knowledge, yes.
> Can we just
> diagnose this as an error?
I don't think so -- GCC's function attribute documentation seems to
suggest you should do this with noinline functions (see the docs for
noinline here
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes)
> Is this bug occurring with real code, or
> is LLDB constructing something bizarre?
It was a c-reduced test case that we found when doing AST dumping to
JSON, so I think the code was probably real at one point. Our reduced
test case wound up as:
void a() __asm__("");
void a();
with clang -cc1 -ast-dump=json causing a failed assertion in LLVM's
mangler (called from Clang's mangler).
~Aaron
>
> John.
> ___
> cfe-commits mailing list
> cfe-comm...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r319694 - Switch from C++1z to C++17; corresponds to r319688 in Clang.
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: lldb/trunk/source/Plugins/Language/CPlusPlus/CPlusPlusNameParser.cpp URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Language/CPlusPlus/CPlusPlusNameParser.cpp?rev=319694&r1=319693&r2=319694&view=diff == --- lldb/trunk/source/Plugins/Language/CPlusPlus/CPlusPlusNameParser.cpp (original) +++ lldb/trunk/source/Plugins/Language/CPlusPlus/CPlusPlusNameParser.cpp Mon Dec 4 12:46:43 2017 @@ -628,7 +628,7 @@ static const clang::LangOptions &GetLang g_options.CPlusPlus = true; g_options.CPlusPlus11 = true; g_options.CPlusPlus14 = true; -g_options.CPlusPlus1z = true; +g_options.CPlusPlus17 = true; }); return g_options; } ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] Buildbot numbers for the week of 9/25/2016 - 10/1/2016
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 entirely? It has never been green (to the best of my knowledge). I know some folks have tried fixing it before, but it seems to have not worked out. http://lab.llvm.org:8011/builders/clang-tools-sphinx-docs/builds/624/steps/docs-clang-tools-html/logs/stdio The builder continually fails with "ninja: error: unknown target 'docs-clang-tools-html'". ~Aaron > > The longest time each builder was red during the last week; > "Status change ratio" by active builder (percent of builds that changed the > builder status from greed to red or from red to green); > Count of commits by project; > Number of completed builds, failed builds and average build time for > successful builds per active builder; > Average waiting time for a revision to get build result per active builder > (response time). > > Thanks > > Galina > > > The longest time each builder was red during the last week: > > buildername| was_red > +--- > clang-cmake-mipsel | 113:03:59 > clang-cmake-mips | 89:43:33 > libomp-ompt-clang-x86_64-linux-debian | 72:01:30 > sanitizer-x86_64-linux | 69:51:49 > clang-cmake-aarch64-quick | 50:18:34 > clang-x86-windows-msvc2015 | 50:07:13 > lldb-x86_64-ubuntu-14.04-cmake | 35:07:56 > clang-ppc64le-linux-multistage | 26:40:23 > clang-sphinx-docs | 16:57:01 > lldb-windows7-android | 15:52:05 > sanitizer-ppc64be-linux| 15:05:26 > sanitizer-ppc64le-linux| 13:56:02 > clang-x86-win2008-selfhost | 13:55:23 > lldb-x86_64-darwin-13.4| 13:21:14 > lldb-x86_64-ubuntu-14.04-android | 12:34:33 > clang-x64-ninja-win7 | 11:24:55 > sanitizer-windows | 11:01:58 > lld-x86_64-win7| 11:00:28 > llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast | 10:44:15 > clang-cmake-thumbv7-a15-full-sh| 09:54:20 > clang-cmake-armv7-a15-selfhost-neon| 07:15:43 > libcxx-libcxxabi-libunwind-arm-linux | 06:41:17 > sanitizer-x86_64-linux-autoconf| 06:39:25 > clang-cmake-thumbv7-a15| 06:30:16 > clang-cmake-armv7-a15 | 06:30:16 > clang-cmake-armv7-a15-full | 06:26:04 > clang-cmake-aarch64-full | 06:15:53 > clang-cmake-armv7-a15-selfhost | 06:11:34 > libcxx-libcxxabi-libunwind-arm-linux-noexceptions | 04:02:06 > clang-with-lto-ubuntu | 03:46:36 > llvm-sphinx-docs | 03:34:07 > sanitizer-x86_64-linux-bootstrap | 03:03:14 > llvm-mips-linux| 02:42:20 > clang-ppc64be-linux| 02:41:21 > clang-hexagon-elf | 02:40:45 > clang-s390x-linux | 02:38:57 > clang-ppc64be-linux-multistage | 02:31:40 > clang-ppc64be-linux-lnt| 02:29:47 > clang-ppc64le-linux-lnt| 02:24:52 > clang-ppc64le-linux| 02:20:39 > clang-native-arm-lnt | 02:19:37 > clang-cmake-aarch64-42vma | 02:11:32 > lld-x86_64-darwin13| 02:10:32 > sanitizer-x86_64-linux-fast| 02:09:59 > clang-x86_64-linux-selfhost-modules| 01:59:26 > libcxx-libcxxabi-x86_64-linux-ubuntu-tsan | 01:47:24 > libcxx-libcxxabi-singlethreaded-x86_64-linux-debian| 01:40:28 > libcxx-libcxxabi-x86_64-linux-ubuntu-msan | 01:36:45 > clang-x86_64-debian-fast | 01:33:12 > clang-cuda-build | 01:31:56 > clang-bpf-bui
Re: [Lldb-commits] Buildbot numbers for the week of 7/10/2016 - 7/16/2016
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 ratio" by active builder (percent of builds that changed the > builder status from greed to red or from red to green); > Count of commits by project; > Number of completed builds, failed builds and average build time for > successful builds per active builder; > Average waiting time for a revision to get build result per active builder > (response time); > > Thanks > > Galina > > > The longest time each builder was red during the last week: > > buildername| was_red > +--- > clang-sphinx-docs | 122:54:15 I am not certain that this builder is sending out emails when it goes red. Since this builds with warnings as errors, I think the builder should be sending out notifications so we hopefully don't run into this again. Any warning means we leave outdated documentation on the public website. Either that, or we should disable treating warnings as errors (which I don't think is a good idea, and would prefer to avoid). Same goes for the other sphinx bots (llvm & lld were both red this week, repeatedly, as well). ~Aaron > sanitizer-x86_64-linux-fuzzer | 58:12:52 > perf-x86_64-penryn-O3-polly-before-vectorizer | 39:52:18 > clang-native-aarch64-full | 31:59:05 > sanitizer-x86_64-linux-bootstrap | 27:37:36 > perf-x86_64-penryn-O3-polly-before-vectorizer-unprofitable | 25:34:19 > clang-cmake-armv7-a15-selfhost | 24:00:48 > clang-x86_64-linux-selfhost-modules| 23:57:52 > polly-amd64-linux | 23:29:30 > clang-cmake-thumbv7-a15-full-sh| 23:23:52 > lldb-windows7-android | 22:15:39 > clang-cmake-aarch64-quick | 21:54:32 > clang-3stage-ubuntu| 21:39:52 > clang-x86-win2008-selfhost | 19:02:47 > perf-x86_64-penryn-O3-polly-unprofitable | 18:50:41 > perf-x86_64-penryn-O3 | 18:03:53 > clang-x64-ninja-win7 | 17:19:40 > lldb-x86_64-ubuntu-14.04-android | 17:09:21 > clang-cmake-armv7-a15-selfhost-neon| 16:35:10 > perf-x86_64-penryn-O3-polly-before-vectorizer-detect-only | 16:34:08 > clang-cmake-aarch64-full | 16:11:16 > clang-native-arm-lnt | 16:00:43 > lldb-x86_64-ubuntu-14.04-cmake | 13:02:12 > clang-ppc64be-linux-multistage | 11:36:28 > sanitizer-x86_64-linux-fast| 10:24:56 > perf-x86_64-penryn-O3-polly-fast | 10:22:11 > sanitizer-x86_64-linux | 09:52:43 > clang-cmake-mipsel | 09:38:52 > clang-atom-d525-fedora-rel | 09:33:56 > perf-x86_64-penryn-O3-polly| 08:11:16 > clang-ppc64le-linux-multistage | 06:07:25 > sanitizer-ppc64le-linux| 04:21:05 > llvm-clang-lld-x86_64-debian-fast | 04:16:01 > clang-cuda-build | 04:13:46 > clang-x86_64-debian-fast | 04:11:41 > llvm-mips-linux| 04:01:44 > llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast | 04:01:03 > clang-ppc64le-linux-lnt| 04:00:27 > clang-s390x-linux | 03:50:24 > clang-ppc64be-linux| 03:46:53 > clang-ppc64be-linux-lnt| 03:46:29 > perf-x86_64-penryn-O3-polly-parallel-fast | 03:46:14 > lld-x86_64-freebsd | 03:39:34 > sanitizer-windows | 03:32:27 > lld-x86_64-darwin13| 03:27:07 > llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast | 03:23:57 > lld-x86_64-win7| 03:22:32 > clang-cmake-aarch64-42vma | 03:20:10 > clang-ppc64le-linux| 03:00:31 > clang-
Re: [Lldb-commits] Some buildbot statistics for the last week
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 it. Thank you for tracking and reporting this information, that's fantastic! > > All the numbers are for the week of 11/8/2015 - 11/14/2015. > > Thanks > > Galina > > > > Number of commits by project: > > project | commits > - > llvm | 286 > cfe | 109 > lldb |76 > compiler-rt |71 > polly|42 > lld |38 > libcxx |10 > openmp | 9 > clang-tools-extra| 7 > clang-tests-external | 2 > libunwind| 1 > - > 651 > > > Number of completed builds, failed builds and average build time for > successful builds per active builder: > > buildername | completed | > failed | time > - > clang-aarch64-lnt | 57 | > 3 | 02:30:12 > clang-atom-d525-fedora| 18 | > | 08:28:15 > clang-atom-d525-fedora-rel| 83 | > 5 | 01:29:55 > clang-bpf-build |310 | > 31 | 00:02:53 > clang-cmake-aarch64-42vma |278 | > 49 | 00:16:47 > clang-cmake-aarch64-quick |209 | > 29 | 00:23:46 > clang-cmake-armv7-a15 |189 | > 8 | 00:25:27 > clang-cmake-armv7-a15-full|154 | > 38 | 00:45:32 > clang-cmake-armv7-a15-selfhost| 58 | > 24 | 03:00:19 > clang-cmake-armv7-a15-selfhost-neon | 45 | > 22 | 04:26:31 > clang-cmake-mips |186 | > 38 | 00:28:52 > clang-cmake-thumbv7-a15 |178 | > 7 | 00:28:30 > clang-cmake-thumbv7-a15-full-sh | 32 | > 23 | 06:03:05 > clang-hexagon-elf |169 | > 23 | 00:24:42 > clang-native-aarch64-full | 24 | > 8 | 05:53:35 > clang-native-arm-lnt | 90 | > 3 | 01:06:01 > clang-native-arm-lnt-perf | 14 | > | 08:57:04 > clang-ppc64-elf-linux |120 | > 6 | 01:01:02 > clang-ppc64-elf-linux2| 89 | > 24 | 01:29:49 > clang-sphinx-docs |113 | > | 00:00:20 > clang-x64-ninja-win7 |285 | > 58 | 00:09:49 > clang-x86-win2008-selfhost|268 | > 46 | 00:12:10 > clang-x86_64-darwin13-cross-arm |232 | > 1 | 00:19:45 > clang-x86_64-darwin13-cross-mingw32 |217 | > 12 | 00:23:20 > clang-x86_64-debian-fast |147 | > 12 | 00:11:37 > clang-x86_64-linux-abi-test |314 | > 1 | 00:18:39 > clang-x86_64-linux-selfhost-modules |261 | > 25 | 00:15:02 > clang-x86_64-ubuntu-gdb-75|124 | > 62 | 00:53:12 > libcxx-libcxxabi-arm-linux| 8 | > | 01:05:10 > libcxx-libcxxabi-singlethreaded-x86_64-linux-debian | 11 | > 2 | 00:08:50 > libcxx-libcxxabi-x86_64-linux-debian | 11 | > 4 | 00:09:43 > libcxx-libcxxabi-x86_64-linux-debian-noexceptions | 5 | > 2 | 00:09:24 > libcxx-libcxxabi-x86_64-linux-ubuntu-asan | 10 | > 2 | 00:08:22 > libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03| 10 | > | 00:05:12 > libcxx-libcxxabi-x86_64-linux-ubuntu-cxx11| 10 | > | 00:06:19 > libcxx-libcxxabi-x86_64-linux-ubuntu-cxx14| 9 | > | 00:06:56 > libcxx-libcxxabi-x86_64-linux-ubuntu-cxx1z| 10 | > 2 | 00:06:06 > libcxx-libcxxabi-x86_64-linux-ubuntu-msan | 10 | > 2 | 00:17:00 > libcxx-libcxxabi-x86_64-linux-ubuntu-tsan
