[llvm-bugs] [Bug 38876] New: Suppressing -Wduplicate-enum via pragma is less intuitive than it should be
via llvm-bugs
llvm-bugs at lists.llvm.org
Fri Sep 7 18:10:07 PDT 2018
https://bugs.llvm.org/show_bug.cgi?id=38876
Bug ID: 38876
Summary: Suppressing -Wduplicate-enum via pragma is less
intuitive than it should be
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangbugs at nondot.org
Reporter: arthur.j.odwyer at gmail.com
CC: llvm-bugs at lists.llvm.org
Inspired by discussion of duplicated enum values in
https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/mpGmQBP4AqI
, I decided to play around with -Wduplicate-enum.
cat >test.cc <<EOF
enum Ranges {
CategoryX = 100,
X1 = CategoryX,
X2,
X3,
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wduplicate-enum"
DeprecatedNameX1 = X1,
DeprecatedNameX2,
DeprecatedNameX3,
#pragma clang diagnostic pop
};
EOF
clang++ -std=c++17 -Wduplicate-enum test.cc
The duplicate-enum warning for the pair (X2, DeprecatedNameX2) is still
printed.
The duplicate-enum warning for the pair (X3, DeprecatedNameX3) is still
printed.
However, if I change my code to:
cat >fixed.cc <<EOF
enum Ranges {
CategoryX = 100,
X1 = CategoryX,
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wduplicate-enum"
X2,
X3,
#pragma clang diagnostic pop
DeprecatedNameX1 = X1,
DeprecatedNameX2,
DeprecatedNameX3,
};
EOF
clang++ -std=c++17 -Wduplicate-enum fixed.cc
then the duplicate-enum warnings are both suppressed as I'd intended.
But this is highly counter-intuitive pragma placement! I don't want to turn off
-Wduplicate-enum for the *original* X2 and X3; I want to suppress
-Wduplicate-enum warnings specifically for the *duplicates*, DeprecatedNameX2
and DeprecatedNameX3.
Ideally, I'd like my "test.cc" to continue to get warnings for duplicates of X2
*other than* DeprecatedNameX2.
At a bare minimum, I'd like my "test.cc" to compile without warnings (i.e.,
Clang should check the position of the note as well as the position of the
warning, when deciding whether to emit each diagnostic).
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20180908/508c210c/attachment-0001.html>
More information about the llvm-bugs
mailing list