llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder
`premerge-monolithic-windows` running on `premerge-windows-1` while building
`clang` at step 5 "clean-build-dir".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/35/builds/3580
Here is the relevant pi
TomWeaver18 wrote:
Thanks for the revert 👍
https://github.com/llvm/llvm-project/pull/115854
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder
`libc-x86_64-debian-dbg-asan` running on `libc-x86_64-debian` while building
`clang` at step 4 "annotate".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/147/builds/9775
Here is the relevant piece of
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder
`clang-cmake-x86_64-avx512-linux` running on `avx512-intel64` while building
`clang` at step 7 "ninja check 1".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/133/builds/6658
Here is the relevant pie
https://github.com/ChuanqiXu9 closed
https://github.com/llvm/llvm-project/pull/106683
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
ChuanqiXu9 wrote:
Thank you very much !
https://github.com/llvm/llvm-project/pull/106683
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder
`libc-aarch64-ubuntu-fullbuild-dbg` running on `libc-aarch64-ubuntu` while
building `clang-tools-extra` at step 4 "annotate".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/71/builds/10350
Here is th
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `clang-debian-cpp20`
running on `clang-debian-cpp20` while building `clang` at step 6
"test-build-unified-tree-check-all".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/108/builds/5850
Here is the r
https://github.com/davemgreen approved this pull request.
Sounds like a good idea to me if no-one else objects. LGTM
https://github.com/llvm/llvm-project/pull/115818
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin
Michael137 wrote:
FYI, looks like this is causing following LLDB builds to fail:
https://green.lab.llvm.org/job/llvm.org/view/LLDB/job/as-lldb-cmake/15106/execution/node/97/log/
```
Unresolved Tests (17):
lldb-api ::
commands/expression/import-std-module/array/TestArrayFromStdModule.py
lldb
https://github.com/jthackray approved this pull request.
Fine by me; I guess anyone with a PR in-flight will need to rebase.
https://github.com/llvm/llvm-project/pull/115818
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org
cor3ntin wrote:
Does this work with an explicit object member function?
https://github.com/llvm/llvm-project/pull/115880
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jurahul updated
https://github.com/llvm/llvm-project/pull/115573
>From 635b24a4e057d85de6c2935ed817b93b34916ed3 Mon Sep 17 00:00:00 2001
From: Rahul Joshi
Date: Fri, 8 Nov 2024 16:04:53 -0800
Subject: [PATCH] [NFC][Clang] Use range for loops in ClangDiagnosticsEmitter
Use ra
@@ -468,11 +442,9 @@ static StringRef getModifierName(ModifierType MT) {
return "objcclass";
case MT_ObjCInstance:
return "objcinstance";
- case MT_Unknown:
+ default:
jurahul wrote:
Done now.
https://github.com/llvm/llvm-project/pull/115573
_
@@ -1553,15 +1526,13 @@ static void emitDiagSubGroups(std::map &DiagsInGroup,
RecordVec &GroupsInPedantic, raw_ostream &OS) {
OS << "static const int16_t DiagSubGroups[] = {\n"
<< " /* Empty */ -1,\n";
- for (auto const &I : DiagsInGroup)
preames wrote:
I am not sue about the acceptance of the "tt" naming here given we use full
names for all other vendors in this context. Can you raise that point
specifically at the next RISCV sync up call for discussion?
https://github.com/llvm/llvm-project/pull/115100
_
https://github.com/jroelofs approved this pull request.
https://github.com/llvm/llvm-project/pull/113281
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Balazs Benics
Date: 2024-11-12T16:23:57+01:00
New Revision: 469520ed9acc1308a492d03cf859703054a61730
URL:
https://github.com/llvm/llvm-project/commit/469520ed9acc1308a492d03cf859703054a61730
DIFF:
https://github.com/llvm/llvm-project/commit/469520ed9acc1308a492d03cf859703054a61730.diff
https://github.com/a-tarasyuk updated
https://github.com/llvm/llvm-project/pull/115786
>From da1b3982e84114cb1214ca5c3d8ed520d1589b83 Mon Sep 17 00:00:00 2001
From: Oleksandr T
Date: Tue, 12 Nov 2024 00:59:37 +0200
Subject: [PATCH 1/5] [Clang] enhance diagnostic by attaching source location
to
https://github.com/steakhal updated
https://github.com/llvm/llvm-project/pull/115884
>From 7c20b117b8cad0fa5b999c86f507d9356e8b41de Mon Sep 17 00:00:00 2001
From: Balazs Benics
Date: Sat, 9 Nov 2024 15:55:08 +0100
Subject: [PATCH 1/3] [analyzer][NFC] Make RegionStore dumps deterministic
Dump t
nikic wrote:
> so
> [12e3ed8](https://github.com/llvm/llvm-project/commit/12e3ed8de8c6063b15916b3faf67c8c9cd17df1f)
> should resolve both lldb buildbot breakage and compile time regression in
> clang.
Thank you, I can confirm that this fixes the compile-time regression (or at
least most of i
jroelofs wrote:
At the very least, the fixit shouldn't be recommending precisely what the user
wrote, which funnily enough, gcc also gets wrong:
https://clang.godbolt.org/z/88sqM5xET
https://github.com/llvm/llvm-project/pull/74440
___
cfe-commits mai
tbaederr wrote:
@MitalAshok Want to merge this?
https://github.com/llvm/llvm-project/pull/108758
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -316,36 +295,187 @@ llvm::Error buildModuleFile(llvm::StringRef ModuleName,
if (Clang->getDiagnostics().hasErrorOccurred())
return llvm::createStringError("Compilation failed");
- BuiltModuleFiles.addModuleFile(ModuleName, Inputs.CompileCommand.Output);
- return llv
@@ -0,0 +1,38 @@
+#include
+#include
+#include
+
+#define CLC_SIGN(TYPE, F)
\
+ _CLC_DEF _CLC_OVERLOAD TYPE __clc_sign(TYPE x) {
\
+if (__clc_isnan(x)) {
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder
`sanitizer-x86_64-linux-fast` running on `sanitizer-buildbot4` while building
`clang` at step 2 "annotate".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/169/builds/5220
Here is the relevant piece o
@@ -8341,6 +8341,11 @@ void Sema::CheckShadow(NamedDecl *D, NamedDecl
*ShadowedDecl,
// shadowing context, but that's just a false negative.
}
+ // Skip shadowing check if we're in a class scope, dealing with an enum
+ // constant in a different context.
+ if (S->isC
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder
`clang-ppc64le-linux-multistage` running on `ppc64le-clang-multistage-test`
while building `clang` at step 5 "ninja check 1".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/76/builds/
Here is the
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `arc-builder` running on
`arc-worker` while building `clang` at step 6
"test-build-unified-tree-check-all".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/3/builds/7495
Here is the relevant piece of
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder
`clang-ppc64le-linux-test-suite` running on `ppc64le-clang-test-suite` while
building `clang` at step 6 "test-build-unified-tree-check-all".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/95/builds/611
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `premerge-monolithic-linux`
running on `premerge-linux-1` while building `clang` at step 7
"test-build-unified-tree-check-all".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/153/builds/14381
Here is
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder
`ppc64le-lld-multistage-test` running on `ppc64le-lld-multistage-test` while
building `clang` at step 7 "test-build-stage1-unified-tree-check-all".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/168/bu
NagyDonat wrote:
The array-based solution can be extended to cover more than two separate cache
sets by replacing the `bool` with a suitable enum (or a bitfield where
independent flags are combined by bitwise or). It will stay more effective than
the "use a single set and store 3-tuples instea
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `clang-ppc64le-rhel`
running on `ppc64le-clang-rhel-test` while building `clang` at step 7
"test-build-unified-tree-check-all".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/145/builds/3119
Here is
@@ -1553,15 +1526,13 @@ static void emitDiagSubGroups(std::map &DiagsInGroup,
RecordVec &GroupsInPedantic, raw_ostream &OS) {
OS << "static const int16_t DiagSubGroups[] = {\n"
<< " /* Empty */ -1,\n";
- for (auto const &I : DiagsInGroup)
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `clang-x64-windows-msvc`
running on `windows-gcebot2` while building `clang` at step 4 "annotate".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/63/builds/2548
Here is the relevant piece of the build
@@ -970,10 +942,11 @@ struct DiagTextPrinter : DiagTextVisitor
{
void VisitPlural(PluralPiece *P) {
Result += "%plural{";
assert(P->Options.size() == P->OptionPrefixes.size());
-for (unsigned I = 0, End = P->Options.size(); I < End; ++I) {
- if (P->OptionPre
Author: Alexandros Lamprineas
Date: 2024-11-12T16:01:35Z
New Revision: 3cc852ece438a63e7b09d1c84a81d21598454e1a
URL:
https://github.com/llvm/llvm-project/commit/3cc852ece438a63e7b09d1c84a81d21598454e1a
DIFF:
https://github.com/llvm/llvm-project/commit/3cc852ece438a63e7b09d1c84a81d21598454e1a.di
https://github.com/labrinea closed
https://github.com/llvm/llvm-project/pull/113281
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -4887,9 +4887,18 @@ static TypeSourceInfo
*GetFullTypeForDeclarator(TypeProcessingState &state,
cast(T)->getKeyword() !=
AutoTypeKeyword::Auto ||
cast(T)->isConstrained())) {
-S.Diag(D.getDecl
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `reverse-iteration` running
on `hexagon-build-03` while building `clang` at step 6 "check_all".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/110/builds/2271
Here is the relevant piece of the build l
@@ -1553,15 +1526,13 @@ static void emitDiagSubGroups(std::map &DiagsInGroup,
RecordVec &GroupsInPedantic, raw_ostream &OS) {
OS << "static const int16_t DiagSubGroups[] = {\n"
<< " /* Empty */ -1,\n";
- for (auto const &I : DiagsInGroup)
https://github.com/jurahul edited
https://github.com/llvm/llvm-project/pull/115573
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tarunprabhu wrote:
Thank you all for the reviews.
https://github.com/llvm/llvm-project/pull/109165
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1553,15 +1526,13 @@ static void emitDiagSubGroups(std::map &DiagsInGroup,
RecordVec &GroupsInPedantic, raw_ostream &OS) {
OS << "static const int16_t DiagSubGroups[] = {\n"
<< " /* Empty */ -1,\n";
- for (auto const &I : DiagsInGroup)
https://github.com/arsenm approved this pull request.
https://github.com/llvm/llvm-project/pull/115885
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/a-tarasyuk updated
https://github.com/llvm/llvm-project/pull/115786
>From da1b3982e84114cb1214ca5c3d8ed520d1589b83 Mon Sep 17 00:00:00 2001
From: Oleksandr T
Date: Tue, 12 Nov 2024 00:59:37 +0200
Subject: [PATCH 1/3] [Clang] enhance diagnostic by attaching source location
to
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff 5dd9867e2d1e698fee980e31da114a37e4c7f612
0aa5ab4815abb8d6f45666d821738b244d3e7efa --e
https://github.com/a-tarasyuk updated
https://github.com/llvm/llvm-project/pull/115786
>From da1b3982e84114cb1214ca5c3d8ed520d1589b83 Mon Sep 17 00:00:00 2001
From: Oleksandr T
Date: Tue, 12 Nov 2024 00:59:37 +0200
Subject: [PATCH 1/4] [Clang] enhance diagnostic by attaching source location
to
@@ -4887,9 +4887,18 @@ static TypeSourceInfo
*GetFullTypeForDeclarator(TypeProcessingState &state,
cast(T)->getKeyword() !=
AutoTypeKeyword::Auto ||
cast(T)->isConstrained())) {
-S.Diag(D.getDecl
labrinea wrote:
I've left out the bf16 and i8mm dependencies fixup as they deserve a separate
patch. I will be merging this until the end of today if no one objects.
https://github.com/llvm/llvm-project/pull/113281
___
cfe-commits mailing list
cfe-com
https://github.com/phoebewang approved this pull request.
Looks reasonable given
https://github.com/llvm/llvm-project/commit/a2d309912a2863dfe7286ffde67b968e8c720b07
is for ifunc only.
https://github.com/llvm/llvm-project/pull/115762
___
cfe-commits
AaronBallman wrote:
> I agree in general that C/C++ has no semantic meaning ascribed to address
> spaces.
Err, C does. Please see TR 18037
(https://standards.iso.org/ittf/PubliclyAvailableStandards/c051126_ISO_IEC_TR_18037_2008.zip)
AIUI, we've extended the C extension into C++, so we should
kadircet wrote:
> FYI, looks like this is causing following LLDB tests to fail:
> https://green.lab.llvm.org/job/llvm.org/view/LLDB/job/as-lldb-cmake/15106/execution/node/97/log/
>
> ```
> Unresolved Tests (17):
> lldb-api ::
> commands/expression/import-std-module/array/TestArrayFromStdModu
https://github.com/erichkeane approved this pull request.
https://github.com/llvm/llvm-project/pull/115568
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
> > I agree in general that C/C++ has no semantic meaning ascribed to address
> > spaces.
>
> Err, C does. Please see TR 18037
> (https://standards.iso.org/ittf/PubliclyAvailableStandards/c051126_ISO_IEC_TR_18037_2008.zip)
>
> AIUI, we've extended the C extension into C++, so w
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder
`libc-x86_64-debian-fullbuild-dbg-asan` running on
`libc-x86_64-debian-fullbuild` while building `clang-tools-extra` at step 4
"annotate".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/171/builds/101
Author: SahilPatidar
Date: 2024-11-12T16:51:25+05:30
New Revision: ebb3508899c3e1773884cf5bc1b1df6f32450ca9
URL:
https://github.com/llvm/llvm-project/commit/ebb3508899c3e1773884cf5bc1b1df6f32450ca9
DIFF:
https://github.com/llvm/llvm-project/commit/ebb3508899c3e1773884cf5bc1b1df6f32450ca9.diff
https://github.com/SahilPatidar closed
https://github.com/llvm/llvm-project/pull/115854
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
vgvassilev wrote:
> Ah, so it isn't failing only for me. Apparently, it blows away all the
> environments where ORC is deliberately disabled.
We probably need a `host-supports-oop-jit` similar to what we have in
`host-supports-jit`...
https://github.com/llvm/llvm-project/pull/110418
_
https://github.com/vabridgers edited
https://github.com/llvm/llvm-project/pull/115791
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ElvinaYakubova updated
https://github.com/llvm/llvm-project/pull/115467
>From 8453bd11fa366b4865dce64b55d2a548c8b74a42 Mon Sep 17 00:00:00 2001
From: Elvina Yakubova
Date: Fri, 8 Nov 2024 03:11:44 -0800
Subject: [PATCH 1/2] Reland [clang][AArch64] Add getHostCPUFeatures to qu
@@ -210,6 +210,9 @@ def have_host_clang_repl_cuda():
config.substitutions.append(("%host_cc", config.host_cc))
config.substitutions.append(("%host_cxx", config.host_cxx))
+# Determine whether the test target is compatible with execution on the host.
+if config.host_arch in con
https://github.com/kadircet created
https://github.com/llvm/llvm-project/pull/115852
Starting with 41e3919ded78d8870f7c95e9181c7f7e29aa3cc4 DiagnosticsEngine
creation might perform IO. It was implicitly defaulting to
getRealFileSystem. This patch makes it explicit by pushing the decision
making
pawosm-arm wrote:
Ah, so it isn't failing only for me. Apparently, it blows away all the
environments where ORC is deliberately disabled.
https://github.com/llvm/llvm-project/pull/110418
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://
llvmbot wrote:
@llvm/pr-subscribers-clangd
@llvm/pr-subscribers-clang-driver
Author: kadir çetinkaya (kadircet)
Changes
Starting with 41e3919ded78d8870f7c95e9181c7f7e29aa3cc4 DiagnosticsEngine
creation might perform IO. It was implicitly defaulting to
getRealFileSystem. This patch makes it
https://github.com/Fznamznon approved this pull request.
https://github.com/llvm/llvm-project/pull/115648
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
nikic wrote:
It looks like this increases time to build clang by 0.5% (see affected files
here:
https://llvm-compile-time-tracker.com/compare_clang.php?from=e385e0d3e71e17da0b2023f480259c95923707bd&to=41e3919ded78d8870f7c95e9181c7f7e29aa3cc4&stat=instructions%3Au&sortBy=interestingness)
This u
nikic wrote:
Though looking at that file list in more details, this also affects files
outside clang, so I think it might be adding some compile-time overhead that is
only visible on specific workloads. E.g.
`LLVMSupport.dir/UnicodeNameToCodepointGenerated.cpp` has a 4.5% increase.
https://gi
@@ -2331,8 +2332,11 @@ void CGOpenMPRuntime::emitBarrierCall(CodeGenFunction
&CGF, SourceLocation Loc,
auto *OMPRegionInfo =
dyn_cast_or_null(CGF.CapturedStmtInfo);
if (CGF.CGM.getLangOpts().OpenMPIRBuilder) {
-CGF.Builder.restoreIP(OMPBuilder.createBarrier(
-
fzou1 wrote:
> Missing IR test?
Sorry. Added. Thanks.
https://github.com/llvm/llvm-project/pull/115829
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
h-vetinari wrote:
Thanks for the reviews! I don't have the commit bit, so would rely on someone
pushing the button. :)
https://github.com/llvm/llvm-project/pull/115648
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-
https://github.com/skatrak created
https://github.com/llvm/llvm-project/pull/115863
The preprocessor definition used to enable asserts and the one that
`llvm::Error` and `llvm::Expected` use to ensure all created instances are
checked are not the same. By making these checks inside of an `asse
llvmbot wrote:
@llvm/pr-subscribers-clang
@llvm/pr-subscribers-clang-codegen
Author: Sergio Afonso (skatrak)
Changes
The preprocessor definition used to enable asserts and the one that
`llvm::Error` and `llvm::Expected` use to ensure all created instances are
checked are not the same. By
https://github.com/frasercrmck created
https://github.com/llvm/llvm-project/pull/115865
This keeps values in vectors, rather than scalarizing them and then
reconstituting the vector. The builtin is identical to performing a C-style
cast on each element, which is what we were doing by recursive
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `clang-aarch64-sve-vls`
running on `linaro-g3-03` while building `clang` at step 7 "ninja check 1".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/143/builds/3388
Here is the relevant piece of the bui
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder
`clang-aarch64-sve-vla-2stage` running on `linaro-g3-04` while building `clang`
at step 12 "ninja check 2".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/41/builds/3377
Here is the relevant piece of
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `clang-aarch64-sve-vla`
running on `linaro-g3-02` while building `clang` at step 7 "ninja check 1".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/17/builds/3853
Here is the relevant piece of the buil
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/115648
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: h-vetinari
Date: 2024-11-12T08:02:36-05:00
New Revision: e723b10266756eceb79612f28fdd025475795822
URL:
https://github.com/llvm/llvm-project/commit/e723b10266756eceb79612f28fdd025475795822
DIFF:
https://github.com/llvm/llvm-project/commit/e723b10266756eceb79612f28fdd025475795822.diff
LO
https://github.com/AaronBallman commented:
> @AaronBallman merging this to main now. PLMK if you have any concerns, I am
> happy to address them post-submit (or revert if need be)
Sorry, there was a US holiday on Monday and I was mostly out on Friday, so
that's why there was a delay in review.
@@ -0,0 +1,97 @@
+
+Warning suppression mappings
+
+
+.. contents::
+ :local:
+
+Introduction
+
+
+Warning suppression mappings enable users to suppress Clang's diagnostics in a
+per-file granular manner. Enabli
@@ -477,6 +486,136 @@ void DiagnosticsEngine::setSeverityForAll(diag::Flavor
Flavor,
setSeverity(Diag, Map, Loc);
}
+namespace {
+// FIXME: We should isolate the parser from SpecialCaseList and just use it
+// here.
+class WarningsSpecialCaseList : public llvm::SpecialC
@@ -23,10 +23,15 @@
// simpler because a remark can't be promoted to an error.
#include "clang/Basic/AllDiagnostics.h"
#include "clang/Basic/Diagnostic.h"
+#include "clang/Basic/DiagnosticDriver.h"
+#include "clang/Basic/DiagnosticIDs.h"
#include "clang/Basic/DiagnosticOptions
@@ -0,0 +1,97 @@
+
+Warning suppression mappings
+
+
+.. contents::
+ :local:
+
+Introduction
+
+
+Warning suppression mappings enable users to suppress Clang's diagnostics in a
+per-file granular manner. Enabli
@@ -1315,6 +1319,34 @@ with its corresponding `Wno-` option.
Note that when combined with :option:`-w` (which disables all warnings),
disabling all warnings wins.
+.. _warning_suppression_mappings:
+
+Controlling Diagnostics via Suppression Mappings
+^^
@@ -477,6 +486,136 @@ void DiagnosticsEngine::setSeverityForAll(diag::Flavor
Flavor,
setSeverity(Diag, Map, Loc);
}
+namespace {
+// FIXME: We should isolate the parser from SpecialCaseList and just use it
+// here.
+class WarningsSpecialCaseList : public llvm::SpecialC
@@ -555,6 +560,10 @@ class DiagnosticsEngine : public
RefCountedBase {
void *ArgToStringCookie = nullptr;
ArgToStringFnTy ArgToStringFn;
+ /// Whether the diagnostic should be suppressed in FilePath.
+ llvm::unique_function
AaronBallman wrote:
You can
@@ -1315,6 +1319,34 @@ with its corresponding `Wno-` option.
Note that when combined with :option:`-w` (which disables all warnings),
disabling all warnings wins.
+.. _warning_suppression_mappings:
+
+Controlling Diagnostics via Suppression Mappings
+^^
@@ -44,6 +44,7 @@
#include "llvm/ADT/ScopeExit.h"
#include "llvm/ADT/SmallSet.h"
#include "llvm/ADT/StringExtras.h"
+#include "llvm/ADT/StringRef.h"
AaronBallman wrote:
Why is this being added?
https://github.com/llvm/llvm-project/pull/112517
@@ -9017,3 +9017,8 @@ def wasm_opt : Flag<["--"], "wasm-opt">,
Group,
HelpText<"Enable the wasm-opt optimizer (default)">,
MarshallingInfoNegativeFlag>;
+
+def warning_suppression_mappings_EQ : Joined<["--"],
AaronBallman wrote:
This should move elsewher
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/112517
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -8341,6 +8341,11 @@ void Sema::CheckShadow(NamedDecl *D, NamedDecl
*ShadowedDecl,
// shadowing context, but that's just a false negative.
}
+ // Skip shadowing check if we're in a class scope, dealing with an enum
+ // constant in a different context.
+ if (S->isC
https://github.com/steakhal edited
https://github.com/llvm/llvm-project/pull/114835
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder
`sanitizer-x86_64-linux-bootstrap-ubsan` running on `sanitizer-buildbot3` while
building `clang` at step 2 "annotate".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/25/builds/4070
Here is the releva
davemgreen wrote:
You have to go searching in the test output for the aarch64-mcpu-native.c test.
The bots run clang tests separately to llvm, with a lot of verbose output,
which means the test that is failing might not be at the end of the output. It
looks like it still has the same error mes
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `clang-x86_64-debian-fast`
running on `gribozavr4` while building `clang` at step 6
"test-build-unified-tree-check-all".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/56/builds/12003
Here is the rel
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `llvm-x86_64-debian-dylib`
running on `gribozavr4` while building `clang` at step 6
"test-build-unified-tree-check-clang".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/60/builds/12482
Here is the r
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `clang-m68k-linux-cross`
running on `suse-gary-m68k-cross` while building `clang` at step 5 "ninja check
1".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/27/builds/1898
Here is the relevant piece o
Author: kadir çetinkaya
Date: 2024-11-12T10:53:43+01:00
New Revision: 41e3919ded78d8870f7c95e9181c7f7e29aa3cc4
URL:
https://github.com/llvm/llvm-project/commit/41e3919ded78d8870f7c95e9181c7f7e29aa3cc4
DIFF:
https://github.com/llvm/llvm-project/commit/41e3919ded78d8870f7c95e9181c7f7e29aa3cc4.dif
401 - 500 of 529 matches
Mail list logo