Treat typedef enum as named enums instead of anonymous enums. Anonymous enums
are ignored by the warning, so previously, typedef enums were ignored as well.
llvm-svn: 312842
Summary:
This is a first half(?) of a fix for the following bug:
https://bugs.llvm.org/show_bug.cgi?id=34147 (gcc -Wtype-limits)
GCC's -Wtype-limits does warn on comparison of unsigned value
with signed zero (as in, with 0), but clang only warns if the
zero is unsigned (i.e. 0U).
Also, be careful not to double-warn, or falsely warn on
comparison of signed/fp variable and signed 0.
Yes, all these testcases are needed.
Testing: $ ninja check-clang-sema check-clang-semacxx
Also, no new warnings for clang stage-2 build.
Reviewers: rjmccall, rsmith, aaron.ballman
Reviewed By: rjmccall
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D37565
llvm-svn: 312750
This follows the scheme agreed with Nathan Sidwell, which can be found here:
https://gcc.gnu.org/wiki/cxx-modules?action=AttachFile
This will be proposed to the itanium-cxx-abi list once we have some experience
with how well it works; the ABI for this TS should be considered unstable until
it is part of the Itanium C++ ABI.
llvm-svn: 312467
r312167 made it so that we emit Wdelete-non-virtual-dtor from delete statements
that are in system headers (e.g. std::unique_ptr). That works great on Linux
and macOS, but on Windows there are non-final classes that are defined in
system headers that have virtual methods but non-virtual destructors and yet
get deleted through a base class pointer (e.g. ATL::CAccessToken::CRevert). So
paddle back a bit and don't emit the warning if it's about a class defined in a
system header.
https://reviews.llvm.org/D37324
llvm-svn: 312216
Makes the warning useful again in a std::unique_ptr world, PR28460.
Also make the warning not fire in unevaluated contexts, since system libraries
(e.g. libc++) do do that. This would've been a good change before we started
emitting this warning in system headers too, but "normal" code seems to be less
template-heavy, so we didn't notice until now.
https://reviews.llvm.org/D37235
llvm-svn: 312167
The standard is not clear on how these are supposed to be handled, so we
conservatively treat as non-constant any cases whose value is unknown or whose
evaluation might result in undefined behavior.
llvm-svn: 311970
Prior to this patch, clang would do the wrong thing here (see inline comments for pre-patch behavior):
struct A {
void bar(int) { }
static void bar(double) { }
void g(int*);
static void g(char *);
};
struct B {
void f() {
A::bar(3); // selects (double) ??!!
A::g((int*)0); // Instead of no object argument, states conversion error?!!
}
};
The fix is as follows: When we detect that what appears to be an implicit member function call (A::bar) is actually a call to a member of a class (A) unrelated to the type (B) that contains the member function (B::f) from which the call is being made, don't treat it (A::bar) as an Implicit Member Call Expression.
P.S. I wonder if there is an existing bug report related to this? (Surprisingly, a cursory search did not find one).
llvm-svn: 311839
This is the same assertion as in https://reviews.llvm.org/D25206 that is
triggered when RecordLayoutBuilder tries to compute the size of a field
(for capture "typo_boo" in the test case) whose type hasn't been
deduced.
The fix is to add CorrectDelayedTyposInExpr call to the cases when we
aren't disambiguating between an Obj-C message send and a lambda
expression.
rdar://problem/31760839
Reviewers: rsmith, ahatanak
Reviewed By: arphaman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D36853
llvm-svn: 311480
This patch, by hamzasood, implements P0409R2, and allows [=, this] pre-C++2a as an extension (with appropriate warnings) for consistency.
https://reviews.llvm.org/D36572
Thanks Hamza!
llvm-svn: 311224
This reverts commit rL310403, which caused spurious warnings in libc++,
because it didn't properly handle templated scoped lockable types.
llvm-svn: 310698
C++14 added user-defined literal support for complex numbers so that you
can write something like "complex<double> val = 2i". However, there is
an existing GNU extension supporting this syntax and interpreting the
result as a _Complex type.
This changes parsing so that such literals are interpreted in terms of
C++14's operators if an overload is present but otherwise falls back to
the original GNU extension.
(We now have more robust diagnostics for implicit conversions so the
libc++ test that caused the original revert still passes).
llvm-svn: 310478
Do not discard invalid Decl when searching for the operator delete function.
The lookup for this function always expects to find a result, so sometimes the
invalid Decl is the only choice possible. This fixes PR34109.
llvm-svn: 310435
Converting a _Complex type to a real one simply discards the imaginary part.
This can easily lead to loss of information so for safety (and GCC
compatibility) this patch disallows that when the conversion would be implicit.
The one exception is bool, which actually compares both real and imaginary
parts and so is safe.
llvm-svn: 310427
Add warnings in cases where an implicit `this` argument is expected to
attributes because either `this` doesn't exist because the attribute is
on a free function, or because `this` is on a type that doesn't have a
corresponding capability/lockable/scoped_lockable attribute.
Reviewers: delesley, aaron.ballman
Differential Revision: https://reviews.llvm.org/D36237
llvm-svn: 310403
Delete the test that was broken by rL309725, and add it back in a
follow up commit. Also, improve the tests a bit.
Reviewers: delesley, aaron.ballman
Differential Revision: https://reviews.llvm.org/D36237
llvm-svn: 310402
Summary:
Fixes http://llvm.org/PR33947.
https://godbolt.org/g/54XRMT
void f(int a) {
struct A {
void g(int a) {}
A() { int a; }
};
}
3 : <source>:3:16: warning: declaration shadows a local variable [-Wshadow]
void g(int a) {}
^
1 : <source>:1:12: note: previous declaration is here
void f(int a) {
^
4 : <source>:4:15: warning: declaration shadows a local variable [-Wshadow]
A() { int a; }
^
1 : <source>:1:12: note: previous declaration is here
void f(int a) {
^
2 warnings generated.
The local variable `a` of the function `f` can't be accessed from a method of
the function-local class A, thus no shadowing occurs and no diagnostic is
needed.
Reviewers: rnk, rsmith, arphaman, Quuxplusone
Reviewed By: rnk, Quuxplusone
Subscribers: Quuxplusone, cfe-commits
Differential Revision: https://reviews.llvm.org/D35941
llvm-svn: 309569
Summary:
Previously Clang was not considering operator declarations that occur at function scope. This is incorrect according to [over.match.oper]p3
> The set of non-member candidates is the result of the unqualified lookup of operator@ in the context of the expression according to the usual rules for name lookup in unqualified function calls.
This patch changes operator name lookup to consider block scope declarations.
This patch fixes PR27027.
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D35297
llvm-svn: 309530
allocation functions.
This changes the error message Sema prints when an unavailable C++17
aligned allocation function is selected.
Original message: "... possibly unavailable on x86_64-apple-macos10.12"
New message: "... only available on macOS 10.13 or newer"
This is a follow-up to r306722.
rdar://problem/32664169
Differential Revision: https://reviews.llvm.org/D35520
llvm-svn: 308496
Summary: GCC has named this `-Wnoexcept-type`, so let's add an alias to stay compatible with the GCC flags.
Reviewers: rsmith, dexonsmith
Reviewed By: dexonsmith
Subscribers: cfe-commits, karies, v.g.vassilev, ahatanak
Differential Revision: https://reviews.llvm.org/D34439
llvm-svn: 308340
be shared without warnings. Build AttributedTypes to leave breadcrumbs
for tools like the static analyzer. Warn about attempting to use the
attribute with incompatible return types.
llvm-svn: 308092
Summary:
r306137 made dllimport pointers to member functions non-constant. This
is correct because a load must be executed to resolve any dllimported
data. However, r306137 did not account for the use of dllimport member
function pointers used as template arguments.
This change re-lands r306137 with a template instantiation fix.
This fixes PR33570.
Reviewers: rnk, majnemer
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D34714
llvm-svn: 307446
Richard Trieu