| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
| |
// rdar://11671080
llvm-svn: 158874
|
| |
|
|
|
|
| |
has not overridden the property. // rdar://11656982
llvm-svn: 158871
|
| |
|
|
|
|
|
|
|
|
| |
"write" attribute (copy/retain/etc.). But, property declaration in
primary class and protcols are tentative as they may be overridden
into a 'readwrite' property in class extensions. Postpone diagnosing
such warnings until the class implementation is seen.
// rdar://11656982
llvm-svn: 158869
|
| |
|
|
|
|
| |
of CFG, discussion: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120507/057370.html)
llvm-svn: 158854
|
| |
|
|
|
|
|
|
|
| |
Now that this is a C-only warning, we can use "static" instead of "internal
linkage", which is a term developers are probably more familiar with.
This makes for a better warning message. The warning name was changed to match,
since "internal linkage" is not mentioned in the warning text anymore.
llvm-svn: 158853
|
| |
|
|
|
|
|
|
| |
This commits sets the grounds for more aggressive use after free
checking. We will use the Relinquished sate to denote that someone
else is now responsible for releasing the memory.
llvm-svn: 158850
|
| |
|
|
|
|
|
|
|
|
| |
in microsoft mode. Fixes PR12701.
The code for this was already in 2 of the 3 branches of a
conditional and missing in the 3rd branch, so lift it above
the conditional.
llvm-svn: 158842
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's very easy for anonymous external linkage to propagate in C++ through
return types and parameter types. Likewise, it's possible that a template
containing an inline function is only used with parameters that have internal
linkage. Actually diagnosing where the internal linkage comes from is fairly
difficult (both to locate and then to print nicely). Finally, since we only
have one translation unit available, we can't even prove that any of this
violates the ODR.
This warning needs better-defined behavior in C++ before it can really go in.
Rewording of the C warning (which /is/ specified by C99) coming shortly.
llvm-svn: 158836
|
| |
|
|
|
|
|
| |
error was asserting on anything that included Windows.h. MS-style inline asm is
still dropped, but at least now we're not completely silent about it.
llvm-svn: 158833
|
| |
|
|
|
|
| |
change in behavior. // rdar://11671080
llvm-svn: 158828
|
| |
|
|
|
|
|
|
| |
designed
a bit further. We may wish to just have -Wno flags to silence warnings, and not have a -no-pedantic.
llvm-svn: 158796
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
target Objective-C runtime down to the frontend: break this
down into a single target runtime kind and version, and compute
all the relevant information from that. This makes it
relatively painless to add support for new runtimes to the
compiler. Make the new -cc1 flag, -fobjc-runtime=blah-x.y.z,
available at the driver level as a better and more general
alternative to -fgnu-runtime and -fnext-runtime. This new
concept of an Objective-C runtime also encompasses what we
were previously separating out as the "Objective-C ABI", so
fragile vs. non-fragile runtimes are now really modelled as
different kinds of runtime, paving the way for better overall
differentiation.
As a sort of special case, continue to accept the -cc1 flag
-fobjc-runtime-has-weak, as a sop to PLCompatibilityWeak.
I won't go so far as to say "no functionality change", even
ignoring the new driver flag, but subtle changes in driver
semantics are almost certainly not intended.
llvm-svn: 158793
|
| |
|
|
|
|
|
|
| |
Per Anna's comment, this is a better way to handle "to-do list"-type failures.
This way we'll know if any of the features get fixed; in an XFAIL file, /all/
the cases have to be fixed before lit would tell us anything.
llvm-svn: 158791
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The default global placement new just returns the pointer it is given.
Note that other custom 'new' implementations with placement args are not
guaranteed to do this.
In addition, we need to invalidate placement args, since they may be updated by
the allocator function. (Also, right now we don't properly handle the
constructor inside a CXXNewExpr, so we need to invalidate the placement args
just so that callers know something changed!)
This invalidation is not perfect because CallOrObjCMessage doesn't support
CXXNewExpr, and all of our invalidation callbacks expect that if there's no
CallOrObjCMessage, the invalidation is happening manually (e.g. by a direct
assignment) and shouldn't affect checker-specific metadata (like malloc state);
hence the malloc test case in new-fail.cpp. But region values are now
properly invalidated, at least.
The long-term solution to this problem is to rework CallOrObjCMessage into
something more general, rather than the morass of branches it is today.
<rdar://problem/11679031>
llvm-svn: 158784
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[NSNumber numberWithDouble:cppb];
warning: converting to boxing syntax requires a cast
to something like:
[NSNumber numberWithDouble:cppb];
warning: converting to boxing syntax requires casting 'bool' to 'double'
This is way better to fully understand the warning.
rdar://11705106
llvm-svn: 158783
|
| |
|
|
|
|
|
|
| |
for "hard" ARC errors, not warnings.
rdar://11691437
llvm-svn: 158781
|
| |
|
|
|
|
|
|
| |
Also add a couple of unit tests to check the invalid-PCH error messages
to satisfy PR4568 and for the assertion (introduced in r149918 and fixed
in r158769) that would cause clang to crash when given an empty PCH.
llvm-svn: 158772
|
| |
|
|
|
|
|
|
|
| |
* Retain comments in the AST
* Serialize/deserialize comments
* Find comments attached to a certain Decl
* Expose raw comment text and SourceRange via libclang
llvm-svn: 158771
|
| |
|
|
|
|
| |
PR13153.
llvm-svn: 158768
|
| |
|
|
| |
llvm-svn: 158763
|
| |
|
|
|
|
|
| |
Add error checking for the static qualifier which is now allowed in certain situations for OpenCL 1.2. Use the CL version to turn on this feature.
Added test case for 1.2 static storage class feature.
llvm-svn: 158759
|
| |
|
|
|
|
|
|
| |
name as an existing ivar since this is common source of error
when people remove @synthesize to take advantage of autosynthesis.
// rdar://11671080
llvm-svn: 158756
|
| |
|
|
|
|
| |
conflicts from a separate problematic patch.
llvm-svn: 158750
|
| |
|
|
|
|
|
|
| |
The original r158700 caused crashes in the gcc test suite,
g++.abi/vtable3a.C among others. It also caused failures in the libc++
test suite.
llvm-svn: 158749
|
| |
|
|
|
|
| |
types to actually includes the value, rather than saying <uninitialized>.
llvm-svn: 158745
|
| |
|
|
| |
llvm-svn: 158744
|
| |
|
|
|
|
|
|
| |
initializer need be null initialized before initializer takes
hold, just like any other initialized retainable object pointer.
// rdar://11016025
llvm-svn: 158738
|
| |
|
|
|
|
| |
includes support for the align (which fixes PR12631).
llvm-svn: 158717
|
| |
|
|
|
|
| |
(Fixes radar://11691035 PR13140)
llvm-svn: 158703
|
| |
|
|
|
|
|
| |
It turns out SourceManager treating the "one-past-the-end" location as invalid,
but then failing to set the invalid flag properly.
llvm-svn: 158699
|
| |
|
|
|
|
|
|
|
| |
ObjCInterfaceDec::lookupInstanceMethod to make sure we check categories as well
and update related tests.
rdar://11695288
llvm-svn: 158697
|
| |
|
|
|
|
|
|
|
| |
option. On the driver, check if we are using libraries from gcc 4.7 or newer
and if so pass -fuse-init-array to the frontend.
The crtbegin*.o files in gcc 4.7 no longer call the constructors listed in
.ctors, so we have to use .init_array.
llvm-svn: 158694
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
because it expects a reference and receives a non-l-value.
For example, given:
int foo(int &);
template<int x> void b() { foo(x); }
clang will now print "expects an l-value for 1st argument" instead of
"no known conversion from 'int' to 'int &' for 1st argument". The change
in wording (and associated code to detect the case) was prompted by
comment #5 in PR3104, and should be the last bit of work needed for the
bug.
llvm-svn: 158691
|
| |
|
|
|
|
|
| |
the compiler predefines buffer. These are essentially part of
the Objective-C language.
llvm-svn: 158690
|
| |
|
|
|
|
|
|
|
|
| |
Per post-commit review, it's not appropriate to use ExtWarn in C++, because
we can't prove that the inline function will actually be defined in more than
one place (and thus we can't prove that this violates the ODR).
This removes the warning entirely from uses in the main source file in C++.
llvm-svn: 158689
|
| |
|
|
| |
llvm-svn: 158687
|
| |
|
|
|
|
|
|
| |
This includes treating anonymous namespaces like internal linkage, and allowing
const variables to be used even if internal. The whole thing's been broken out
into a separate function to avoid nested ifs.
llvm-svn: 158683
|
| |
|
|
|
|
|
|
|
|
|
| |
This handles the very common case of people writing inline functions in their
main source files and not tagging them as inline. These cases should still
behave as the user intended. (The diagnostic is still emitted as an extension.)
I'm reworking this code anyway to account for C++'s equivalent restriction in
[basic.def.odr]p6, but this should get some bots back to green.
llvm-svn: 158666
|
| |
|
|
|
|
| |
Patch by Nikola Smiljanic!
llvm-svn: 158664
|
| |
|
|
|
|
| |
crash on invalid function decl with alloc_size attribute
llvm-svn: 158663
|
| |
|
|
|
|
| |
means the function allocates x^2 bytes. GCC also accepts this syntax
llvm-svn: 158662
|
| |
|
|
|
|
|
|
| |
Now, as long as the 'Namespaces' variable is correct inside Attr.td, the
generated code will correctly admit a C++11 attribute only when it has the
appropriate namespace(s).
llvm-svn: 158661
|
| |
|
|
|
|
| |
__forceinline is a combination of the inline keyword and __attribute__((always_inline))
llvm-svn: 158653
|
| |
|
|
|
|
|
|
|
| |
also deal with '>>>' (in CUDA), '>=', and '>>='. Fix the FixItHints logic to
deal with cases where the token is followed by an adjacent '=', '==', '>=',
'>>=', or '>>>' token, where a naive fix-it would result in a differing token
stream on a re-lex.
llvm-svn: 158652
|
| |
|
|
|
|
| |
the member expression is in parentheses.
llvm-svn: 158651
|
| |
|
|
| |
llvm-svn: 158613
|
| |
|
|
|
|
|
| |
initializer, it is uninitialized, even if we may be coming from somewhere where
it was initialized.
llvm-svn: 158611
|
| |
|
|
|
|
|
| |
The target specific __builtin_va_list types are now explicitly built instead
of injecting strings into the preprocessor input.
llvm-svn: 158592
|
| |
|
|
|
|
|
|
| |
semantics when promotions are involved.
(As far as I can tell, this only affects some edge cases.)
llvm-svn: 158591
|
| |
|
|
| |
llvm-svn: 158588
|