| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
'default' methods in Foundation does not
infer 'instancetype' for methods' result type.
// rdar://15145218
llvm-svn: 192129
|
|
|
|
|
|
|
|
| |
'instancetype' for known family of methods
with related result type; such as 'init'
methods. // rdar://14987948
llvm-svn: 190956
|
|
|
|
| |
llvm-svn: 189592
|
|
|
|
|
|
| |
methods which can be migrated to instancetype.
llvm-svn: 187672
|
|
|
|
|
|
| |
in my previous patch which was reverted in r187657
llvm-svn: 187661
|
|
|
|
|
|
| |
buildbot.
llvm-svn: 187657
|
|
|
|
|
|
| |
Also removed check for "NS" prefix for class name.
llvm-svn: 187655
|
|
|
|
|
|
|
|
|
|
| |
with certain prefix selector matching their class names' suffix."
This reverts commit r187626.
It is breaking the bots.
llvm-svn: 187634
|
|
|
|
|
|
|
| |
for mehods with certain prefix selector matching their class names'
suffix.
llvm-svn: 187626
|
|
|
|
|
|
|
|
| |
Expose static type of init/alloc/retain with
instance type as well. Ad-hoc cases are coming
next.
llvm-svn: 187068
|
|
|
|
|
|
| |
instancetype migration.
llvm-svn: 187000
|
|
|
|
|
|
|
| |
which are candidate for migrating to
'instancetype'. wip.
llvm-svn: 186981
|
|
|
|
|
|
|
|
| |
- reduce default buffer size to 64, which will still be large enough to
hold any property names found in the wild.
- get rid of the /*static*/ comments.
llvm-svn: 183697
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
|
|
|
|
|
|
|
|
| |
Typo correction for an unqualified name needs to walk through all of the identifier tables of all modules.
When we have a global index, just walk its identifier table only.
rdar://13425732
llvm-svn: 179730
|
|
|
|
|
|
| |
These are causing assertions on some MSVC builds.
llvm-svn: 174805
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
nearby 'C++0x' comments.
llvm-svn: 171372
|
|
|
|
| |
llvm-svn: 171367
|
|
|
|
|
|
| |
latter is rather a mess to type.
llvm-svn: 169919
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: 167694
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 164610
|
|
|
|
| |
llvm-svn: 163221
|
|
|
|
| |
llvm-svn: 161660
|
|
|
|
| |
llvm-svn: 160663
|
|
|
|
|
|
| |
way to disable keywords under Microsoft mode.
llvm-svn: 160612
|
|
|
|
| |
llvm-svn: 158548
|
|
|
|
|
|
|
|
| |
that bridging between the two is free. Saves ~4k of code size,
although I don't see any measurable performance difference
(unfortunately).
llvm-svn: 156187
|
|
|
|
| |
llvm-svn: 152547
|
|
|
|
|
|
|
|
|
| |
IndentifierTable::get() and into IdentifierTable's constructor.
This gets a 0.7% reducing on lexing time for Cocoa.h, and
about the same for PCH generation.
llvm-svn: 151854
|
|
|
|
|
|
|
|
| |
commit to a particular syntax for modules,
and don't have time to push it forward in the near future.
llvm-svn: 151841
|
|
|
|
|
|
|
| |
(I was going to fix the TODO about DenseMap too, but
that would break self-host right now. See PR11922.)
llvm-svn: 149799
|
|
|
|
|
|
|
|
| |
include.
Fix all the transitive include users.
llvm-svn: 149783
|
|
|
|
|
|
| |
appropriate or when GCC requires it)
llvm-svn: 148292
|
|
|
|
| |
llvm-svn: 147469
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
modules. This leaves us without an explicit syntax for importing
modules in C/C++, because such a syntax needs to be discussed
first. In Objective-C/Objective-C++, the @import syntax is used to
import modules.
Note that, under -fmodules, C/C++ programs can import modules via the
#include mechanism when a module map is in place for that header. This
allows us to work with modules in C/C++ without committing to a syntax.
llvm-svn: 147467
|
|
|
|
|
|
|
| |
to make a macro public (the default for headers) or private,
respectively.
llvm-svn: 147455
|
|
|
|
|
|
|
|
| |
so this patch is surprisingly small.
Also drop -Wc1x-extensions in favor of -Wc11-extensions. I don't think we need to keep this around for compatibility.
llvm-svn: 147221
|
|
|
|
|
|
| |
But, warn too. // rdar://10597832
llvm-svn: 146904
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
AST file more lazy, so that we don't eagerly load that information for
all known identifiers each time a new AST file is loaded. The eager
reloading made some sense in the context of precompiled headers, since
very few identifiers were defined before PCH load time. With modules,
however, a huge amount of code can get parsed before we see an
@import, so laziness becomes important here.
The approach taken to make this information lazy is fairly simple:
when we load a new AST file, we mark all of the existing identifiers
as being out-of-date. Whenever we want to access information that may
come from an AST (e.g., whether the identifier has a macro definition,
or what top-level declarations have that name), we check the
out-of-date bit and, if it's set, ask the AST reader to update the
IdentifierInfo from the AST files. The update is a merge, and we now
take care to merge declarations before/after imports with declarations
from multiple imports.
The results of this optimization are fairly dramatic. On a small
application that brings in 14 non-trivial modules, this takes modules
from being > 3x slower than a "perfect" PCH file down to 30% slower
for a full rebuild. A partial rebuild (where the PCH file or modules
can be re-used) is down to 7% slower. Making the PCH file just a
little imperfect (e.g., adding two smallish modules used by a bunch of
.m files that aren't in the PCH file) tips the scales in favor of the
modules approach, with 24% faster partial rebuilds.
This is just a first step; the lazy scheme could possibly be improved
by adding versioning, so we don't search into modules we already
searched. Moreover, we'll need similar lazy schemes for all of the
other lookup data structures, such as DeclContexts.
llvm-svn: 143100
|
|
|
|
|
|
|
| |
public. Add a __private_macro__ directive to hide a macro, similar to
the __module_private__ declaration specifier.
llvm-svn: 142188
|
|
|
|
|
|
| |
C++98 mode. Only the first occurrence of each keyword will produce a warning.
llvm-svn: 141700
|
|
|
|
|
|
|
|
| |
that this flag must be used only for Microsoft extensions and not emulation; to avoid confusion with the new LangOptions::MicrosoftMode flag.
Many of the code now under LangOptions::MicrosoftExt will eventually be moved under the LangOptions::MicrosoftMode flag.
llvm-svn: 139987
|
|
|
|
|
|
|
|
|
|
|
| |
include guards don't show up as macro definitions in every translation
unit that imports a module. Macro definitions can, however, be
exported with the intentionally-ugly #__export_macro__
directive. Implement this feature by not even bothering to serialize
non-exported macros to a module, because clients of that module need
not (should not) know that these macros even exist.
llvm-svn: 138943
|
|
|
|
|
|
| |
This matches gcc's logic. Second half of PR10661.
llvm-svn: 138730
|
|
|
|
|
|
|
|
| |
LLVM.h imports
them into the clang namespace.
llvm-svn: 135852
|
|
|
|
|
|
|
| |
passed to it, and unknown selectors causing potential leak.
// rdar://9659270
llvm-svn: 134449
|
|
|
|
|
|
|
|
|
|
| |
Language-design credit goes to a lot of people, but I particularly want
to single out Blaine Garst and Patrick Beard for their contributions.
Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself,
in no particular order.
llvm-svn: 133103
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Related result types apply Cocoa conventions to the type of message
sends and property accesses to Objective-C methods that are known to
always return objects whose type is the same as the type of the
receiving class (or a subclass thereof), such as +alloc and
-init. This tightens up static type safety for Objective-C, so that we
now diagnose mistakes like this:
t.m:4:10: warning: incompatible pointer types initializing 'NSSet *'
with an
expression of type 'NSArray *' [-Wincompatible-pointer-types]
NSSet *array = [[NSArray alloc] init];
^ ~~~~~~~~~~~~~~~~~~~~~~
/System/Library/Frameworks/Foundation.framework/Headers/NSObject.h:72:1:
note:
instance method 'init' is assumed to return an instance of its
receiver
type ('NSArray *')
- (id)init;
^
It also means that we get decent type inference when writing code in
Objective-C++0x:
auto array = [[NSMutableArray alloc] initWithObjects:@"one", @"two",nil];
// ^ now infers NSMutableArray* rather than id
llvm-svn: 132868
|