| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
takeAs to getAs.
llvm-svn: 209800
|
|
|
|
|
|
|
| |
now deprecated, ObjC containers instead of crashing.
// rdar://16859666
llvm-svn: 209758
|
|
|
|
| |
llvm-svn: 209613
|
|
|
|
|
|
|
| |
Required pulling LambdaExpr::Capture into its own header.
No functionality change.
llvm-svn: 208470
|
|
|
|
|
|
|
| |
objects to fund root class's instance methods.
// rdar://16650575
llvm-svn: 206781
|
|
|
|
|
|
| |
class.
llvm-svn: 203640
|
|
|
|
|
|
|
| |
the property assignment is an lvalue for an incomplete type.
// rdar://15118128. Reviewed offline by John McCall.
llvm-svn: 203043
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A return type is the declared or deduced part of the function type specified in
the declaration.
A result type is the (potentially adjusted) type of the value of an expression
that calls the function.
Rule of thumb:
* Declarations have return types and parameters.
* Expressions have result types and arguments.
llvm-svn: 200082
|
|
|
|
| |
llvm-svn: 198418
|
|
|
|
| |
llvm-svn: 198387
|
|
|
|
|
|
| |
Thanks to Alp Toker for the naming suggestion!
llvm-svn: 198052
|
|
|
|
|
|
| |
intended.
llvm-svn: 198049
|
|
|
|
|
|
|
| |
There are about 30 removed in this patch, generated by a new FixIt I haven't
got round to submitting yet.
llvm-svn: 195814
|
|
|
|
|
|
|
| |
objc++ properties using property-dot syntax.
// rdar://14654207
llvm-svn: 192819
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the same way GenericSelectionExpr works, and it's generally a
more consistent approach.
A large part of this patch is devoted to caching the value of the condition
of a ChooseExpr; it's needed to avoid threading an ASTContext into
IgnoreParens().
Fixes <rdar://problem/14438917>.
llvm-svn: 186738
|
|
|
|
|
|
|
|
|
|
| |
- factor the name construction part out from constructSetterName
- rename constructSetterName to the more appropriate constructSetterSelector
no functionality change intended.
rdar://problem/14035789
llvm-svn: 183582
|
|
|
|
|
|
|
| |
variables when they are used in such unevaluated
contexts as __typeof, etc. // rdar://13942025
llvm-svn: 182423
|
|
|
|
| |
llvm-svn: 181166
|
|
|
|
|
|
|
|
| |
constructor from None
Patch by Robert Wilhelm.
llvm-svn: 181139
|
|
|
|
|
|
|
|
|
| |
type-dependent intermediate result in a postfix ++ pseudo-
object operation.
Test case by Tong Shen.
llvm-svn: 179637
|
|
|
|
|
|
|
|
| |
references thereto.
Patch by Tong Shen!
llvm-svn: 179585
|
|
|
|
|
|
|
|
|
|
|
| |
http://lab.llvm.org:8011/builders/clang-x86_64-darwin10-gdb went back green
before it processed the reverted 178663, so it could not have been the culprit.
Revert "Revert 178663."
This reverts commit 4f8a3eb2ce5d4ba422483439e20c8cbb4d953a41.
llvm-svn: 178682
|
|
|
|
|
|
|
|
|
|
| |
Looks like it broke http://lab.llvm.org:8011/builders/clang-x86_64-darwin10-gdb
Revert "Don't compute a patched/semantic storage class."
This reverts commit 8f187f62cb0487d31bc4afdfcd47e11fe9a51d05.
llvm-svn: 178681
|
|
|
|
|
|
|
|
|
|
|
| |
For variables and functions clang used to store two storage classes. The one
"as written" in the code and a patched one, which, for example, propagates
static to the following decls.
This apparently is from the days clang lacked linkage computation. It is now
redundant and this patch removes it.
llvm-svn: 178663
|
|
|
|
|
|
|
| |
Nearly all of these changes are one-to-one replacements; the few that
aren't have to do with custom identifier validation.
llvm-svn: 174768
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
llvm-svn: 169237
|
|
|
|
| |
llvm-svn: 168851
|
|
|
|
|
|
| |
expose only the iterators instead.
llvm-svn: 168770
|
|
|
|
|
|
|
|
|
| |
if the type of the value is a non-trivial class type. Fixes PR14318.
(There's a minor ObjC++ language change here: given that we can't save the
value, the type of the assignment expression is void in such cases.)
llvm-svn: 167884
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This more accurately reflects its use: this flag is set when a method
matches the getter or setter name for a property in the same class,
and does not actually specify whether or not the definition of the method
will be synthesized (either implicitly or explicitly with @synthesize).
This renames the setter and backing field as well, and changes the
(soon-to-be-obsolete?) XML dump format to use 'property_accessor'
instead of 'synthesized'.
llvm-svn: 165626
|
|
|
|
|
|
|
|
| |
Clang will now honor the FP_CONTRACT pragma and emit LLVM
fmuladd intrinsics for expressions of the form A * B + C (when they occur in a
single statement).
llvm-svn: 164989
|
|
|
|
|
|
|
|
|
|
| |
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>.
llvm-svn: 164855
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
llvm-svn: 164854
|
|
|
|
| |
llvm-svn: 163722
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 162552
|
|
|
|
| |
llvm-svn: 162452
|
|
|
|
|
|
|
| |
objects used as dictionary subscript objects.
// rdar://11913153
llvm-svn: 161187
|
|
|
|
|
|
| |
// rdar://11528439
llvm-svn: 157517
|
|
|
|
|
|
|
|
| |
backing two propeties because proprty names
match except for first letter being of different
case. // rdar://11528439, [PR12936].
llvm-svn: 157435
|
|
|
|
|
|
|
|
|
|
|
| |
off PartialDiagnostic. PartialDiagnostic is rather heavyweight for
something that is in the critical path and is rarely used. So, switch
over to an abstract-class-based callback mechanism that delays most of
the work until a diagnostic is actually produced. Good for ~11k code
size reduction in the compiler and 1% speedup in -fsyntax-only on the
code in <rdar://problem/11004361>.
llvm-svn: 156176
|
|
|
|
|
|
|
| |
is issued on weak property as receiver and not on
any other use of a weak property. // rdar://10225276
llvm-svn: 155169
|
|
|
|
|
|
|
| |
if receiver is a 'weak' property, by type or by attribute.
// rdar://10225276
llvm-svn: 155159
|
|
|
|
|
|
|
| |
property accessor (getter) missing, instead of crashing.
// rdar://11273060
llvm-svn: 155036
|
|
|
|
|
|
| |
expressions without their OpaqueValueExprs
llvm-svn: 154669
|
|
|
|
|
|
| |
rebuilt. Fixes <rdar://problem/11052352>.
llvm-svn: 154667
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
reference is going to message the setter, the getter, or both.
Having this info on the ObjCPropertyRefExpr node makes it easier for AST
clients (like libclang) to reason about the meaning of the property reference.
[AST/Sema]
-Use 2 bits (with a PointerIntPair) in ObjCPropertyRefExpr to record the above info
-Have ObjCPropertyOpBuilder set the info appropriately.
[libclang]
-When there is an implicit property reference (property syntax using methods)
have clang_getCursorReferenced return a cursor for the method. If the property
reference is going to result in messaging both the getter and the setter choose
to return a cursor for the setter because it is less obvious from source inspection
that the setter is getting called.
The general idea has the seal of approval by John.
rdar://11151621
llvm-svn: 153709
|
|
|
|
|
|
|
| |
provide 'fixit' hint when dictionary index
is not of proper type. // rdar://11062080
llvm-svn: 153584
|
|
|
|
|
|
|
|
|
|
| |
(Lex to AST).
The member variable is always "LangOpts" and the member function is always "getLangOpts".
Reviewed by Chris Lattner
llvm-svn: 152536
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NSNumber, and boolean literals. This includes both Sema and Codegen support.
Included is also support for new Objective-C container subscripting.
My apologies for the large patch. It was very difficult to break apart.
The patch introduces changes to the driver as well to cause clang to link
in additional runtime support when needed to support the new language features.
Docs are forthcoming to document the implementation and behavior of these features.
llvm-svn: 152137
|
|
|
|
|
|
| |
that we can correctly compute value-dependence of the OVE.
llvm-svn: 151291
|