Age | Commit message (Collapse) | Author |
|
seems to have intended.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165440 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
functionality changed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165439 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165384 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
GCC has always supported this on PowerPC and 4.8 supports it on all platforms,
so it's a good idea to expose it in clang too. LLVM supports this on all targets.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165362 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
-Wenum-conversion, that is a subgroup of -Wconversion.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165361 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This appears to be consistent with GCC's implementation of the same warning
under -Wparentheses. Suppressing a << b + c for cases where 'a' is a user
defined type for compatibility with C++ stream IO. Otherwise suggest
parentheses around the addition or subtraction subexpression.
(this came up when MSVC was complaining (incorrectly, so far as I can tell)
about a perceived violation of this within the LLVM codebase, PR14001)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165283 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
that are associated with a (sub)module.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165279 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
a non-inline namespace, then reopens it as inline to try to add its symbols to
the surrounding namespace. In this one special case, permit the namespace to be
reopened as inline, and patch up the name lookup tables to match.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165263 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
mess by handling all pragmas which the parser touches uniformly.
<rdar://problem/12248901>, etc.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165195 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165177 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165142 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
that doesn't have a 'self' as this implicitly captures 'self' and could
create retain cycles. Provide fixit. // rdar://11194874
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165133 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
is allowed or ignored with warning. This allows for correct name mangling for x64 targets on Windows, which in turn allows for linking against the Win32 APIs.
Fixes PR13782
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165015 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
allowed
for ARC. Fixes <rdar://problem/12407705>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164990 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
care of comments by Dimitri and Doug.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164957 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164907 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164904 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164873 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
When issuing a diagnostic message for the -Wimplicit-fallthrough diagnostics, always try to find the latest macro, defined at the point of fallthrough, which is immediately expanded to "[[clang::fallthrough]]", and use it's name instead of the actual sequence.
Known issues:
* uses PP.getSpelling() to compare macro definition with a string (anyone can suggest a convenient way to fill a token array, or maybe lex it in runtime?);
* this can be generalized and used in other similar cases, any ideas where it should reside then?
Reviewers: doug.gregor, rsmith
Reviewed By: rsmith
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D50
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164858 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
New output:
warning: weak property may be unpredictably set to nil
note: property declared here
note: assign the value to a strong variable to keep the object alive
during use
<rdar://problem/12277204>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164857 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Like properties, loading from a weak ivar twice in the same function can
give you inconsistent results if the object is deallocated between the
two loads. It is safer to assign to a strong local variable and use that.
Second half of <rdar://problem/12280249>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164855 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The motivating example:
if (self.weakProp)
use(self.weakProp);
As with any non-atomic test-then-use, it is possible a weak property to be
non-nil at the 'if', but be deallocated by the time it is used. The correct
way to write this example is as follows:
id tmp = self.weakProp;
if (tmp)
use(tmp);
The warning is controlled by -Warc-repeated-use-of-receiver, and uses the
property name and base to determine if the same property on the same object
is being accessed multiple times. In cases where the base is more
complicated than just a single Decl (e.g. 'foo.bar.weakProp'), it picks a
Decl for some degree of uniquing and reports the problem under a subflag,
-Warc-maybe-repeated-use-of-receiver. This gives a way to tune the
aggressiveness of the warning for a particular project.
The warning is not on by default because it is not flow-sensitive and thus
may have a higher-than-acceptable rate of false positives, though it is
less noisy than -Wreceiver-is-weak. On the other hand, it will not warn
about some cases that may be legitimate issues that -Wreceiver-is-weak
will catch, and it does not attempt to reason about methods returning weak
values.
Even though this is not a real "analysis-based" check I've put the bug
emission code in AnalysisBasedWarnings for two reasons: (1) to run on
every kind of code body (function, method, block, or lambda), and (2) to
suggest that it may be enhanced by flow-sensitive analysis in the future.
The second (smaller) half of this work is to extend it to weak locals
and weak ivars. This should use most of the same infrastructure.
Part of <rdar://problem/12280249>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164854 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
See: http://en.wikipedia.org/wiki/If_and_only_if Commit 164766
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164769 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164766 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
latest macro definition. Needs more work.
Summary: Passes all tests (+ the new one with code completion), but needs a thorough review in part related to modules.
Reviewers: doug.gregor
Reviewed By: alexfh
CC: cfe-commits, rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D41
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164610 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
specific module (__building_module(modulename)) and to get the name of
the current module as an identifier (__MODULE__).
Used to help headers behave differently when they're being included as
part of building a module. Oh, the irony.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164605 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Patch by Andy Gibbs!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164591 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Patch by Andy Gibbs!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164590 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
to the feature.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164566 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
'instance variable' in text of all diagnostics
for objective-C: // rdar://12352442
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164559 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164551 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
silenced by -Wno-long-long. Thanks Richard Smith for the fix idea!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164546 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
> 'long long' is an extension when C99 mode is not enabled
to
> 'long long' is a C++11 extension
while compiling in C++98 mode.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164545 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
deprecation attribute ('deprecated', 'availability' or 'unavailable').
This warning is under a separate flag, -Wdocumentation-deprecated-sync, so it
can be turned off easily while leaving other -Wdocumentation warnings on.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164467 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164466 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
fatal error. Previously, if a fatal error was followed by a diagnostic which
was suppressed due to a SFINAETrap, we'd forget that we'd seen a fatal error.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164437 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
setter or getter backing a deprecated/unavailable property,
also not location of the property. // rdar://12324295
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164412 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This makes the wording more informative, and consistent with the other
warnings about uninitialized variables.
Also, me and David who reviewed this couldn't figure out why we would
need to do a lookup to get the name of the variable; so just print the
name directly.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164366 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164359 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The expression based expansion too often results in IR level optimizations
splitting the intermediate values into separate basic blocks, preventing
the formation of the VBSL instruction as the code author intended. In
particular, LICM would often hoist part of the computation out of a loop.
rdar://11011471
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164342 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Richard's comments. // rdar://12202422
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164316 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is some really old code (took me a while to find the test cases) & the
diagnostic text is slightly incorrect (it should really only apply to
re/declarations/, redefinitions are an error regardless of whether the types
match). Not sure if anyone cares about it, though.
For now this just makes the diagnostic more clear in less obvious cases where
the type of a declaration might not be explicitly written (eg: because it
uses decltype)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164313 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164301 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
non-function friend declaration. Patch by Josh Magee!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164273 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
it into -Wgnu.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164272 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
integral expression have the obvious result.
Patch reviewed by John McCall off line.
// rdar://12202422
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164143 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
LLVM_DELETED_FUNCTION.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164102 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
is no compelling argument that this is a generally useful warning,
and imposes a strong stylistic argument on code beyond what it was
intended to find warnings in.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164083 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
argument names. // rdar://12263549
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164077 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
between objc method parameter name and colon.
// rdar://12263549
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164047 91177308-0d34-0410-b5e6-96231b3b80d8
|